Pull in v4.20-rc3 via drm-next.
Unified · Split
| @@ -323,7 +323,6 @@ ForEachMacros: · 322 unmodified lines | ||
| 323 | 323 | - 'protocol_for_each_card' |
| 324 | 324 | - 'protocol_for_each_dev' |
| 325 | 325 | - 'queue_for_each_hw_ctx' |
| 326 | − - 'radix_tree_for_each_contig' | |
| 327 | 326 | - 'radix_tree_for_each_slot' |
| 328 | 327 | - 'radix_tree_for_each_tagged' |
| 329 | 328 | - 'rbtree_postorder_for_each_entry_safe' |
| @@ -119,6 +119,13 @@ Mark Brown <broonie@sirena.org.uk> · 118 unmodified lines | ||
| 119 | 119 | Mark Yao <markyao0591@gmail.com> <mark.yao@rock-chips.com> |
| 120 | 120 | Martin Kepplinger <martink@posteo.de> <martin.kepplinger@theobroma-systems.com> |
| 121 | 121 | Martin Kepplinger <martink@posteo.de> <martin.kepplinger@ginzinger.com> |
| 122 | +Matthew Wilcox <willy@infradead.org> <matthew.r.wilcox@intel.com> | |
| 123 | +Matthew Wilcox <willy@infradead.org> <matthew@wil.cx> | |
| 124 | +Matthew Wilcox <willy@infradead.org> <mawilcox@linuxonhyperv.com> | |
| 125 | +Matthew Wilcox <willy@infradead.org> <mawilcox@microsoft.com> | |
| 126 | +Matthew Wilcox <willy@infradead.org> <willy@debian.org> | |
| 127 | +Matthew Wilcox <willy@infradead.org> <willy@linux.intel.com> | |
| 128 | +Matthew Wilcox <willy@infradead.org> <willy@parisc-linux.org> | |
| 122 | 129 | Matthieu CASTET <castet.matthieu@free.fr> |
| 123 | 130 | Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@brturbo.com.br> |
| 124 | 131 | Mauro Carvalho Chehab <mchehab@kernel.org> <maurochehab@gmail.com> |
| @@ -152,7 +159,13 @@ Peter Oruba <peter@oruba.de> · 27 unmodified lines | ||
| 152 | 159 | Peter Oruba <peter.oruba@amd.com> |
| 153 | 160 | Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com> |
| 154 | 161 | Praveen BP <praveenbp@ti.com> |
| 162 | +Punit Agrawal <punitagrawal@gmail.com> <punit.agrawal@arm.com> | |
| 155 | 163 | Qais Yousef <qsyousef@gmail.com> <qais.yousef@imgtec.com> |
| 164 | +Oleksij Rempel <linux@rempel-privat.de> <bug-track@fisher-privat.net> | |
| 165 | +Oleksij Rempel <linux@rempel-privat.de> <external.Oleksij.Rempel@de.bosch.com> | |
| 166 | +Oleksij Rempel <linux@rempel-privat.de> <fixed-term.Oleksij.Rempel@de.bosch.com> | |
| 167 | +Oleksij Rempel <linux@rempel-privat.de> <o.rempel@pengutronix.de> | |
| 168 | +Oleksij Rempel <linux@rempel-privat.de> <ore@pengutronix.de> | |
| 156 | 169 | Rajesh Shah <rajesh.shah@intel.com> |
| 157 | 170 | Ralf Baechle <ralf@linux-mips.org> |
| 158 | 171 | Ralf Wildenhues <Ralf.Wildenhues@gmx.de> |
| @@ -2138,6 +2138,10 @@ E: paul@laufernet.com · 2137 unmodified lines | ||
| 2138 | 2138 | D: Soundblaster driver fixes, ISAPnP quirk |
| 2139 | 2139 | S: California, USA |
| 2140 | 2140 | |
| 2141 | +N: Jarkko Lavinen | |
| 2142 | +E: jarkko.lavinen@nokia.com | |
| 2143 | +D: OMAP MMC support | |
| 2144 | + | |
| 2141 | 2145 | N: Jonathan Layes |
| 2142 | 2146 | D: ARPD support |
| 2143 | 2147 | |
| @@ -1,428 +0,0 @@ | ||
| 1 | − | |
| 2 | −This is a brief list of all the files in ./linux/Documentation and what | |
| 3 | −they contain. If you add a documentation file, please list it here in | |
| 4 | −alphabetical order as well, or risk being hunted down like a rabid dog. | |
| 5 | −Please keep the descriptions small enough to fit on one line. | |
| 6 | − Thanks -- Paul G. | |
| 7 | − | |
| 8 | −Following translations are available on the WWW: | |
| 9 | − | |
| 10 | − - Japanese, maintained by the JF Project (jf@listserv.linux.or.jp), at | |
| 11 | − http://linuxjf.sourceforge.jp/ | |
| 12 | − | |
| 13 | −00-INDEX | |
| 14 | − - this file. | |
| 15 | −ABI/ | |
| 16 | − - info on kernel <-> userspace ABI and relative interface stability. | |
| 17 | −CodingStyle | |
| 18 | − - nothing here, just a pointer to process/coding-style.rst. | |
| 19 | −DMA-API.txt | |
| 20 | − - DMA API, pci_ API & extensions for non-consistent memory machines. | |
| 21 | −DMA-API-HOWTO.txt | |
| 22 | − - Dynamic DMA mapping Guide | |
| 23 | −DMA-ISA-LPC.txt | |
| 24 | − - How to do DMA with ISA (and LPC) devices. | |
| 25 | −DMA-attributes.txt | |
| 26 | − - listing of the various possible attributes a DMA region can have | |
| 27 | −EDID/ | |
| 28 | − - directory with info on customizing EDID for broken gfx/displays. | |
| 29 | −IPMI.txt | |
| 30 | − - info on Linux Intelligent Platform Management Interface (IPMI) Driver. | |
| 31 | −IRQ-affinity.txt | |
| 32 | − - how to select which CPU(s) handle which interrupt events on SMP. | |
| 33 | −IRQ-domain.txt | |
| 34 | − - info on interrupt numbering and setting up IRQ domains. | |
| 35 | −IRQ.txt | |
| 36 | − - description of what an IRQ is. | |
| 37 | −Intel-IOMMU.txt | |
| 38 | − - basic info on the Intel IOMMU virtualization support. | |
| 39 | −Makefile | |
| 40 | − - It's not of interest for those who aren't touching the build system. | |
| 41 | −PCI/ | |
| 42 | − - info related to PCI drivers. | |
| 43 | −RCU/ | |
| 44 | − - directory with info on RCU (read-copy update). | |
| 45 | −SAK.txt | |
| 46 | − - info on Secure Attention Keys. | |
| 47 | −SM501.txt | |
| 48 | − - Silicon Motion SM501 multimedia companion chip | |
| 49 | −SubmittingPatches | |
| 50 | − - nothing here, just a pointer to process/coding-style.rst. | |
| 51 | −accounting/ | |
| 52 | − - documentation on accounting and taskstats. | |
| 53 | −acpi/ | |
| 54 | − - info on ACPI-specific hooks in the kernel. | |
| 55 | −admin-guide/ | |
| 56 | − - info related to Linux users and system admins. | |
| 57 | −aoe/ | |
| 58 | − - description of AoE (ATA over Ethernet) along with config examples. | |
| 59 | −arm/ | |
| 60 | − - directory with info about Linux on the ARM architecture. | |
| 61 | −arm64/ | |
| 62 | − - directory with info about Linux on the 64 bit ARM architecture. | |
| 63 | −auxdisplay/ | |
| 64 | − - misc. LCD driver documentation (cfag12864b, ks0108). | |
| 65 | −backlight/ | |
| 66 | − - directory with info on controlling backlights in flat panel displays | |
| 67 | −block/ | |
| 68 | − - info on the Block I/O (BIO) layer. | |
| 69 | −blockdev/ | |
| 70 | − - info on block devices & drivers | |
| 71 | −bt8xxgpio.txt | |
| 72 | − - info on how to modify a bt8xx video card for GPIO usage. | |
| 73 | −btmrvl.txt | |
| 74 | − - info on Marvell Bluetooth driver usage. | |
| 75 | −bus-devices/ | |
| 76 | − - directory with info on TI GPMC (General Purpose Memory Controller) | |
| 77 | −bus-virt-phys-mapping.txt | |
| 78 | − - how to access I/O mapped memory from within device drivers. | |
| 79 | −cdrom/ | |
| 80 | − - directory with information on the CD-ROM drivers that Linux has. | |
| 81 | −cgroup-v1/ | |
| 82 | − - cgroups v1 features, including cpusets and memory controller. | |
| 83 | −cma/ | |
| 84 | − - Continuous Memory Area (CMA) debugfs interface. | |
| 85 | −conf.py | |
| 86 | − - It's not of interest for those who aren't touching the build system. | |
| 87 | −connector/ | |
| 88 | − - docs on the netlink based userspace<->kernel space communication mod. | |
| 89 | −console/ | |
| 90 | − - documentation on Linux console drivers. | |
| 91 | −core-api/ | |
| 92 | − - documentation on kernel core components. | |
| 93 | −cpu-freq/ | |
| 94 | − - info on CPU frequency and voltage scaling. | |
| 95 | −cpu-hotplug.txt | |
| 96 | − - document describing CPU hotplug support in the Linux kernel. | |
| 97 | −cpu-load.txt | |
| 98 | − - document describing how CPU load statistics are collected. | |
| 99 | −cpuidle/ | |
| 100 | − - info on CPU_IDLE, CPU idle state management subsystem. | |
| 101 | −cputopology.txt | |
| 102 | − - documentation on how CPU topology info is exported via sysfs. | |
| 103 | −crc32.txt | |
| 104 | − - brief tutorial on CRC computation | |
| 105 | −crypto/ | |
| 106 | − - directory with info on the Crypto API. | |
| 107 | −dcdbas.txt | |
| 108 | − - information on the Dell Systems Management Base Driver. | |
| 109 | −debugging-modules.txt | |
| 110 | − - some notes on debugging modules after Linux 2.6.3. | |
| 111 | −debugging-via-ohci1394.txt | |
| 112 | − - how to use firewire like a hardware debugger memory reader. | |
| 113 | −dell_rbu.txt | |
| 114 | − - document demonstrating the use of the Dell Remote BIOS Update driver. | |
| 115 | −dev-tools/ | |
| 116 | − - directory with info on development tools for the kernel. | |
| 117 | −device-mapper/ | |
| 118 | − - directory with info on Device Mapper. | |
| 119 | −dmaengine/ | |
| 120 | − - the DMA engine and controller API guides. | |
| 121 | −devicetree/ | |
| 122 | − - directory with info on device tree files used by OF/PowerPC/ARM | |
| 123 | −digsig.txt | |
| 124 | − -info on the Digital Signature Verification API | |
| 125 | −dma-buf-sharing.txt | |
| 126 | − - the DMA Buffer Sharing API Guide | |
| 127 | −docutils.conf | |
| 128 | − - nothing here. Just a configuration file for docutils. | |
| 129 | −dontdiff | |
| 130 | − - file containing a list of files that should never be diff'ed. | |
| 131 | −driver-api/ | |
| 132 | − - the Linux driver implementer's API guide. | |
| 133 | −driver-model/ | |
| 134 | − - directory with info about Linux driver model. | |
| 135 | −early-userspace/ | |
| 136 | − - info about initramfs, klibc, and userspace early during boot. | |
| 137 | −efi-stub.txt | |
| 138 | − - How to use the EFI boot stub to bypass GRUB or elilo on EFI systems. | |
| 139 | −eisa.txt | |
| 140 | − - info on EISA bus support. | |
| 141 | −extcon/ | |
| 142 | − - directory with porting guide for Android kernel switch driver. | |
| 143 | −isa.txt | |
| 144 | − - info on EISA bus support. | |
| 145 | −fault-injection/ | |
| 146 | − - dir with docs about the fault injection capabilities infrastructure. | |
| 147 | −fb/ | |
| 148 | − - directory with info on the frame buffer graphics abstraction layer. | |
| 149 | −features/ | |
| 150 | − - status of feature implementation on different architectures. | |
| 151 | −filesystems/ | |
| 152 | − - info on the vfs and the various filesystems that Linux supports. | |
| 153 | −firmware_class/ | |
| 154 | − - request_firmware() hotplug interface info. | |
| 155 | −flexible-arrays.txt | |
| 156 | − - how to make use of flexible sized arrays in linux | |
| 157 | −fmc/ | |
| 158 | − - information about the FMC bus abstraction | |
| 159 | −fpga/ | |
| 160 | − - FPGA Manager Core. | |
| 161 | −futex-requeue-pi.txt | |
| 162 | − - info on requeueing of tasks from a non-PI futex to a PI futex | |
| 163 | −gcc-plugins.txt | |
| 164 | − - GCC plugin infrastructure. | |
| 165 | −gpio/ | |
| 166 | − - gpio related documentation | |
| 167 | −gpu/ | |
| 168 | − - directory with information on GPU driver developer's guide. | |
| 169 | −hid/ | |
| 170 | − - directory with information on human interface devices | |
| 171 | −highuid.txt | |
| 172 | − - notes on the change from 16 bit to 32 bit user/group IDs. | |
| 173 | −hwspinlock.txt | |
| 174 | − - hardware spinlock provides hardware assistance for synchronization | |
| 175 | −timers/ | |
| 176 | − - info on the timer related topics | |
| 177 | −hw_random.txt | |
| 178 | − - info on Linux support for random number generator in i8xx chipsets. | |
| 179 | −hwmon/ | |
| 180 | − - directory with docs on various hardware monitoring drivers. | |
| 181 | −i2c/ | |
| 182 | − - directory with info about the I2C bus/protocol (2 wire, kHz speed). | |
| 183 | −x86/i386/ | |
| 184 | − - directory with info about Linux on Intel 32 bit architecture. | |
| 185 | −ia64/ | |
| 186 | − - directory with info about Linux on Intel 64 bit architecture. | |
| 187 | −ide/ | |
| 188 | − - Information regarding the Enhanced IDE drive. | |
| 189 | −iio/ | |
| 190 | − - info on industrial IIO configfs support. | |
| 191 | −index.rst | |
| 192 | − - main index for the documentation at ReST format. | |
| 193 | −infiniband/ | |
| 194 | − - directory with documents concerning Linux InfiniBand support. | |
| 195 | −input/ | |
| 196 | − - info on Linux input device support. | |
| 197 | −intel_txt.txt | |
| 198 | − - info on intel Trusted Execution Technology (intel TXT). | |
| 199 | −io-mapping.txt | |
| 200 | − - description of io_mapping functions in linux/io-mapping.h | |
| 201 | −io_ordering.txt | |
| 202 | − - info on ordering I/O writes to memory-mapped addresses. | |
| 203 | −ioctl/ | |
| 204 | − - directory with documents describing various IOCTL calls. | |
| 205 | −iostats.txt | |
| 206 | − - info on I/O statistics Linux kernel provides. | |
| 207 | −irqflags-tracing.txt | |
| 208 | − - how to use the irq-flags tracing feature. | |
| 209 | −isapnp.txt | |
| 210 | − - info on Linux ISA Plug & Play support. | |
| 211 | −isdn/ | |
| 212 | − - directory with info on the Linux ISDN support, and supported cards. | |
| 213 | −kbuild/ | |
| 214 | − - directory with info about the kernel build process. | |
| 215 | −kdump/ | |
| 216 | − - directory with mini HowTo on getting the crash dump code to work. | |
| 217 | −doc-guide/ | |
| 218 | − - how to write and format reStructuredText kernel documentation | |
| 219 | −kernel-per-CPU-kthreads.txt | |
| 220 | − - List of all per-CPU kthreads and how they introduce jitter. | |
| 221 | −kobject.txt | |
| 222 | − - info of the kobject infrastructure of the Linux kernel. | |
| 223 | −kprobes.txt | |
| 224 | − - documents the kernel probes debugging feature. | |
| 225 | −kref.txt | |
| 226 | − - docs on adding reference counters (krefs) to kernel objects. | |
| 227 | −laptops/ | |
| 228 | − - directory with laptop related info and laptop driver documentation. | |
| 229 | −ldm.txt | |
| 230 | − - a brief description of LDM (Windows Dynamic Disks). | |
| 231 | −leds/ | |
| 232 | − - directory with info about LED handling under Linux. | |
| 233 | −livepatch/ | |
| 234 | − - info on kernel live patching. | |
| 235 | −locking/ | |
| 236 | − - directory with info about kernel locking primitives | |
| 237 | −lockup-watchdogs.txt | |
| 238 | − - info on soft and hard lockup detectors (aka nmi_watchdog). | |
| 239 | −logo.gif | |
| 240 | − - full colour GIF image of Linux logo (penguin - Tux). | |
| 241 | −logo.txt | |
| 242 | − - info on creator of above logo & site to get additional images from. | |
| 243 | −lsm.txt | |
| 244 | − - Linux Security Modules: General Security Hooks for Linux | |
| 245 | −lzo.txt | |
| 246 | − - kernel LZO decompressor input formats | |
| 247 | −m68k/ | |
| 248 | − - directory with info about Linux on Motorola 68k architecture. | |
| 249 | −mailbox.txt | |
| 250 | − - How to write drivers for the common mailbox framework (IPC). | |
| 251 | −md/ | |
| 252 | − - directory with info about Linux Software RAID | |
| 253 | −media/ | |
| 254 | − - info on media drivers: uAPI, kAPI and driver documentation. | |
| 255 | −memory-barriers.txt | |
| 256 | − - info on Linux kernel memory barriers. | |
| 257 | −memory-devices/ | |
| 258 | − - directory with info on parts like the Texas Instruments EMIF driver | |
| 259 | −memory-hotplug.txt | |
| 260 | − - Hotpluggable memory support, how to use and current status. | |
| 261 | −men-chameleon-bus.txt | |
| 262 | − - info on MEN chameleon bus. | |
| 263 | −mic/ | |
| 264 | − - Intel Many Integrated Core (MIC) architecture device driver. | |
| 265 | −mips/ | |
| 266 | − - directory with info about Linux on MIPS architecture. | |
| 267 | −misc-devices/ | |
| 268 | − - directory with info about devices using the misc dev subsystem | |
| 269 | −mmc/ | |
| 270 | − - directory with info about the MMC subsystem | |
| 271 | −mtd/ | |
| 272 | − - directory with info about memory technology devices (flash) | |
| 273 | −namespaces/ | |
| 274 | − - directory with various information about namespaces | |
| 275 | −netlabel/ | |
| 276 | − - directory with information on the NetLabel subsystem. | |
| 277 | −networking/ | |
| 278 | − - directory with info on various aspects of networking with Linux. | |
| 279 | −nfc/ | |
| 280 | − - directory relating info about Near Field Communications support. | |
| 281 | −nios2/ | |
| 282 | − - Linux on the Nios II architecture. | |
| 283 | −nommu-mmap.txt | |
| 284 | − - documentation about no-mmu memory mapping support. | |
| 285 | −numastat.txt | |
| 286 | − - info on how to read Numa policy hit/miss statistics in sysfs. | |
| 287 | −ntb.txt | |
| 288 | − - info on Non-Transparent Bridge (NTB) drivers. | |
| 289 | −nvdimm/ | |
| 290 | − - info on non-volatile devices. | |
| 291 | −nvmem/ | |
| 292 | − - info on non volatile memory framework. | |
| 293 | −output/ | |
| 294 | − - default directory where html/LaTeX/pdf files will be written. | |
| 295 | −padata.txt | |
| 296 | − - An introduction to the "padata" parallel execution API | |
| 297 | −parisc/ | |
| 298 | − - directory with info on using Linux on PA-RISC architecture. | |
| 299 | −parport-lowlevel.txt | |
| 300 | − - description and usage of the low level parallel port functions. | |
| 301 | −pcmcia/ | |
| 302 | − - info on the Linux PCMCIA driver. | |
| 303 | −percpu-rw-semaphore.txt | |
| 304 | − - RCU based read-write semaphore optimized for locking for reading | |
| 305 | −perf/ | |
| 306 | − - info about the APM X-Gene SoC Performance Monitoring Unit (PMU). | |
| 307 | −phy/ | |
| 308 | − - ino on Samsung USB 2.0 PHY adaptation layer. | |
| 309 | −phy.txt | |
| 310 | − - Description of the generic PHY framework. | |
| 311 | −pi-futex.txt | |
| 312 | − - documentation on lightweight priority inheritance futexes. | |
| 313 | −pinctrl.txt | |
| 314 | − - info on pinctrl subsystem and the PINMUX/PINCONF and drivers | |
| 315 | −platform/ | |
| 316 | − - List of supported hardware by compal and Dell laptop. | |
| 317 | −pnp.txt | |
| 318 | − - Linux Plug and Play documentation. | |
| 319 | −power/ | |
| 320 | − - directory with info on Linux PCI power management. | |
| 321 | −powerpc/ | |
| 322 | − - directory with info on using Linux with the PowerPC. | |
| 323 | −prctl/ | |
| 324 | − - directory with info on the priveledge control subsystem | |
| 325 | −preempt-locking.txt | |
| 326 | − - info on locking under a preemptive kernel. | |
| 327 | −process/ | |
| 328 | − - how to work with the mainline kernel development process. | |
| 329 | −pps/ | |
| 330 | − - directory with information on the pulse-per-second support | |
| 331 | −pti/ | |
| 332 | − - directory with info on Intel MID PTI. | |
| 333 | −ptp/ | |
| 334 | − - directory with info on support for IEEE 1588 PTP clocks in Linux. | |
| 335 | −pwm.txt | |
| 336 | − - info on the pulse width modulation driver subsystem | |
| 337 | −rapidio/ | |
| 338 | − - directory with info on RapidIO packet-based fabric interconnect | |
| 339 | −rbtree.txt | |
| 340 | − - info on what red-black trees are and what they are for. | |
| 341 | −remoteproc.txt | |
| 342 | − - info on how to handle remote processor (e.g. AMP) offloads/usage. | |
| 343 | −rfkill.txt | |
| 344 | − - info on the radio frequency kill switch subsystem/support. | |
| 345 | −robust-futex-ABI.txt | |
| 346 | − - documentation of the robust futex ABI. | |
| 347 | −robust-futexes.txt | |
| 348 | − - a description of what robust futexes are. | |
| 349 | −rpmsg.txt | |
| 350 | − - info on the Remote Processor Messaging (rpmsg) Framework | |
| 351 | −rtc.txt | |
| 352 | − - notes on how to use the Real Time Clock (aka CMOS clock) driver. | |
| 353 | −s390/ | |
| 354 | − - directory with info on using Linux on the IBM S390. | |
| 355 | −scheduler/ | |
| 356 | − - directory with info on the scheduler. | |
| 357 | −scsi/ | |
| 358 | − - directory with info on Linux scsi support. | |
| 359 | −security/ | |
| 360 | − - directory that contains security-related info | |
| 361 | −serial/ | |
| 362 | − - directory with info on the low level serial API. | |
| 363 | −sgi-ioc4.txt | |
| 364 | − - description of the SGI IOC4 PCI (multi function) device. | |
| 365 | −sh/ | |
| 366 | − - directory with info on porting Linux to a new architecture. | |
| 367 | −smsc_ece1099.txt | |
| 368 | − -info on the smsc Keyboard Scan Expansion/GPIO Expansion device. | |
| 369 | −sound/ | |
| 370 | − - directory with info on sound card support. | |
| 371 | −spi/ | |
| 372 | − - overview of Linux kernel Serial Peripheral Interface (SPI) support. | |
| 373 | −sphinx/ | |
| 374 | − - no documentation here, just files required by Sphinx toolchain. | |
| 375 | −sphinx-static/ | |
| 376 | − - no documentation here, just files required by Sphinx toolchain. | |
| 377 | −static-keys.txt | |
| 378 | − - info on how static keys allow debug code in hotpaths via patching | |
| 379 | −svga.txt | |
| 380 | − - short guide on selecting video modes at boot via VGA BIOS. | |
| 381 | −sync_file.txt | |
| 382 | − - Sync file API guide. | |
| 383 | −sysctl/ | |
| 384 | − - directory with info on the /proc/sys/* files. | |
| 385 | −target/ | |
| 386 | − - directory with info on generating TCM v4 fabric .ko modules | |
| 387 | −tee.txt | |
| 388 | − - info on the TEE subsystem and drivers | |
| 389 | −this_cpu_ops.txt | |
| 390 | − - List rationale behind and the way to use this_cpu operations. | |
| 391 | −thermal/ | |
| 392 | − - directory with information on managing thermal issues (CPU/temp) | |
| 393 | −trace/ | |
| 394 | − - directory with info on tracing technologies within linux | |
| 395 | −translations/ | |
| 396 | − - translations of this document from English to another language | |
| 397 | −unaligned-memory-access.txt | |
| 398 | − - info on how to avoid arch breaking unaligned memory access in code. | |
| 399 | −unshare.txt | |
| 400 | − - description of the Linux unshare system call. | |
| 401 | −usb/ | |
| 402 | − - directory with info regarding the Universal Serial Bus. | |
| 403 | −vfio.txt | |
| 404 | − - info on Virtual Function I/O used in guest/hypervisor instances. | |
| 405 | −video-output.txt | |
| 406 | − - sysfs class driver interface to enable/disable a video output device. | |
| 407 | −virtual/ | |
| 408 | − - directory with information on the various linux virtualizations. | |
| 409 | −vm/ | |
| 410 | − - directory with info on the Linux vm code. | |
| 411 | −w1/ | |
| 412 | − - directory with documents regarding the 1-wire (w1) subsystem. | |
| 413 | −watchdog/ | |
| 414 | − - how to auto-reboot Linux if it has "fallen and can't get up". ;-) | |
| 415 | −wimax/ | |
| 416 | − - directory with info about Intel Wireless Wimax Connections | |
| 417 | −core-api/workqueue.rst | |
| 418 | − - information on the Concurrency Managed Workqueue implementation | |
| 419 | −x86/x86_64/ | |
| 420 | − - directory with info on Linux support for AMD x86-64 (Hammer) machines. | |
| 421 | −xillybus.txt | |
| 422 | − - Overview and basic ui of xillybus driver | |
| 423 | −xtensa/ | |
| 424 | − - directory with documents relating to arch/xtensa port/implementation | |
| 425 | −xz.txt | |
| 426 | − - how to make use of the XZ data compression within linux kernel | |
| 427 | −zorro.txt | |
| 428 | − - info on writing drivers for Zorro bus devices found on Amigas. | |
| @@ -25,38 +25,3 @@ Description: · 24 unmodified lines | ||
| 25 | 25 | 4.2.2. |
| 26 | 26 | |
| 27 | 27 | The files are read only. |
| 28 | − | |
| 29 | − | |
| 30 | −What: /sys/bus/usb/drivers/usbtmc/*/TermChar | |
| 31 | −Date: August 2008 | |
| 32 | −Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | |
| 33 | −Description: | |
| 34 | − This file is the TermChar value to be sent to the USB TMC | |
| 35 | − device as described by the document, "Universal Serial Bus Test | |
| 36 | − and Measurement Class Specification | |
| 37 | − (USBTMC) Revision 1.0" as published by the USB-IF. | |
| 38 | − | |
| 39 | − Note that the TermCharEnabled file determines if this value is | |
| 40 | − sent to the device or not. | |
| 41 | − | |
| 42 | − | |
| 43 | −What: /sys/bus/usb/drivers/usbtmc/*/TermCharEnabled | |
| 44 | −Date: August 2008 | |
| 45 | −Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | |
| 46 | −Description: | |
| 47 | − This file determines if the TermChar is to be sent to the | |
| 48 | − device on every transaction or not. For more details about | |
| 49 | − this, please see the document, "Universal Serial Bus Test and | |
| 50 | − Measurement Class Specification (USBTMC) Revision 1.0" as | |
| 51 | − published by the USB-IF. | |
| 52 | − | |
| 53 | − | |
| 54 | −What: /sys/bus/usb/drivers/usbtmc/*/auto_abort | |
| 55 | −Date: August 2008 | |
| 56 | −Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | |
| 57 | −Description: | |
| 58 | − This file determines if the transaction of the USB TMC | |
| 59 | − device is to be automatically aborted if there is any error. | |
| 60 | − For more details about this, please see the document, | |
| 61 | − "Universal Serial Bus Test and Measurement Class Specification | |
| 62 | − (USBTMC) Revision 1.0" as published by the USB-IF. | |
| @@ -0,0 +1,41 @@ | ||
| 1 | +What: /config/stp-policy/<device>:p_sys-t.<policy>/<node>/uuid | |
| 2 | +Date: June 2018 | |
| 3 | +KernelVersion: 4.19 | |
| 4 | +Description: | |
| 5 | + UUID source identifier string, RW. | |
| 6 | + Default value is randomly generated at the mkdir <node> time. | |
| 7 | + Data coming from trace sources that use this <node> will be | |
| 8 | + tagged with this UUID in the MIPI SyS-T packet stream, to | |
| 9 | + allow the decoder to discern between different sources | |
| 10 | + within the same master/channel range, and identify the | |
| 11 | + higher level decoders that may be needed for each source. | |
| 12 | + | |
| 13 | +What: /config/stp-policy/<device>:p_sys-t.<policy>/<node>/do_len | |
| 14 | +Date: June 2018 | |
| 15 | +KernelVersion: 4.19 | |
| 16 | +Description: | |
| 17 | + Include payload length in the MIPI SyS-T header, boolean. | |
| 18 | + If enabled, the SyS-T protocol encoder will include payload | |
| 19 | + length in each packet's metadata. This is normally redundant | |
| 20 | + if the underlying transport protocol supports marking message | |
| 21 | + boundaries (which STP does), so this is off by default. | |
| 22 | + | |
| 23 | +What: /config/stp-policy/<device>:p_sys-t.<policy>/<node>/ts_interval | |
| 24 | +Date: June 2018 | |
| 25 | +KernelVersion: 4.19 | |
| 26 | +Description: | |
| 27 | + Time interval in milliseconds. Include a timestamp in the | |
| 28 | + MIPI SyS-T packet metadata, if this many milliseconds have | |
| 29 | + passed since the previous packet from this source. Zero is | |
| 30 | + the default and stands for "never send the timestamp". | |
| 31 | + | |
| 32 | +What: /config/stp-policy/<device>:p_sys-t.<policy>/<node>/clocksync_interval | |
| 33 | +Date: June 2018 | |
| 34 | +KernelVersion: 4.19 | |
| 35 | +Description: | |
| 36 | + Time interval in milliseconds. Send a CLOCKSYNC packet if | |
| 37 | + this many milliseconds have passed since the previous | |
| 38 | + CLOCKSYNC packet from this source. Zero is the default and | |
| 39 | + stands for "never send the CLOCKSYNC". It makes sense to | |
| 40 | + use this option with sources that generate constant and/or | |
| 41 | + periodic data, like stm_heartbeat. | |
| @@ -12,6 +12,10 @@ Date: Dec 2014 · 11 unmodified lines | ||
| 12 | 12 | KernelVersion: 4.0 |
| 13 | 13 | Description: Control descriptors |
| 14 | 14 | |
| 15 | + All attributes read only: | |
| 16 | + bInterfaceNumber - USB interface number for this | |
| 17 | + streaming interface | |
| 18 | + | |
| 15 | 19 | What: /config/usb-gadget/gadget/functions/uvc.name/control/class |
| 16 | 20 | Date: Dec 2014 |
| 17 | 21 | KernelVersion: 4.0 |
| @@ -109,6 +113,10 @@ Date: Dec 2014 · 91 unmodified lines | ||
| 109 | 113 | KernelVersion: 4.0 |
| 110 | 114 | Description: Streaming descriptors |
| 111 | 115 | |
| 116 | + All attributes read only: | |
| 117 | + bInterfaceNumber - USB interface number for this | |
| 118 | + streaming interface | |
| 119 | + | |
| 112 | 120 | What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class |
| 113 | 121 | Date: Dec 2014 |
| 114 | 122 | KernelVersion: 4.0 |
| @@ -160,6 +168,10 @@ Description: Specific MJPEG format descriptors · 45 unmodified lines | ||
| 160 | 168 | |
| 161 | 169 | All attributes read only, |
| 162 | 170 | except bmaControls and bDefaultFrameIndex: |
| 171 | + bFormatIndex - unique id for this format descriptor; | |
| 172 | + only defined after parent header is | |
| 173 | + linked into the streaming class; | |
| 174 | + read-only | |
| 163 | 175 | bmaControls - this format's data for bmaControls in |
| 164 | 176 | the streaming header |
| 165 | 177 | bmInterfaceFlags - specifies interlace information, |
| @@ -177,6 +189,10 @@ Date: Dec 2014 · 11 unmodified lines | ||
| 177 | 189 | KernelVersion: 4.0 |
| 178 | 190 | Description: Specific MJPEG frame descriptors |
| 179 | 191 | |
| 192 | + bFrameIndex - unique id for this framedescriptor; | |
| 193 | + only defined after parent format is | |
| 194 | + linked into the streaming header; | |
| 195 | + read-only | |
| 180 | 196 | dwFrameInterval - indicates how frame interval can be |
| 181 | 197 | programmed; a number of values |
| 182 | 198 | separated by newline can be specified |
| @@ -204,6 +220,10 @@ Date: Dec 2014 · 21 unmodified lines | ||
| 204 | 220 | KernelVersion: 4.0 |
| 205 | 221 | Description: Specific uncompressed format descriptors |
| 206 | 222 | |
| 223 | + bFormatIndex - unique id for this format descriptor; | |
| 224 | + only defined after parent header is | |
| 225 | + linked into the streaming class; | |
| 226 | + read-only | |
| 207 | 227 | bmaControls - this format's data for bmaControls in |
| 208 | 228 | the streaming header |
| 209 | 229 | bmInterfaceFlags - specifies interlace information, |
| @@ -224,6 +244,10 @@ Date: Dec 2014 · 14 unmodified lines | ||
| 224 | 244 | KernelVersion: 4.0 |
| 225 | 245 | Description: Specific uncompressed frame descriptors |
| 226 | 246 | |
| 247 | + bFrameIndex - unique id for this framedescriptor; | |
| 248 | + only defined after parent format is | |
| 249 | + linked into the streaming header; | |
| 250 | + read-only | |
| 227 | 251 | dwFrameInterval - indicates how frame interval can be |
| 228 | 252 | programmed; a number of values |
| 229 | 253 | separated by newline can be specified |
| @@ -199,7 +199,7 @@ Description: · 198 unmodified lines | ||
| 199 | 199 | |
| 200 | 200 | What: /sys/bus/iio/devices/iio:deviceX/in_positionrelative_x_raw |
| 201 | 201 | What: /sys/bus/iio/devices/iio:deviceX/in_positionrelative_y_raw |
| 202 | −KernelVersion: 4.18 | |
| 202 | +KernelVersion: 4.19 | |
| 203 | 203 | Contact: linux-iio@vger.kernel.org |
| 204 | 204 | Description: |
| 205 | 205 | Relative position in direction x or y on a pad (may be |
| @@ -323,3 +323,27 @@ Description: · 322 unmodified lines | ||
| 323 | 323 | |
| 324 | 324 | This is similar to /sys/bus/pci/drivers_autoprobe, but |
| 325 | 325 | affects only the VFs associated with a specific PF. |
| 326 | + | |
| 327 | +What: /sys/bus/pci/devices/.../p2pmem/size | |
| 328 | +Date: November 2017 | |
| 329 | +Contact: Logan Gunthorpe <logang@deltatee.com> | |
| 330 | +Description: | |
| 331 | + If the device has any Peer-to-Peer memory registered, this | |
| 332 | + file contains the total amount of memory that the device | |
| 333 | + provides (in decimal). | |
| 334 | + | |
| 335 | +What: /sys/bus/pci/devices/.../p2pmem/available | |
| 336 | +Date: November 2017 | |
| 337 | +Contact: Logan Gunthorpe <logang@deltatee.com> | |
| 338 | +Description: | |
| 339 | + If the device has any Peer-to-Peer memory registered, this | |
| 340 | + file contains the amount of memory that has not been | |
| 341 | + allocated (in decimal). | |
| 342 | + | |
| 343 | +What: /sys/bus/pci/devices/.../p2pmem/published | |
| 344 | +Date: November 2017 | |
| 345 | +Contact: Logan Gunthorpe <logang@deltatee.com> | |
| 346 | +Description: | |
| 347 | + If the device has any Peer-to-Peer memory registered, this | |
| 348 | + file contains a '1' if the memory has been published for | |
| 349 | + use outside the driver that owns the device. | |
| @@ -189,6 +189,16 @@ Description: · 188 unmodified lines | ||
| 189 | 189 | The file will read "hotplug", "wired" and "not used" if the |
| 190 | 190 | information is available, and "unknown" otherwise. |
| 191 | 191 | |
| 192 | +What: /sys/bus/usb/devices/.../(hub interface)/portX/location | |
| 193 | +Date: October 2018 | |
| 194 | +Contact: Bjørn Mork <bjorn@mork.no> | |
| 195 | +Description: | |
| 196 | + Some platforms provide usb port physical location through | |
| 197 | + firmware. This is used by the kernel to pair up logical ports | |
| 198 | + mapping to the same physical connector. The attribute exposes the | |
| 199 | + raw location value as a hex integer. | |
| 200 | + | |
| 201 | + | |
| 192 | 202 | What: /sys/bus/usb/devices/.../(hub interface)/portX/quirks |
| 193 | 203 | Date: May 2018 |
| 194 | 204 | Contact: Nicolas Boichat <drinkcat@chromium.org> |
| @@ -219,7 +229,14 @@ Description: · 24 unmodified lines | ||
| 219 | 229 | ports and report them to the kernel. This attribute is to expose |
| 220 | 230 | the number of over-current situation occurred on a specific port |
| 221 | 231 | to user space. This file will contain an unsigned 32 bit value |
| 222 | − which wraps to 0 after its maximum is reached. | |
| 232 | + which wraps to 0 after its maximum is reached. This file supports | |
| 233 | + poll() for monitoring changes to this value in user space. | |
| 234 | + | |
| 235 | + Any time this value changes the corresponding hub device will send a | |
| 236 | + udev event with the following attributes: | |
| 237 | + | |
| 238 | + OVER_CURRENT_PORT=/sys/bus/usb/devices/.../(hub interface)/portX | |
| 239 | + OVER_CURRENT_COUNT=[current value of this sysfs attribute] | |
| 223 | 240 | |
| 224 | 241 | What: /sys/bus/usb/devices/.../(hub interface)/portX/usb3_lpm_permit |
| 225 | 242 | Date: November 2015 |
| @@ -0,0 +1,21 @@ | ||
| 1 | +What: /sys/bus/vmbus/devices/.../driver_override | |
| 2 | +Date: August 2019 | |
| 3 | +Contact: Stephen Hemminger <sthemmin@microsoft.com> | |
| 4 | +Description: | |
| 5 | + This file allows the driver for a device to be specified which | |
| 6 | + will override standard static and dynamic ID matching. When | |
| 7 | + specified, only a driver with a name matching the value written | |
| 8 | + to driver_override will have an opportunity to bind to the | |
| 9 | + device. The override is specified by writing a string to the | |
| 10 | + driver_override file (echo uio_hv_generic > driver_override) and | |
| 11 | + may be cleared with an empty string (echo > driver_override). | |
| 12 | + This returns the device to standard matching rules binding. | |
| 13 | + Writing to driver_override does not automatically unbind the | |
| 14 | + device from its current driver or make any attempt to | |
| 15 | + automatically load the specified driver. If no driver with a | |
| 16 | + matching name is currently loaded in the kernel, the device | |
| 17 | + will not bind to any driver. This also allows devices to | |
| 18 | + opt-out of driver binding using a driver_override name such as | |
| 19 | + "none". Only a single driver may be specified in the override, | |
| 20 | + there is no support for parsing delimiters. | |
| 21 | + | |
| @@ -1,27 +0,0 @@ | ||
| 1 | −sysfs interface for the S6E63M0 AMOLED LCD panel driver | |
| 2 | −------------------------------------------------------- | |
| 3 | − | |
| 4 | −What: /sys/class/lcd/<lcd>/gamma_mode | |
| 5 | −Date: May, 2010 | |
| 6 | −KernelVersion: v2.6.35 | |
| 7 | −Contact: dri-devel@lists.freedesktop.org | |
| 8 | −Description: | |
| 9 | − (RW) Read or write the gamma mode. Following three modes are | |
| 10 | − supported: | |
| 11 | − 0 - gamma value 2.2, | |
| 12 | − 1 - gamma value 1.9 and | |
| 13 | − 2 - gamma value 1.7. | |
| 14 | − | |
| 15 | − | |
| 16 | −What: /sys/class/lcd/<lcd>/gamma_table | |
| 17 | −Date: May, 2010 | |
| 18 | −KernelVersion: v2.6.35 | |
| 19 | −Contact: dri-devel@lists.freedesktop.org | |
| 20 | −Description: | |
| 21 | − (RO) Displays the size of the gamma table i.e. the number of | |
| 22 | − gamma modes available. | |
| 23 | − | |
| 24 | −This is a backlight lcd driver. These interfaces are an extension to the API | |
| 25 | −documented in Documentation/ABI/testing/sysfs-class-lcd and in | |
| 26 | −Documentation/ABI/stable/sysfs-class-backlight (under | |
| 27 | −/sys/class/backlight/<backlight>/). | |
| @@ -0,0 +1,22 @@ | ||
| 1 | +What: /sys/class/leds/<led>/hw_pattern | |
| 2 | +Date: September 2018 | |
| 3 | +KernelVersion: 4.20 | |
| 4 | +Description: | |
| 5 | + Specify a hardware pattern for the SC27XX LED. For the SC27XX | |
| 6 | + LED controller, it only supports 4 stages to make a single | |
| 7 | + hardware pattern, which is used to configure the rise time, | |
| 8 | + high time, fall time and low time for the breathing mode. | |
| 9 | + | |
| 10 | + For the breathing mode, the SC27XX LED only expects one brightness | |
| 11 | + for the high stage. To be compatible with the hardware pattern | |
| 12 | + format, we should set brightness as 0 for rise stage, fall | |
| 13 | + stage and low stage. | |
| 14 | + | |
| 15 | + Min stage duration: 125 ms | |
| 16 | + Max stage duration: 31875 ms | |
| 17 | + | |
| 18 | + Since the stage duration step is 125 ms, the duration should be | |
| 19 | + a multiplier of 125, like 125ms, 250ms, 375ms, 500ms ... 31875ms. | |
| 20 | + | |
| 21 | + Thus the format of the hardware pattern values should be: | |
| 22 | + "0 rise_duration brightness high_duration 0 fall_duration 0 low_duration". | |
| @@ -0,0 +1,82 @@ | ||
| 1 | +What: /sys/class/leds/<led>/pattern | |
| 2 | +Date: September 2018 | |
| 3 | +KernelVersion: 4.20 | |
| 4 | +Description: | |
| 5 | + Specify a software pattern for the LED, that supports altering | |
| 6 | + the brightness for the specified duration with one software | |
| 7 | + timer. It can do gradual dimming and step change of brightness. | |
| 8 | + | |
| 9 | + The pattern is given by a series of tuples, of brightness and | |
| 10 | + duration (ms). The LED is expected to traverse the series and | |
| 11 | + each brightness value for the specified duration. Duration of | |
| 12 | + 0 means brightness should immediately change to new value, and | |
| 13 | + writing malformed pattern deactivates any active one. | |
| 14 | + | |
| 15 | + 1. For gradual dimming, the dimming interval now is set as 50 | |
| 16 | + milliseconds. So the tuple with duration less than dimming | |
| 17 | + interval (50ms) is treated as a step change of brightness, | |
| 18 | + i.e. the subsequent brightness will be applied without adding | |
| 19 | + intervening dimming intervals. | |
| 20 | + | |
| 21 | + The gradual dimming format of the software pattern values should be: | |
| 22 | + "brightness_1 duration_1 brightness_2 duration_2 brightness_3 | |
| 23 | + duration_3 ...". For example: | |
| 24 | + | |
| 25 | + echo 0 1000 255 2000 > pattern | |
| 26 | + | |
| 27 | + It will make the LED go gradually from zero-intensity to max (255) | |
| 28 | + intensity in 1000 milliseconds, then back to zero intensity in 2000 | |
| 29 | + milliseconds: | |
| 30 | + | |
| 31 | + LED brightness | |
| 32 | + ^ | |
| 33 | + 255-| / \ / \ / | |
| 34 | + | / \ / \ / | |
| 35 | + | / \ / \ / | |
| 36 | + | / \ / \ / | |
| 37 | + 0-| / \/ \/ | |
| 38 | + +---0----1----2----3----4----5----6------------> time (s) | |
| 39 | + | |
| 40 | + 2. To make the LED go instantly from one brightness value to another, | |
| 41 | + we should use zero-time lengths (the brightness must be same as | |
| 42 | + the previous tuple's). So the format should be: | |
| 43 | + "brightness_1 duration_1 brightness_1 0 brightness_2 duration_2 | |
| 44 | + brightness_2 0 ...". For example: | |
| 45 | + | |
| 46 | + echo 0 1000 0 0 255 2000 255 0 > pattern | |
| 47 | + | |
| 48 | + It will make the LED stay off for one second, then stay at max brightness | |
| 49 | + for two seconds: | |
| 50 | + | |
| 51 | + LED brightness | |
| 52 | + ^ | |
| 53 | + 255-| +---------+ +---------+ | |
| 54 | + | | | | | | |
| 55 | + | | | | | | |
| 56 | + | | | | | | |
| 57 | + 0-| -----+ +----+ +---- | |
| 58 | + +---0----1----2----3----4----5----6------------> time (s) | |
| 59 | + | |
| 60 | +What: /sys/class/leds/<led>/hw_pattern | |
| 61 | +Date: September 2018 | |
| 62 | +KernelVersion: 4.20 | |
| 63 | +Description: | |
| 64 | + Specify a hardware pattern for the LED, for LED hardware that | |
| 65 | + supports autonomously controlling brightness over time, according | |
| 66 | + to some preprogrammed hardware patterns. It deactivates any active | |
| 67 | + software pattern. | |
| 68 | + | |
| 69 | + Since different LED hardware can have different semantics of | |
| 70 | + hardware patterns, each driver is expected to provide its own | |
| 71 | + description for the hardware patterns in their ABI documentation | |
| 72 | + file. | |
| 73 | + | |
| 74 | +What: /sys/class/leds/<led>/repeat | |
| 75 | +Date: September 2018 | |
| 76 | +KernelVersion: 4.20 | |
| 77 | +Description: | |
| 78 | + Specify a pattern repeat number. -1 means repeat indefinitely, | |
| 79 | + other negative numbers and number 0 are invalid. | |
| 80 | + | |
| 81 | + This file will always return the originally written repeat | |
| 82 | + number. | |
| @@ -91,6 +91,24 @@ Description: · 90 unmodified lines | ||
| 91 | 91 | stacked (e.g: VLAN interfaces) but still have the same MAC |
| 92 | 92 | address as their parent device. |
| 93 | 93 | |
| 94 | +What: /sys/class/net/<iface>/dev_port | |
| 95 | +Date: February 2014 | |
| 96 | +KernelVersion: 3.15 | |
| 97 | +Contact: netdev@vger.kernel.org | |
| 98 | +Description: | |
| 99 | + Indicates the port number of this network device, formatted | |
| 100 | + as a decimal value. Some NICs have multiple independent ports | |
| 101 | + on the same PCI bus, device and function. This attribute allows | |
| 102 | + userspace to distinguish the respective interfaces. | |
| 103 | + | |
| 104 | + Note: some device drivers started to use 'dev_id' for this | |
| 105 | + purpose since long before 3.15 and have not adopted the new | |
| 106 | + attribute ever since. To query the port number, some tools look | |
| 107 | + exclusively at 'dev_port', while others only consult 'dev_id'. | |
| 108 | + If a network device has multiple client adapter ports as | |
| 109 | + described in the previous paragraph and does not set this | |
| 110 | + attribute to its port number, it's a kernel bug. | |
| 111 | + | |
| 94 | 112 | What: /sys/class/net/<iface>/dormant |
| 95 | 113 | Date: March 2006 |
| 96 | 114 | KernelVersion: 2.6.17 |
| @@ -117,7 +135,7 @@ Description: · 20 unmodified lines | ||
| 117 | 135 | full: full duplex |
| 118 | 136 | |
| 119 | 137 | Note: This attribute is only valid for interfaces that implement |
| 120 | − the ethtool get_settings method (mostly Ethernet). | |
| 138 | + the ethtool get_link_ksettings method (mostly Ethernet). | |
| 121 | 139 | |
| 122 | 140 | What: /sys/class/net/<iface>/flags |
| 123 | 141 | Date: April 2005 |
| @@ -224,7 +242,7 @@ Description: · 100 unmodified lines | ||
| 224 | 242 | an integer representing the link speed in Mbits/sec. |
| 225 | 243 | |
| 226 | 244 | Note: this attribute is only valid for interfaces that implement |
| 227 | − the ethtool get_settings method (mostly Ethernet ). | |
| 245 | + the ethtool get_link_ksettings method (mostly Ethernet). | |
| 228 | 246 | |
| 229 | 247 | What: /sys/class/net/<iface>/tx_queue_len |
| 230 | 248 | Date: April 2005 |
| @@ -0,0 +1,7 @@ | ||
| 1 | +What: /sys/class/net/<iface>/tagging | |
| 2 | +Date: August 2018 | |
| 3 | +KernelVersion: 4.20 | |
| 4 | +Contact: netdev@vger.kernel.org | |
| 5 | +Description: | |
| 6 | + String indicating the type of tagging protocol used by the | |
| 7 | + DSA slave network device. | |
| @@ -121,7 +121,22 @@ What: /sys/fs/f2fs/<disk>/idle_interval · 120 unmodified lines | ||
| 121 | 121 | Date: January 2016 |
| 122 | 122 | Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> |
| 123 | 123 | Description: |
| 124 | − Controls the idle timing. | |
| 124 | + Controls the idle timing for all paths other than | |
| 125 | + discard and gc path. | |
| 126 | + | |
| 127 | +What: /sys/fs/f2fs/<disk>/discard_idle_interval | |
| 128 | +Date: September 2018 | |
| 129 | +Contact: "Chao Yu" <yuchao0@huawei.com> | |
| 130 | +Contact: "Sahitya Tummala" <stummala@codeaurora.org> | |
| 131 | +Description: | |
| 132 | + Controls the idle timing for discard path. | |
| 133 | + | |
| 134 | +What: /sys/fs/f2fs/<disk>/gc_idle_interval | |
| 135 | +Date: September 2018 | |
| 136 | +Contact: "Chao Yu" <yuchao0@huawei.com> | |
| 137 | +Contact: "Sahitya Tummala" <stummala@codeaurora.org> | |
| 138 | +Description: | |
| 139 | + Controls the idle timing for gc path. | |
| 125 | 140 | |
| 126 | 141 | What: /sys/fs/f2fs/<disk>/iostat_enable |
| 127 | 142 | Date: August 2017 |
| @@ -0,0 +1,35 @@ | ||
| 1 | +What: /sys/devices/platform/lg-laptop/reader_mode | |
| 2 | +Date: October 2018 | |
| 3 | +KernelVersion: 4.20 | |
| 4 | +Contact: "Matan Ziv-Av <matan@svgalib.org> | |
| 5 | +Description: | |
| 6 | + Control reader mode. 1 means on, 0 means off. | |
| 7 | + | |
| 8 | +What: /sys/devices/platform/lg-laptop/fn_lock | |
| 9 | +Date: October 2018 | |
| 10 | +KernelVersion: 4.20 | |
| 11 | +Contact: "Matan Ziv-Av <matan@svgalib.org> | |
| 12 | +Description: | |
| 13 | + Control FN lock mode. 1 means on, 0 means off. | |
| 14 | + | |
| 15 | +What: /sys/devices/platform/lg-laptop/battery_care_limit | |
| 16 | +Date: October 2018 | |
| 17 | +KernelVersion: 4.20 | |
| 18 | +Contact: "Matan Ziv-Av <matan@svgalib.org> | |
| 19 | +Description: | |
| 20 | + Maximal battery charge level. Accepted values are 80 or 100. | |
| 21 | + | |
| 22 | +What: /sys/devices/platform/lg-laptop/fan_mode | |
| 23 | +Date: October 2018 | |
| 24 | +KernelVersion: 4.20 | |
| 25 | +Contact: "Matan Ziv-Av <matan@svgalib.org> | |
| 26 | +Description: | |
| 27 | + Control fan mode. 1 for performance mode, 0 for silent mode. | |
| 28 | + | |
| 29 | +What: /sys/devices/platform/lg-laptop/usb_charge | |
| 30 | +Date: October 2018 | |
| 31 | +KernelVersion: 4.20 | |
| 32 | +Contact: "Matan Ziv-Av <matan@svgalib.org> | |
| 33 | +Description: | |
| 34 | + Control USB port charging when device is turned off. | |
| 35 | + 1 means on, 0 means off. | |
| @@ -99,7 +99,7 @@ Description: · 98 unmodified lines | ||
| 99 | 99 | this file, the suspend image will be as small as possible. |
| 100 | 100 | |
| 101 | 101 | Reading from this file will display the current image size |
| 102 | − limit, which is set to 500 MB by default. | |
| 102 | + limit, which is set to around 2/5 of available RAM by default. | |
| 103 | 103 | |
| 104 | 104 | What: /sys/power/pm_trace |
| 105 | 105 | Date: August 2006 |
| @@ -1,26 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - this file | |
| 3 | −acpi-info.txt | |
| 4 | − - info on how PCI host bridges are represented in ACPI | |
| 5 | −MSI-HOWTO.txt | |
| 6 | − - the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ. | |
| 7 | −PCIEBUS-HOWTO.txt | |
| 8 | − - a guide describing the PCI Express Port Bus driver | |
| 9 | −pci-error-recovery.txt | |
| 10 | − - info on PCI error recovery | |
| 11 | −pci-iov-howto.txt | |
| 12 | − - the PCI Express I/O Virtualization HOWTO | |
| 13 | −pci.txt | |
| 14 | − - info on the PCI subsystem for device driver authors | |
| 15 | −pcieaer-howto.txt | |
| 16 | − - the PCI Express Advanced Error Reporting Driver Guide HOWTO | |
| 17 | −endpoint/pci-endpoint.txt | |
| 18 | − - guide to add endpoint controller driver and endpoint function driver. | |
| 19 | −endpoint/pci-endpoint-cfs.txt | |
| 20 | − - guide to use configfs to configure the PCI endpoint function. | |
| 21 | −endpoint/pci-test-function.txt | |
| 22 | − - specification of *PCI test* function device. | |
| 23 | −endpoint/pci-test-howto.txt | |
| 24 | − - userguide for PCI endpoint test function. | |
| 25 | −endpoint/function/binding/ | |
| 26 | − - binding documentation for PCI endpoint function | |
| @@ -99,17 +99,20 @@ Note that the devices listed here correspond to the value populated in 1.4 above · 98 unmodified lines | ||
| 99 | 99 | 2.2 Using Endpoint Test function Device |
| 100 | 100 | |
| 101 | 101 | pcitest.sh added in tools/pci/ can be used to run all the default PCI endpoint |
| 102 | −tests. Before pcitest.sh can be used pcitest.c should be compiled using the | |
| 103 | −following commands. | |
| 102 | +tests. To compile this tool the following commands should be used: | |
| 104 | 103 | |
| 105 | − cd <kernel-dir> | |
| 106 | − make headers_install ARCH=arm | |
| 107 | − arm-linux-gnueabihf-gcc -Iusr/include tools/pci/pcitest.c -o pcitest | |
| 108 | − cp pcitest <rootfs>/usr/sbin/ | |
| 109 | − cp tools/pci/pcitest.sh <rootfs> | |
| 104 | + # cd <kernel-dir> | |
| 105 | + # make -C tools/pci | |
| 106 | + | |
| 107 | +or if you desire to compile and install in your system: | |
| 108 | + | |
| 109 | + # cd <kernel-dir> | |
| 110 | + # make -C tools/pci install | |
| 111 | + | |
| 112 | +The tool and script will be located in <rootfs>/usr/bin/ | |
| 110 | 113 | |
| 111 | 114 | 2.2.1 pcitest.sh Output |
| 112 | − # ./pcitest.sh | |
| 115 | + # pcitest.sh | |
| 113 | 116 | BAR tests |
| 114 | 117 | |
| 115 | 118 | BAR0: OKAY |
| @@ -110,7 +110,7 @@ The actual steps taken by a platform to recover from a PCI error · 109 unmodified lines | ||
| 110 | 110 | event will be platform-dependent, but will follow the general |
| 111 | 111 | sequence described below. |
| 112 | 112 | |
| 113 | −STEP 0: Error Event: ERR_NONFATAL | |
| 113 | +STEP 0: Error Event | |
| 114 | 114 | ------------------- |
| 115 | 115 | A PCI bus error is detected by the PCI hardware. On powerpc, the slot |
| 116 | 116 | is isolated, in that all I/O is blocked: all reads return 0xffffffff, |
| @@ -228,7 +228,13 @@ proceeds to either STEP3 (Link Reset) or to STEP 5 (Resume Operations). · 111 unmodified lines | ||
| 228 | 228 | If any driver returned PCI_ERS_RESULT_NEED_RESET, then the platform |
| 229 | 229 | proceeds to STEP 4 (Slot Reset) |
| 230 | 230 | |
| 231 | −STEP 3: Slot Reset | |
| 231 | +STEP 3: Link Reset | |
| 232 | +------------------ | |
| 233 | +The platform resets the link. This is a PCI-Express specific step | |
| 234 | +and is done whenever a fatal error has been detected that can be | |
| 235 | +"solved" by resetting the link. | |
| 236 | + | |
| 237 | +STEP 4: Slot Reset | |
| 232 | 238 | ------------------ |
| 233 | 239 | |
| 234 | 240 | In response to a return value of PCI_ERS_RESULT_NEED_RESET, the |
| @@ -314,7 +320,7 @@ Failure). · 79 unmodified lines | ||
| 314 | 320 | >>> However, it probably should. |
| 315 | 321 | |
| 316 | 322 | |
| 317 | −STEP 4: Resume Operations | |
| 323 | +STEP 5: Resume Operations | |
| 318 | 324 | ------------------------- |
| 319 | 325 | The platform will call the resume() callback on all affected device |
| 320 | 326 | drivers if all drivers on the segment have returned |
| @@ -326,7 +332,7 @@ a result code. · 5 unmodified lines | ||
| 326 | 332 | At this point, if a new error happens, the platform will restart |
| 327 | 333 | a new error recovery sequence. |
| 328 | 334 | |
| 329 | −STEP 5: Permanent Failure | |
| 335 | +STEP 6: Permanent Failure | |
| 330 | 336 | ------------------------- |
| 331 | 337 | A "permanent failure" has occurred, and the platform cannot recover |
| 332 | 338 | the device. The platform will call error_detected() with a |
| @@ -349,27 +355,6 @@ errors. See the discussion in powerpc/eeh-pci-error-recovery.txt · 16 unmodified lines | ||
| 349 | 355 | for additional detail on real-life experience of the causes of |
| 350 | 356 | software errors. |
| 351 | 357 | |
| 352 | −STEP 0: Error Event: ERR_FATAL | |
| 353 | −------------------- | |
| 354 | −PCI bus error is detected by the PCI hardware. On powerpc, the slot is | |
| 355 | −isolated, in that all I/O is blocked: all reads return 0xffffffff, all | |
| 356 | −writes are ignored. | |
| 357 | − | |
| 358 | −STEP 1: Remove devices | |
| 359 | −-------------------- | |
| 360 | −Platform removes the devices depending on the error agent, it could be | |
| 361 | −this port for all subordinates or upstream component (likely downstream | |
| 362 | −port) | |
| 363 | − | |
| 364 | −STEP 2: Reset link | |
| 365 | −-------------------- | |
| 366 | −The platform resets the link. This is a PCI-Express specific step and is | |
| 367 | −done whenever a fatal error has been detected that can be "solved" by | |
| 368 | −resetting the link. | |
| 369 | − | |
| 370 | −STEP 3: Re-enumerate the devices | |
| 371 | −-------------------- | |
| 372 | −Initiates the re-enumeration. | |
| 373 | 358 | |
| 374 | 359 | Conclusion; General Remarks |
| 375 | 360 | --------------------------- |
| @@ -1,34 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - This file | |
| 3 | −arrayRCU.txt | |
| 4 | − - Using RCU to Protect Read-Mostly Arrays | |
| 5 | −checklist.txt | |
| 6 | − - Review Checklist for RCU Patches | |
| 7 | −listRCU.txt | |
| 8 | − - Using RCU to Protect Read-Mostly Linked Lists | |
| 9 | −lockdep.txt | |
| 10 | − - RCU and lockdep checking | |
| 11 | −lockdep-splat.txt | |
| 12 | − - RCU Lockdep splats explained. | |
| 13 | −NMI-RCU.txt | |
| 14 | − - Using RCU to Protect Dynamic NMI Handlers | |
| 15 | −rcu_dereference.txt | |
| 16 | − - Proper care and feeding of return values from rcu_dereference() | |
| 17 | −rcubarrier.txt | |
| 18 | − - RCU and Unloadable Modules | |
| 19 | −rculist_nulls.txt | |
| 20 | − - RCU list primitives for use with SLAB_TYPESAFE_BY_RCU | |
| 21 | −rcuref.txt | |
| 22 | − - Reference-count design for elements of lists/arrays protected by RCU | |
| 23 | −rcu.txt | |
| 24 | − - RCU Concepts | |
| 25 | −RTFP.txt | |
| 26 | − - List of RCU papers (bibliography) going back to 1980. | |
| 27 | −stallwarn.txt | |
| 28 | − - RCU CPU stall warnings (module parameter rcu_cpu_stall_suppress) | |
| 29 | −torture.txt | |
| 30 | − - RCU Torture Test Operation (CONFIG_RCU_TORTURE_TEST) | |
| 31 | −UP.txt | |
| 32 | − - RCU on Uniprocessor Systems | |
| 33 | −whatisRCU.txt | |
| 34 | − - What is RCU? | |
| @@ -1227,9 +1227,11 @@ to overflow the counter, this approach corrects the · 1226 unmodified lines | ||
| 1227 | 1227 | CPU enters the idle loop from process context. |
| 1228 | 1228 | |
| 1229 | 1229 | </p><p>The <tt>->dynticks</tt> field counts the corresponding |
| 1230 | −CPU's transitions to and from dyntick-idle mode, so that this counter | |
| 1231 | −has an even value when the CPU is in dyntick-idle mode and an odd | |
| 1232 | −value otherwise. | |
| 1230 | +CPU's transitions to and from either dyntick-idle or user mode, so | |
| 1231 | +that this counter has an even value when the CPU is in dyntick-idle | |
| 1232 | +mode or user mode and an odd value otherwise. The transitions to/from | |
| 1233 | +user mode need to be counted for user mode adaptive-ticks support | |
| 1234 | +(see timers/NO_HZ.txt). | |
| 1233 | 1235 | |
| 1234 | 1236 | </p><p>The <tt>->rcu_need_heavy_qs</tt> field is used |
| 1235 | 1237 | to record the fact that the RCU core code would really like to |
| @@ -1372,8 +1374,7 @@ that is, if the CPU is currently idle. · 136 unmodified lines | ||
| 1372 | 1374 | Accessor Functions</a></h3> |
| 1373 | 1375 | |
| 1374 | 1376 | <p>The following listing shows the |
| 1375 | −<tt>rcu_get_root()</tt>, <tt>rcu_for_each_node_breadth_first</tt>, | |
| 1376 | −<tt>rcu_for_each_nonleaf_node_breadth_first()</tt>, and | |
| 1377 | +<tt>rcu_get_root()</tt>, <tt>rcu_for_each_node_breadth_first</tt> and | |
| 1377 | 1378 | <tt>rcu_for_each_leaf_node()</tt> function and macros: |
| 1378 | 1379 | |
| 1379 | 1380 | <pre> |
| @@ -1386,13 +1387,9 @@ Accessor Functions</a></h3> · 6 unmodified lines | ||
| 1386 | 1387 | 7 for ((rnp) = &(rsp)->node[0]; \ |
| 1387 | 1388 | 8 (rnp) < &(rsp)->node[NUM_RCU_NODES]; (rnp)++) |
| 1388 | 1389 | 9 |
| 1389 | − 10 #define rcu_for_each_nonleaf_node_breadth_first(rsp, rnp) \ | |
| 1390 | − 11 for ((rnp) = &(rsp)->node[0]; \ | |
| 1391 | − 12 (rnp) < (rsp)->level[NUM_RCU_LVLS - 1]; (rnp)++) | |
| 1392 | − 13 | |
| 1393 | − 14 #define rcu_for_each_leaf_node(rsp, rnp) \ | |
| 1394 | − 15 for ((rnp) = (rsp)->level[NUM_RCU_LVLS - 1]; \ | |
| 1395 | − 16 (rnp) < &(rsp)->node[NUM_RCU_NODES]; (rnp)++) | |
| 1390 | + 10 #define rcu_for_each_leaf_node(rsp, rnp) \ | |
| 1391 | + 11 for ((rnp) = (rsp)->level[NUM_RCU_LVLS - 1]; \ | |
| 1392 | + 12 (rnp) < &(rsp)->node[NUM_RCU_NODES]; (rnp)++) | |
| 1396 | 1393 | </pre> |
| 1397 | 1394 | |
| 1398 | 1395 | <p>The <tt>rcu_get_root()</tt> simply returns a pointer to the |
| @@ -1405,10 +1402,7 @@ macro takes advantage of the layout of the <tt>rcu_node</tt> · 6 unmodified lines | ||
| 1405 | 1402 | structures in the <tt>rcu_state</tt> structure's |
| 1406 | 1403 | <tt>->node[]</tt> array, performing a breadth-first traversal by |
| 1407 | 1404 | simply traversing the array in order. |
| 1408 | −The <tt>rcu_for_each_nonleaf_node_breadth_first()</tt> macro operates | |
| 1409 | −similarly, but traverses only the first part of the array, thus excluding | |
| 1410 | −the leaf <tt>rcu_node</tt> structures. | |
| 1411 | −Finally, the <tt>rcu_for_each_leaf_node()</tt> macro traverses only | |
| 1405 | +Similarly, the <tt>rcu_for_each_leaf_node()</tt> macro traverses only | |
| 1412 | 1406 | the last part of the array, thus traversing only the leaf |
| 1413 | 1407 | <tt>rcu_node</tt> structures. |
| 1414 | 1408 | |
| @@ -1416,15 +1410,14 @@ the last part of the array, thus traversing only the leaf · 1 unmodified line | ||
| 1416 | 1410 | <tr><th> </th></tr> |
| 1417 | 1411 | <tr><th align="left">Quick Quiz:</th></tr> |
| 1418 | 1412 | <tr><td> |
| 1419 | − What do <tt>rcu_for_each_nonleaf_node_breadth_first()</tt> and | |
| 1413 | + What does | |
| 1420 | 1414 | <tt>rcu_for_each_leaf_node()</tt> do if the <tt>rcu_node</tt> tree |
| 1421 | 1415 | contains only a single node? |
| 1422 | 1416 | </td></tr> |
| 1423 | 1417 | <tr><th align="left">Answer:</th></tr> |
| 1424 | 1418 | <tr><td bgcolor="#ffffff"><font color="ffffff"> |
| 1425 | 1419 | In the single-node case, |
| 1426 | − <tt>rcu_for_each_nonleaf_node_breadth_first()</tt> is a no-op | |
| 1427 | − and <tt>rcu_for_each_leaf_node()</tt> traverses the single node. | |
| 1420 | + <tt>rcu_for_each_leaf_node()</tt> traverses the single node. | |
| 1428 | 1421 | </font></td></tr> |
| 1429 | 1422 | <tr><td> </td></tr> |
| 1430 | 1423 | </table> |
| @@ -12,10 +12,9 @@ high efficiency and minimal disturbance, expedited grace periods accept · 11 unmodified lines | ||
| 12 | 12 | lower efficiency and significant disturbance to attain shorter latencies. |
| 13 | 13 | |
| 14 | 14 | <p> |
| 15 | −There are three flavors of RCU (RCU-bh, RCU-preempt, and RCU-sched), | |
| 16 | −but only two flavors of expedited grace periods because the RCU-bh | |
| 17 | −expedited grace period maps onto the RCU-sched expedited grace period. | |
| 18 | −Each of the remaining two implementations is covered in its own section. | |
| 15 | +There are two flavors of RCU (RCU-preempt and RCU-sched), with an earlier | |
| 16 | +third RCU-bh flavor having been implemented in terms of the other two. | |
| 17 | +Each of the two implementations is covered in its own section. | |
| 19 | 18 | |
| 20 | 19 | <ol> |
| 21 | 20 | <li> <a href="#Expedited Grace Period Design"> |
| @@ -158,7 +157,7 @@ whether or not the current CPU is in an RCU read-side critical section. · 136 unmodified lines | ||
| 158 | 157 | The best that <tt>sync_sched_exp_handler()</tt> can do is to check |
| 159 | 158 | for idle, on the off-chance that the CPU went idle while the IPI |
| 160 | 159 | was in flight. |
| 161 | −If the CPU is idle, then tt>sync_sched_exp_handler()</tt> reports | |
| 160 | +If the CPU is idle, then <tt>sync_sched_exp_handler()</tt> reports | |
| 162 | 161 | the quiescent state. |
| 163 | 162 | |
| 164 | 163 | <p> |
| @@ -1306,8 +1306,6 @@ doing so would degrade real-time response. · 1305 unmodified lines | ||
| 1306 | 1306 | |
| 1307 | 1307 | <p> |
| 1308 | 1308 | This non-requirement appeared with preemptible RCU. |
| 1309 | −If you need a grace period that waits on non-preemptible code regions, use | |
| 1310 | −<a href="#Sched Flavor">RCU-sched</a>. | |
| 1311 | 1309 | |
| 1312 | 1310 | <h2><a name="Parallelism Facts of Life">Parallelism Facts of Life</a></h2> |
| 1313 | 1311 | |
| @@ -2165,14 +2163,9 @@ however, this is not a panacea because there would be severe restrictions · 851 unmodified lines | ||
| 2165 | 2163 | on what operations those callbacks could invoke. |
| 2166 | 2164 | |
| 2167 | 2165 | <p> |
| 2168 | −Perhaps surprisingly, <tt>synchronize_rcu()</tt>, | |
| 2169 | −<a href="#Bottom-Half Flavor"><tt>synchronize_rcu_bh()</tt></a> | |
| 2170 | −(<a href="#Bottom-Half Flavor">discussed below</a>), | |
| 2171 | −<a href="#Sched Flavor"><tt>synchronize_sched()</tt></a>, | |
| 2166 | +Perhaps surprisingly, <tt>synchronize_rcu()</tt> and | |
| 2172 | 2167 | <tt>synchronize_rcu_expedited()</tt>, |
| 2173 | −<tt>synchronize_rcu_bh_expedited()</tt>, and | |
| 2174 | −<tt>synchronize_sched_expedited()</tt> | |
| 2175 | −will all operate normally | |
| 2168 | +will operate normally | |
| 2176 | 2169 | during very early boot, the reason being that there is only one CPU |
| 2177 | 2170 | and preemption is disabled. |
| 2178 | 2171 | This means that the call <tt>synchronize_rcu()</tt> (or friends) |
| @@ -2269,12 +2262,23 @@ Thankfully, RCU update-side primitives, including · 90 unmodified lines | ||
| 2269 | 2262 | The name notwithstanding, some Linux-kernel architectures |
| 2270 | 2263 | can have nested NMIs, which RCU must handle correctly. |
| 2271 | 2264 | Andy Lutomirski |
| 2272 | −<a href="https://lkml.kernel.org/g/CALCETrXLq1y7e_dKFPgou-FKHB6Pu-r8+t-6Ds+8=va7anBWDA@mail.gmail.com">surprised me</a> | |
| 2265 | +<a href="https://lkml.kernel.org/r/CALCETrXLq1y7e_dKFPgou-FKHB6Pu-r8+t-6Ds+8=va7anBWDA@mail.gmail.com">surprised me</a> | |
| 2273 | 2266 | with this requirement; |
| 2274 | 2267 | he also kindly surprised me with |
| 2275 | −<a href="https://lkml.kernel.org/g/CALCETrXSY9JpW3uE6H8WYk81sg56qasA2aqmjMPsq5dOtzso=g@mail.gmail.com">an algorithm</a> | |
| 2268 | +<a href="https://lkml.kernel.org/r/CALCETrXSY9JpW3uE6H8WYk81sg56qasA2aqmjMPsq5dOtzso=g@mail.gmail.com">an algorithm</a> | |
| 2276 | 2269 | that meets this requirement. |
| 2277 | 2270 | |
| 2271 | +<p> | |
| 2272 | +Furthermore, NMI handlers can be interrupted by what appear to RCU | |
| 2273 | +to be normal interrupts. | |
| 2274 | +One way that this can happen is for code that directly invokes | |
| 2275 | +<tt>rcu_irq_enter()</tt> and </tt>rcu_irq_exit()</tt> to be called | |
| 2276 | +from an NMI handler. | |
| 2277 | +This astonishing fact of life prompted the current code structure, | |
| 2278 | +which has <tt>rcu_irq_enter()</tt> invoking <tt>rcu_nmi_enter()</tt> | |
| 2279 | +and <tt>rcu_irq_exit()</tt> invoking <tt>rcu_nmi_exit()</tt>. | |
| 2280 | +And yes, I also learned of this requirement the hard way. | |
| 2281 | + | |
| 2278 | 2282 | <h3><a name="Loadable Modules">Loadable Modules</a></h3> |
| 2279 | 2283 | |
| 2280 | 2284 | <p> |
| @@ -2394,30 +2398,9 @@ when invoked from a CPU-hotplug notifier. · 113 unmodified lines | ||
| 2394 | 2398 | <p> |
| 2395 | 2399 | RCU depends on the scheduler, and the scheduler uses RCU to |
| 2396 | 2400 | protect some of its data structures. |
| 2397 | −This means the scheduler is forbidden from acquiring | |
| 2398 | −the runqueue locks and the priority-inheritance locks | |
| 2399 | −in the middle of an outermost RCU read-side critical section unless either | |
| 2400 | −(1) it releases them before exiting that same | |
| 2401 | −RCU read-side critical section, or | |
| 2402 | −(2) interrupts are disabled across | |
| 2403 | −that entire RCU read-side critical section. | |
| 2404 | −This same prohibition also applies (recursively!) to any lock that is acquired | |
| 2405 | −while holding any lock to which this prohibition applies. | |
| 2406 | −Adhering to this rule prevents preemptible RCU from invoking | |
| 2407 | −<tt>rcu_read_unlock_special()</tt> while either runqueue or | |
| 2408 | −priority-inheritance locks are held, thus avoiding deadlock. | |
| 2409 | − | |
| 2410 | −<p> | |
| 2411 | −Prior to v4.4, it was only necessary to disable preemption across | |
| 2412 | −RCU read-side critical sections that acquired scheduler locks. | |
| 2413 | −In v4.4, expedited grace periods started using IPIs, and these | |
| 2414 | −IPIs could force a <tt>rcu_read_unlock()</tt> to take the slowpath. | |
| 2415 | −Therefore, this expedited-grace-period change required disabling of | |
| 2416 | −interrupts, not just preemption. | |
| 2417 | − | |
| 2418 | −<p> | |
| 2419 | −For RCU's part, the preemptible-RCU <tt>rcu_read_unlock()</tt> | |
| 2420 | −implementation must be written carefully to avoid similar deadlocks. | |
| 2401 | +The preemptible-RCU <tt>rcu_read_unlock()</tt> | |
| 2402 | +implementation must therefore be written carefully to avoid deadlocks | |
| 2403 | +involving the scheduler's runqueue and priority-inheritance locks. | |
| 2421 | 2404 | In particular, <tt>rcu_read_unlock()</tt> must tolerate an |
| 2422 | 2405 | interrupt where the interrupt handler invokes both |
| 2423 | 2406 | <tt>rcu_read_lock()</tt> and <tt>rcu_read_unlock()</tt>. |
| @@ -2426,7 +2409,7 @@ negative nesting levels to avoid destructive recursion via · 2 unmodified lines | ||
| 2426 | 2409 | interrupt handler's use of RCU. |
| 2427 | 2410 | |
| 2428 | 2411 | <p> |
| 2429 | −This pair of mutual scheduler-RCU requirements came as a | |
| 2412 | +This scheduler-RCU requirement came as a | |
| 2430 | 2413 | <a href="https://lwn.net/Articles/453002/">complete surprise</a>. |
| 2431 | 2414 | |
| 2432 | 2415 | <p> |
| @@ -2437,9 +2420,28 @@ when running context-switch-heavy workloads when built with · 4 unmodified lines | ||
| 2437 | 2420 | <tt>CONFIG_NO_HZ_FULL=y</tt> |
| 2438 | 2421 | <a href="http://www.rdrop.com/users/paulmck/scalability/paper/BareMetal.2015.01.15b.pdf">did come as a surprise [PDF]</a>. |
| 2439 | 2422 | RCU has made good progress towards meeting this requirement, even |
| 2440 | −for context-switch-have <tt>CONFIG_NO_HZ_FULL=y</tt> workloads, | |
| 2423 | +for context-switch-heavy <tt>CONFIG_NO_HZ_FULL=y</tt> workloads, | |
| 2441 | 2424 | but there is room for further improvement. |
| 2442 | 2425 | |
| 2426 | +<p> | |
| 2427 | +In the past, it was forbidden to disable interrupts across an | |
| 2428 | +<tt>rcu_read_unlock()</tt> unless that interrupt-disabled region | |
| 2429 | +of code also included the matching <tt>rcu_read_lock()</tt>. | |
| 2430 | +Violating this restriction could result in deadlocks involving the | |
| 2431 | +scheduler's runqueue and priority-inheritance spinlocks. | |
| 2432 | +This restriction was lifted when interrupt-disabled calls to | |
| 2433 | +<tt>rcu_read_unlock()</tt> started deferring the reporting of | |
| 2434 | +the resulting RCU-preempt quiescent state until the end of that | |
| 2435 | +interrupts-disabled region. | |
| 2436 | +This deferred reporting means that the scheduler's runqueue and | |
| 2437 | +priority-inheritance locks cannot be held while reporting an RCU-preempt | |
| 2438 | +quiescent state, which lifts the earlier restriction, at least from | |
| 2439 | +a deadlock perspective. | |
| 2440 | +Unfortunately, real-time systems using RCU priority boosting may | |
| 2441 | +need this restriction to remain in effect because deferred | |
| 2442 | +quiescent-state reporting also defers deboosting, which in turn | |
| 2443 | +degrades real-time latencies. | |
| 2444 | + | |
| 2443 | 2445 | <h3><a name="Tracing and RCU">Tracing and RCU</a></h3> |
| 2444 | 2446 | |
| 2445 | 2447 | <p> |
| @@ -2850,15 +2852,22 @@ The other four flavors are listed below, with requirements for each · 404 unmodified lines | ||
| 2850 | 2852 | described in a separate section. |
| 2851 | 2853 | |
| 2852 | 2854 | <ol> |
| 2853 | −<li> <a href="#Bottom-Half Flavor">Bottom-Half Flavor</a> | |
| 2854 | −<li> <a href="#Sched Flavor">Sched Flavor</a> | |
| 2855 | +<li> <a href="#Bottom-Half Flavor">Bottom-Half Flavor (Historical)</a> | |
| 2856 | +<li> <a href="#Sched Flavor">Sched Flavor (Historical)</a> | |
| 2855 | 2857 | <li> <a href="#Sleepable RCU">Sleepable RCU</a> |
| 2856 | 2858 | <li> <a href="#Tasks RCU">Tasks RCU</a> |
| 2857 | −<li> <a href="#Waiting for Multiple Grace Periods"> | |
| 2858 | − Waiting for Multiple Grace Periods</a> | |
| 2859 | 2859 | </ol> |
| 2860 | 2860 | |
| 2861 | −<h3><a name="Bottom-Half Flavor">Bottom-Half Flavor</a></h3> | |
| 2861 | +<h3><a name="Bottom-Half Flavor">Bottom-Half Flavor (Historical)</a></h3> | |
| 2862 | + | |
| 2863 | +<p> | |
| 2864 | +The RCU-bh flavor of RCU has since been expressed in terms of | |
| 2865 | +the other RCU flavors as part of a consolidation of the three | |
| 2866 | +flavors into a single flavor. | |
| 2867 | +The read-side API remains, and continues to disable softirq and to | |
| 2868 | +be accounted for by lockdep. | |
| 2869 | +Much of the material in this section is therefore strictly historical | |
| 2870 | +in nature. | |
| 2862 | 2871 | |
| 2863 | 2872 | <p> |
| 2864 | 2873 | The softirq-disable (AKA “bottom-half”, |
| @@ -2918,8 +2927,20 @@ includes · 53 unmodified lines | ||
| 2918 | 2927 | <tt>call_rcu_bh()</tt>, |
| 2919 | 2928 | <tt>rcu_barrier_bh()</tt>, and |
| 2920 | 2929 | <tt>rcu_read_lock_bh_held()</tt>. |
| 2930 | +However, the update-side APIs are now simple wrappers for other RCU | |
| 2931 | +flavors, namely RCU-sched in CONFIG_PREEMPT=n kernels and RCU-preempt | |
| 2932 | +otherwise. | |
| 2933 | + | |
| 2934 | +<h3><a name="Sched Flavor">Sched Flavor (Historical)</a></h3> | |
| 2921 | 2935 | |
| 2922 | −<h3><a name="Sched Flavor">Sched Flavor</a></h3> | |
| 2936 | +<p> | |
| 2937 | +The RCU-sched flavor of RCU has since been expressed in terms of | |
| 2938 | +the other RCU flavors as part of a consolidation of the three | |
| 2939 | +flavors into a single flavor. | |
| 2940 | +The read-side API remains, and continues to disable preemption and to | |
| 2941 | +be accounted for by lockdep. | |
| 2942 | +Much of the material in this section is therefore strictly historical | |
| 2943 | +in nature. | |
| 2923 | 2944 | |
| 2924 | 2945 | <p> |
| 2925 | 2946 | Before preemptible RCU, waiting for an RCU grace period had the |
| @@ -3139,94 +3160,14 @@ The tasks-RCU API is quite compact, consisting only of · 213 unmodified lines | ||
| 3139 | 3160 | <tt>call_rcu_tasks()</tt>, |
| 3140 | 3161 | <tt>synchronize_rcu_tasks()</tt>, and |
| 3141 | 3162 | <tt>rcu_barrier_tasks()</tt>. |
| 3142 | − | |
| 3143 | −<h3><a name="Waiting for Multiple Grace Periods"> | |
| 3144 | −Waiting for Multiple Grace Periods</a></h3> | |
| 3145 | − | |
| 3146 | −<p> | |
| 3147 | −Perhaps you have an RCU protected data structure that is accessed from | |
| 3148 | −RCU read-side critical sections, from softirq handlers, and from | |
| 3149 | −hardware interrupt handlers. | |
| 3150 | −That is three flavors of RCU, the normal flavor, the bottom-half flavor, | |
| 3151 | −and the sched flavor. | |
| 3152 | −How to wait for a compound grace period? | |
| 3153 | − | |
| 3154 | −<p> | |
| 3155 | −The best approach is usually to “just say no!” and | |
| 3156 | −insert <tt>rcu_read_lock()</tt> and <tt>rcu_read_unlock()</tt> | |
| 3157 | −around each RCU read-side critical section, regardless of what | |
| 3158 | −environment it happens to be in. | |
| 3159 | −But suppose that some of the RCU read-side critical sections are | |
| 3160 | −on extremely hot code paths, and that use of <tt>CONFIG_PREEMPT=n</tt> | |
| 3161 | −is not a viable option, so that <tt>rcu_read_lock()</tt> and | |
| 3162 | −<tt>rcu_read_unlock()</tt> are not free. | |
| 3163 | −What then? | |
| 3164 | − | |
| 3165 | −<p> | |
| 3166 | −You <i>could</i> wait on all three grace periods in succession, as follows: | |
| 3167 | − | |
| 3168 | −<blockquote> | |
| 3169 | −<pre> | |
| 3170 | − 1 synchronize_rcu(); | |
| 3171 | − 2 synchronize_rcu_bh(); | |
| 3172 | − 3 synchronize_sched(); | |
| 3173 | −</pre> | |
| 3174 | −</blockquote> | |
| 3175 | − | |
| 3176 | −<p> | |
| 3177 | −This works, but triples the update-side latency penalty. | |
| 3178 | −In cases where this is not acceptable, <tt>synchronize_rcu_mult()</tt> | |
| 3179 | −may be used to wait on all three flavors of grace period concurrently: | |
| 3180 | − | |
| 3181 | −<blockquote> | |
| 3182 | −<pre> | |
| 3183 | − 1 synchronize_rcu_mult(call_rcu, call_rcu_bh, call_rcu_sched); | |
| 3184 | −</pre> | |
| 3185 | −</blockquote> | |
| 3186 | − | |
| 3187 | −<p> | |
| 3188 | −But what if it is necessary to also wait on SRCU? | |
| 3189 | −This can be done as follows: | |
| 3190 | − | |
| 3191 | −<blockquote> | |
| 3192 | −<pre> | |
| 3193 | − 1 static void call_my_srcu(struct rcu_head *head, | |
| 3194 | − 2 void (*func)(struct rcu_head *head)) | |
| 3195 | − 3 { | |
| 3196 | − 4 call_srcu(&my_srcu, head, func); | |
| 3197 | − 5 } | |
| 3198 | − 6 | |
| 3199 | − 7 synchronize_rcu_mult(call_rcu, call_rcu_bh, call_rcu_sched, call_my_srcu); | |
| 3200 | −</pre> | |
| 3201 | −</blockquote> | |
| 3202 | − | |
| 3203 | −<p> | |
| 3204 | −If you needed to wait on multiple different flavors of SRCU | |
| 3205 | −(but why???), you would need to create a wrapper function resembling | |
| 3206 | −<tt>call_my_srcu()</tt> for each SRCU flavor. | |
| 3207 | − | |
| 3208 | −<table> | |
| 3209 | −<tr><th> </th></tr> | |
| 3210 | −<tr><th align="left">Quick Quiz:</th></tr> | |
| 3211 | −<tr><td> | |
| 3212 | − But what if I need to wait for multiple RCU flavors, but I also need | |
| 3213 | − the grace periods to be expedited? | |
| 3214 | −</td></tr> | |
| 3215 | −<tr><th align="left">Answer:</th></tr> | |
| 3216 | −<tr><td bgcolor="#ffffff"><font color="ffffff"> | |
| 3217 | − If you are using expedited grace periods, there should be less penalty | |
| 3218 | − for waiting on them in succession. | |
| 3219 | − But if that is nevertheless a problem, you can use workqueues | |
| 3220 | − or multiple kthreads to wait on the various expedited grace | |
| 3221 | − periods concurrently. | |
| 3222 | −</font></td></tr> | |
| 3223 | −<tr><td> </td></tr> | |
| 3224 | −</table> | |
| 3225 | − | |
| 3226 | −<p> | |
| 3227 | −Again, it is usually better to adjust the RCU read-side critical sections | |
| 3228 | −to use a single flavor of RCU, but when this is not feasible, you can use | |
| 3229 | −<tt>synchronize_rcu_mult()</tt>. | |
| 3163 | +In <tt>CONFIG_PREEMPT=n</tt> kernels, trampolines cannot be preempted, | |
| 3164 | +so these APIs map to | |
| 3165 | +<tt>call_rcu()</tt>, | |
| 3166 | +<tt>synchronize_rcu()</tt>, and | |
| 3167 | +<tt>rcu_barrier()</tt>, respectively. | |
| 3168 | +In <tt>CONFIG_PREEMPT=y</tt> kernels, trampolines can be preempted, | |
| 3169 | +and these three APIs are therefore implemented by separate functions | |
| 3170 | +that check for voluntary context switches. | |
| 3230 | 3171 | |
| 3231 | 3172 | <h2><a name="Possible Future Changes">Possible Future Changes</a></h2> |
| 3232 | 3173 | |
| @@ -3237,12 +3178,6 @@ If this becomes a serious problem, it will be necessary to rework the · 4 unmodified lines | ||
| 3237 | 3178 | grace-period state machine so as to avoid the need for the additional |
| 3238 | 3179 | latency. |
| 3239 | 3180 | |
| 3240 | −<p> | |
| 3241 | −Expedited grace periods scan the CPUs, so their latency and overhead | |
| 3242 | −increases with increasing numbers of CPUs. | |
| 3243 | −If this becomes a serious problem on large systems, it will be necessary | |
| 3244 | −to do some redesign to avoid this scalability problem. | |
| 3245 | − | |
| 3246 | 3181 | <p> |
| 3247 | 3182 | RCU disables CPU hotplug in a few places, perhaps most notably in the |
| 3248 | 3183 | <tt>rcu_barrier()</tt> operations. |
| @@ -3287,11 +3222,6 @@ Please note that arrangements that require RCU to remap CPU numbers will · 38 unmodified lines | ||
| 3287 | 3222 | require extremely good demonstration of need and full exploration of |
| 3288 | 3223 | alternatives. |
| 3289 | 3224 | |
| 3290 | −<p> | |
| 3291 | −There is an embarrassingly large number of flavors of RCU, and this | |
| 3292 | −number has been increasing over time. | |
| 3293 | −Perhaps it will be possible to combine some at some future date. | |
| 3294 | − | |
| 3295 | 3225 | <p> |
| 3296 | 3226 | RCU's various kthreads are reasonably recent additions. |
| 3297 | 3227 | It is quite likely that adjustments will be required to more gracefully |
| @@ -87,7 +87,3 @@ o Where can I find more information on RCU? · 86 unmodified lines | ||
| 87 | 87 | |
| 88 | 88 | See the RTFP.txt file in this directory. |
| 89 | 89 | Or point your browser at http://www.rdrop.com/users/paulmck/RCU/. |
| 90 | − | |
| 91 | −o What are all these files in this directory? | |
| 92 | − | |
| 93 | − See 00-INDEX for the list. | |
| @@ -16,12 +16,9 @@ o A CPU looping in an RCU read-side critical section. · 15 unmodified lines | ||
| 16 | 16 | |
| 17 | 17 | o A CPU looping with interrupts disabled. |
| 18 | 18 | |
| 19 | −o A CPU looping with preemption disabled. This condition can | |
| 20 | − result in RCU-sched stalls and, if ksoftirqd is in use, RCU-bh | |
| 21 | − stalls. | |
| 19 | +o A CPU looping with preemption disabled. | |
| 22 | 20 | |
| 23 | −o A CPU looping with bottom halves disabled. This condition can | |
| 24 | − result in RCU-sched and RCU-bh stalls. | |
| 21 | +o A CPU looping with bottom halves disabled. | |
| 25 | 22 | |
| 26 | 23 | o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the kernel |
| 27 | 24 | without invoking schedule(). If the looping in the kernel is |
| @@ -87,9 +84,9 @@ o A hardware failure. This is quite unlikely, but has occurred · 59 unmodified lines | ||
| 87 | 84 | This resulted in a series of RCU CPU stall warnings, eventually |
| 88 | 85 | leading the realization that the CPU had failed. |
| 89 | 86 | |
| 90 | −The RCU, RCU-sched, RCU-bh, and RCU-tasks implementations have CPU stall | |
| 91 | −warning. Note that SRCU does -not- have CPU stall warnings. Please note | |
| 92 | −that RCU only detects CPU stalls when there is a grace period in progress. | |
| 87 | +The RCU, RCU-sched, and RCU-tasks implementations have CPU stall warning. | |
| 88 | +Note that SRCU does -not- have CPU stall warnings. Please note that | |
| 89 | +RCU only detects CPU stalls when there is a grace period in progress. | |
| 93 | 90 | No grace period, no CPU stall warnings. |
| 94 | 91 | |
| 95 | 92 | To diagnose the cause of the stall, inspect the stack traces. |
| @@ -934,7 +934,8 @@ c. Do you need to treat NMI handlers, hardirq handlers, · 933 unmodified lines | ||
| 934 | 934 | d. Do you need RCU grace periods to complete even in the face |
| 935 | 935 | of softirq monopolization of one or more of the CPUs? For |
| 936 | 936 | example, is your code subject to network-based denial-of-service |
| 937 | − attacks? If so, you need RCU-bh. | |
| 937 | + attacks? If so, you should disable softirq across your readers, | |
| 938 | + for example, by using rcu_read_lock_bh(). | |
| 938 | 939 | |
| 939 | 940 | e. Is your workload too update-intensive for normal use of |
| 940 | 941 | RCU, but inappropriate for other synchronization mechanisms? |
| @@ -0,0 +1,73 @@ | ||
| 1 | +================================ | |
| 2 | +PSI - Pressure Stall Information | |
| 3 | +================================ | |
| 4 | + | |
| 5 | +:Date: April, 2018 | |
| 6 | +:Author: Johannes Weiner <hannes@cmpxchg.org> | |
| 7 | + | |
| 8 | +When CPU, memory or IO devices are contended, workloads experience | |
| 9 | +latency spikes, throughput losses, and run the risk of OOM kills. | |
| 10 | + | |
| 11 | +Without an accurate measure of such contention, users are forced to | |
| 12 | +either play it safe and under-utilize their hardware resources, or | |
| 13 | +roll the dice and frequently suffer the disruptions resulting from | |
| 14 | +excessive overcommit. | |
| 15 | + | |
| 16 | +The psi feature identifies and quantifies the disruptions caused by | |
| 17 | +such resource crunches and the time impact it has on complex workloads | |
| 18 | +or even entire systems. | |
| 19 | + | |
| 20 | +Having an accurate measure of productivity losses caused by resource | |
| 21 | +scarcity aids users in sizing workloads to hardware--or provisioning | |
| 22 | +hardware according to workload demand. | |
| 23 | + | |
| 24 | +As psi aggregates this information in realtime, systems can be managed | |
| 25 | +dynamically using techniques such as load shedding, migrating jobs to | |
| 26 | +other systems or data centers, or strategically pausing or killing low | |
| 27 | +priority or restartable batch jobs. | |
| 28 | + | |
| 29 | +This allows maximizing hardware utilization without sacrificing | |
| 30 | +workload health or risking major disruptions such as OOM kills. | |
| 31 | + | |
| 32 | +Pressure interface | |
| 33 | +================== | |
| 34 | + | |
| 35 | +Pressure information for each resource is exported through the | |
| 36 | +respective file in /proc/pressure/ -- cpu, memory, and io. | |
| 37 | + | |
| 38 | +The format for CPU is as such: | |
| 39 | + | |
| 40 | +some avg10=0.00 avg60=0.00 avg300=0.00 total=0 | |
| 41 | + | |
| 42 | +and for memory and IO: | |
| 43 | + | |
| 44 | +some avg10=0.00 avg60=0.00 avg300=0.00 total=0 | |
| 45 | +full avg10=0.00 avg60=0.00 avg300=0.00 total=0 | |
| 46 | + | |
| 47 | +The "some" line indicates the share of time in which at least some | |
| 48 | +tasks are stalled on a given resource. | |
| 49 | + | |
| 50 | +The "full" line indicates the share of time in which all non-idle | |
| 51 | +tasks are stalled on a given resource simultaneously. In this state | |
| 52 | +actual CPU cycles are going to waste, and a workload that spends | |
| 53 | +extended time in this state is considered to be thrashing. This has | |
| 54 | +severe impact on performance, and it's useful to distinguish this | |
| 55 | +situation from a state where some tasks are stalled but the CPU is | |
| 56 | +still doing productive work. As such, time spent in this subset of the | |
| 57 | +stall state is tracked separately and exported in the "full" averages. | |
| 58 | + | |
| 59 | +The ratios are tracked as recent trends over ten, sixty, and three | |
| 60 | +hundred second windows, which gives insight into short term events as | |
| 61 | +well as medium and long term trends. The total absolute stall time is | |
| 62 | +tracked and exported as well, to allow detection of latency spikes | |
| 63 | +which wouldn't necessarily make a dent in the time averages, or to | |
| 64 | +average trends over custom time frames. | |
| 65 | + | |
| 66 | +Cgroup2 interface | |
| 67 | +================= | |
| 68 | + | |
| 69 | +In a system with a CONFIG_CGROUP=y kernel and the cgroup2 filesystem | |
| 70 | +mounted, pressure stall information is also tracked for tasks grouped | |
| 71 | +into cgroups. Each subdirectory in the cgroupfs mountpoint contains | |
| 72 | +cpu.pressure, memory.pressure, and io.pressure files; the format is | |
| 73 | +the same as the /proc/pressure/ files. | |
| @@ -64,8 +64,8 @@ The sysctl settings (writable only with ``CAP_SYS_PTRACE``) are: · 63 unmodified lines | ||
| 64 | 64 | Using ``PTRACE_TRACEME`` is unchanged. |
| 65 | 65 | |
| 66 | 66 | 2 - admin-only attach: |
| 67 | − only processes with ``CAP_SYS_PTRACE`` may use ptrace | |
| 68 | − with ``PTRACE_ATTACH``, or through children calling ``PTRACE_TRACEME``. | |
| 67 | + only processes with ``CAP_SYS_PTRACE`` may use ptrace, either with | |
| 68 | + ``PTRACE_ATTACH`` or through children calling ``PTRACE_TRACEME``. | |
| 69 | 69 | |
| 70 | 70 | 3 - no attach: |
| 71 | 71 | no processes may use ptrace with ``PTRACE_ATTACH`` nor via |
| @@ -51,8 +51,7 @@ Documentation · 50 unmodified lines | ||
| 51 | 51 | |
| 52 | 52 | - There are various README files in the Documentation/ subdirectory: |
| 53 | 53 | these typically contain kernel-specific installation notes for some |
| 54 | − drivers for example. See Documentation/00-INDEX for a list of what | |
| 55 | − is contained in each file. Please read the | |
| 54 | + drivers for example. Please read the | |
| 56 | 55 | :ref:`Documentation/process/changes.rst <changes>` file, as it |
| 57 | 56 | contains information about the problems, which may result by upgrading |
| 58 | 57 | your kernel. |
| @@ -966,6 +966,12 @@ All time durations are in microseconds. · 965 unmodified lines | ||
| 966 | 966 | $PERIOD duration. "max" for $MAX indicates no limit. If only |
| 967 | 967 | one number is written, $MAX is updated. |
| 968 | 968 | |
| 969 | + cpu.pressure | |
| 970 | + A read-only nested-key file which exists on non-root cgroups. | |
| 971 | + | |
| 972 | + Shows pressure stall information for CPU. See | |
| 973 | + Documentation/accounting/psi.txt for details. | |
| 974 | + | |
| 969 | 975 | |
| 970 | 976 | Memory |
| 971 | 977 | ------ |
| @@ -1127,6 +1133,10 @@ PAGE_SIZE multiple when read back. · 155 unmodified lines | ||
| 1127 | 1133 | disk readahead. For now OOM in memory cgroup kills |
| 1128 | 1134 | tasks iff shortage has happened inside page fault. |
| 1129 | 1135 | |
| 1136 | + This event is not raised if the OOM killer is not | |
| 1137 | + considered as an option, e.g. for failed high-order | |
| 1138 | + allocations. | |
| 1139 | + | |
| 1130 | 1140 | oom_kill |
| 1131 | 1141 | The number of processes belonging to this cgroup |
| 1132 | 1142 | killed by any kind of OOM killer. |
| @@ -1271,6 +1281,12 @@ PAGE_SIZE multiple when read back. · 138 unmodified lines | ||
| 1271 | 1281 | higher than the limit for an extended period of time. This |
| 1272 | 1282 | reduces the impact on the workload and memory management. |
| 1273 | 1283 | |
| 1284 | + memory.pressure | |
| 1285 | + A read-only nested-key file which exists on non-root cgroups. | |
| 1286 | + | |
| 1287 | + Shows pressure stall information for memory. See | |
| 1288 | + Documentation/accounting/psi.txt for details. | |
| 1289 | + | |
| 1274 | 1290 | |
| 1275 | 1291 | Usage Guidelines |
| 1276 | 1292 | ~~~~~~~~~~~~~~~~ |
| @@ -1408,6 +1424,12 @@ IO Interface Files · 131 unmodified lines | ||
| 1408 | 1424 | |
| 1409 | 1425 | 8:16 rbps=2097152 wbps=max riops=max wiops=max |
| 1410 | 1426 | |
| 1427 | + io.pressure | |
| 1428 | + A read-only nested-key file which exists on non-root cgroups. | |
| 1429 | + | |
| 1430 | + Shows pressure stall information for IO. See | |
| 1431 | + Documentation/accounting/psi.txt for details. | |
| 1432 | + | |
| 1411 | 1433 | |
| 1412 | 1434 | Writeback |
| 1413 | 1435 | ~~~~~~~~~ |
| @@ -0,0 +1,574 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +======================== | |
| 4 | +ext4 General Information | |
| 5 | +======================== | |
| 6 | + | |
| 7 | +Ext4 is an advanced level of the ext3 filesystem which incorporates | |
| 8 | +scalability and reliability enhancements for supporting large filesystems | |
| 9 | +(64 bit) in keeping with increasing disk capacities and state-of-the-art | |
| 10 | +feature requirements. | |
| 11 | + | |
| 12 | +Mailing list: linux-ext4@vger.kernel.org | |
| 13 | +Web site: http://ext4.wiki.kernel.org | |
| 14 | + | |
| 15 | + | |
| 16 | +Quick usage instructions | |
| 17 | +======================== | |
| 18 | + | |
| 19 | +Note: More extensive information for getting started with ext4 can be | |
| 20 | +found at the ext4 wiki site at the URL: | |
| 21 | +http://ext4.wiki.kernel.org/index.php/Ext4_Howto | |
| 22 | + | |
| 23 | + - The latest version of e2fsprogs can be found at: | |
| 24 | + | |
| 25 | + https://www.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/ | |
| 26 | + | |
| 27 | + or | |
| 28 | + | |
| 29 | + http://sourceforge.net/project/showfiles.php?group_id=2406 | |
| 30 | + | |
| 31 | + or grab the latest git repository from: | |
| 32 | + | |
| 33 | + https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git | |
| 34 | + | |
| 35 | + - Create a new filesystem using the ext4 filesystem type: | |
| 36 | + | |
| 37 | + # mke2fs -t ext4 /dev/hda1 | |
| 38 | + | |
| 39 | + Or to configure an existing ext3 filesystem to support extents: | |
| 40 | + | |
| 41 | + # tune2fs -O extents /dev/hda1 | |
| 42 | + | |
| 43 | + If the filesystem was created with 128 byte inodes, it can be | |
| 44 | + converted to use 256 byte for greater efficiency via: | |
| 45 | + | |
| 46 | + # tune2fs -I 256 /dev/hda1 | |
| 47 | + | |
| 48 | + - Mounting: | |
| 49 | + | |
| 50 | + # mount -t ext4 /dev/hda1 /wherever | |
| 51 | + | |
| 52 | + - When comparing performance with other filesystems, it's always | |
| 53 | + important to try multiple workloads; very often a subtle change in a | |
| 54 | + workload parameter can completely change the ranking of which | |
| 55 | + filesystems do well compared to others. When comparing versus ext3, | |
| 56 | + note that ext4 enables write barriers by default, while ext3 does | |
| 57 | + not enable write barriers by default. So it is useful to use | |
| 58 | + explicitly specify whether barriers are enabled or not when via the | |
| 59 | + '-o barriers=[0|1]' mount option for both ext3 and ext4 filesystems | |
| 60 | + for a fair comparison. When tuning ext3 for best benchmark numbers, | |
| 61 | + it is often worthwhile to try changing the data journaling mode; '-o | |
| 62 | + data=writeback' can be faster for some workloads. (Note however that | |
| 63 | + running mounted with data=writeback can potentially leave stale data | |
| 64 | + exposed in recently written files in case of an unclean shutdown, | |
| 65 | + which could be a security exposure in some situations.) Configuring | |
| 66 | + the filesystem with a large journal can also be helpful for | |
| 67 | + metadata-intensive workloads. | |
| 68 | + | |
| 69 | +Features | |
| 70 | +======== | |
| 71 | + | |
| 72 | +Currently Available | |
| 73 | +------------------- | |
| 74 | + | |
| 75 | +* ability to use filesystems > 16TB (e2fsprogs support not available yet) | |
| 76 | +* extent format reduces metadata overhead (RAM, IO for access, transactions) | |
| 77 | +* extent format more robust in face of on-disk corruption due to magics, | |
| 78 | +* internal redundancy in tree | |
| 79 | +* improved file allocation (multi-block alloc) | |
| 80 | +* lift 32000 subdirectory limit imposed by i_links_count[1] | |
| 81 | +* nsec timestamps for mtime, atime, ctime, create time | |
| 82 | +* inode version field on disk (NFSv4, Lustre) | |
| 83 | +* reduced e2fsck time via uninit_bg feature | |
| 84 | +* journal checksumming for robustness, performance | |
| 85 | +* persistent file preallocation (e.g for streaming media, databases) | |
| 86 | +* ability to pack bitmaps and inode tables into larger virtual groups via the | |
| 87 | + flex_bg feature | |
| 88 | +* large file support | |
| 89 | +* inode allocation using large virtual block groups via flex_bg | |
| 90 | +* delayed allocation | |
| 91 | +* large block (up to pagesize) support | |
| 92 | +* efficient new ordered mode in JBD2 and ext4 (avoid using buffer head to force | |
| 93 | + the ordering) | |
| 94 | + | |
| 95 | +[1] Filesystems with a block size of 1k may see a limit imposed by the | |
| 96 | +directory hash tree having a maximum depth of two. | |
| 97 | + | |
| 98 | +Options | |
| 99 | +======= | |
| 100 | + | |
| 101 | +When mounting an ext4 filesystem, the following option are accepted: | |
| 102 | +(*) == default | |
| 103 | + | |
| 104 | + ro | |
| 105 | + Mount filesystem read only. Note that ext4 will replay the journal (and | |
| 106 | + thus write to the partition) even when mounted "read only". The mount | |
| 107 | + options "ro,noload" can be used to prevent writes to the filesystem. | |
| 108 | + | |
| 109 | + journal_checksum | |
| 110 | + Enable checksumming of the journal transactions. This will allow the | |
| 111 | + recovery code in e2fsck and the kernel to detect corruption in the | |
| 112 | + kernel. It is a compatible change and will be ignored by older | |
| 113 | + kernels. | |
| 114 | + | |
| 115 | + journal_async_commit | |
| 116 | + Commit block can be written to disk without waiting for descriptor | |
| 117 | + blocks. If enabled older kernels cannot mount the device. This will | |
| 118 | + enable 'journal_checksum' internally. | |
| 119 | + | |
| 120 | + journal_path=path, journal_dev=devnum | |
| 121 | + When the external journal device's major/minor numbers have changed, | |
| 122 | + these options allow the user to specify the new journal location. The | |
| 123 | + journal device is identified through either its new major/minor numbers | |
| 124 | + encoded in devnum, or via a path to the device. | |
| 125 | + | |
| 126 | + norecovery, noload | |
| 127 | + Don't load the journal on mounting. Note that if the filesystem was | |
| 128 | + not unmounted cleanly, skipping the journal replay will lead to the | |
| 129 | + filesystem containing inconsistencies that can lead to any number of | |
| 130 | + problems. | |
| 131 | + | |
| 132 | + data=journal | |
| 133 | + All data are committed into the journal prior to being written into the | |
| 134 | + main file system. Enabling this mode will disable delayed allocation | |
| 135 | + and O_DIRECT support. | |
| 136 | + | |
| 137 | + data=ordered (*) | |
| 138 | + All data are forced directly out to the main file system prior to its | |
| 139 | + metadata being committed to the journal. | |
| 140 | + | |
| 141 | + data=writeback | |
| 142 | + Data ordering is not preserved, data may be written into the main file | |
| 143 | + system after its metadata has been committed to the journal. | |
| 144 | + | |
| 145 | + commit=nrsec (*) | |
| 146 | + Ext4 can be told to sync all its data and metadata every 'nrsec' | |
| 147 | + seconds. The default value is 5 seconds. This means that if you lose | |
| 148 | + your power, you will lose as much as the latest 5 seconds of work (your | |
| 149 | + filesystem will not be damaged though, thanks to the journaling). This | |
| 150 | + default value (or any low value) will hurt performance, but it's good | |
| 151 | + for data-safety. Setting it to 0 will have the same effect as leaving | |
| 152 | + it at the default (5 seconds). Setting it to very large values will | |
| 153 | + improve performance. | |
| 154 | + | |
| 155 | + barrier=<0|1(*)>, barrier(*), nobarrier | |
| 156 | + This enables/disables the use of write barriers in the jbd code. | |
| 157 | + barrier=0 disables, barrier=1 enables. This also requires an IO stack | |
| 158 | + which can support barriers, and if jbd gets an error on a barrier | |
| 159 | + write, it will disable again with a warning. Write barriers enforce | |
| 160 | + proper on-disk ordering of journal commits, making volatile disk write | |
| 161 | + caches safe to use, at some performance penalty. If your disks are | |
| 162 | + battery-backed in one way or another, disabling barriers may safely | |
| 163 | + improve performance. The mount options "barrier" and "nobarrier" can | |
| 164 | + also be used to enable or disable barriers, for consistency with other | |
| 165 | + ext4 mount options. | |
| 166 | + | |
| 167 | + inode_readahead_blks=n | |
| 168 | + This tuning parameter controls the maximum number of inode table blocks | |
| 169 | + that ext4's inode table readahead algorithm will pre-read into the | |
| 170 | + buffer cache. The default value is 32 blocks. | |
| 171 | + | |
| 172 | + nouser_xattr | |
| 173 | + Disables Extended User Attributes. See the attr(5) manual page for | |
| 174 | + more information about extended attributes. | |
| 175 | + | |
| 176 | + noacl | |
| 177 | + This option disables POSIX Access Control List support. If ACL support | |
| 178 | + is enabled in the kernel configuration (CONFIG_EXT4_FS_POSIX_ACL), ACL | |
| 179 | + is enabled by default on mount. See the acl(5) manual page for more | |
| 180 | + information about acl. | |
| 181 | + | |
| 182 | + bsddf (*) | |
| 183 | + Make 'df' act like BSD. | |
| 184 | + | |
| 185 | + minixdf | |
| 186 | + Make 'df' act like Minix. | |
| 187 | + | |
| 188 | + debug | |
| 189 | + Extra debugging information is sent to syslog. | |
| 190 | + | |
| 191 | + abort | |
| 192 | + Simulate the effects of calling ext4_abort() for debugging purposes. | |
| 193 | + This is normally used while remounting a filesystem which is already | |
| 194 | + mounted. | |
| 195 | + | |
| 196 | + errors=remount-ro | |
| 197 | + Remount the filesystem read-only on an error. | |
| 198 | + | |
| 199 | + errors=continue | |
| 200 | + Keep going on a filesystem error. | |
| 201 | + | |
| 202 | + errors=panic | |
| 203 | + Panic and halt the machine if an error occurs. (These mount options | |
| 204 | + override the errors behavior specified in the superblock, which can be | |
| 205 | + configured using tune2fs) | |
| 206 | + | |
| 207 | + data_err=ignore(*) | |
| 208 | + Just print an error message if an error occurs in a file data buffer in | |
| 209 | + ordered mode. | |
| 210 | + data_err=abort | |
| 211 | + Abort the journal if an error occurs in a file data buffer in ordered | |
| 212 | + mode. | |
| 213 | + | |
| 214 | + grpid | bsdgroups | |
| 215 | + New objects have the group ID of their parent. | |
| 216 | + | |
| 217 | + nogrpid (*) | sysvgroups | |
| 218 | + New objects have the group ID of their creator. | |
| 219 | + | |
| 220 | + resgid=n | |
| 221 | + The group ID which may use the reserved blocks. | |
| 222 | + | |
| 223 | + resuid=n | |
| 224 | + The user ID which may use the reserved blocks. | |
| 225 | + | |
| 226 | + sb= | |
| 227 | + Use alternate superblock at this location. | |
| 228 | + | |
| 229 | + quota, noquota, grpquota, usrquota | |
| 230 | + These options are ignored by the filesystem. They are used only by | |
| 231 | + quota tools to recognize volumes where quota should be turned on. See | |
| 232 | + documentation in the quota-tools package for more details | |
| 233 | + (http://sourceforge.net/projects/linuxquota). | |
| 234 | + | |
| 235 | + jqfmt=<quota type>, usrjquota=<file>, grpjquota=<file> | |
| 236 | + These options tell filesystem details about quota so that quota | |
| 237 | + information can be properly updated during journal replay. They replace | |
| 238 | + the above quota options. See documentation in the quota-tools package | |
| 239 | + for more details (http://sourceforge.net/projects/linuxquota). | |
| 240 | + | |
| 241 | + stripe=n | |
| 242 | + Number of filesystem blocks that mballoc will try to use for allocation | |
| 243 | + size and alignment. For RAID5/6 systems this should be the number of | |
| 244 | + data disks * RAID chunk size in file system blocks. | |
| 245 | + | |
| 246 | + delalloc (*) | |
| 247 | + Defer block allocation until just before ext4 writes out the block(s) | |
| 248 | + in question. This allows ext4 to better allocation decisions more | |
| 249 | + efficiently. | |
| 250 | + | |
| 251 | + nodelalloc | |
| 252 | + Disable delayed allocation. Blocks are allocated when the data is | |
| 253 | + copied from userspace to the page cache, either via the write(2) system | |
| 254 | + call or when an mmap'ed page which was previously unallocated is | |
| 255 | + written for the first time. | |
| 256 | + | |
| 257 | + max_batch_time=usec | |
| 258 | + Maximum amount of time ext4 should wait for additional filesystem | |
| 259 | + operations to be batch together with a synchronous write operation. | |
| 260 | + Since a synchronous write operation is going to force a commit and then | |
| 261 | + a wait for the I/O complete, it doesn't cost much, and can be a huge | |
| 262 | + throughput win, we wait for a small amount of time to see if any other | |
| 263 | + transactions can piggyback on the synchronous write. The algorithm | |
| 264 | + used is designed to automatically tune for the speed of the disk, by | |
| 265 | + measuring the amount of time (on average) that it takes to finish | |
| 266 | + committing a transaction. Call this time the "commit time". If the | |
| 267 | + time that the transaction has been running is less than the commit | |
| 268 | + time, ext4 will try sleeping for the commit time to see if other | |
| 269 | + operations will join the transaction. The commit time is capped by | |
| 270 | + the max_batch_time, which defaults to 15000us (15ms). This | |
| 271 | + optimization can be turned off entirely by setting max_batch_time to 0. | |
| 272 | + | |
| 273 | + min_batch_time=usec | |
| 274 | + This parameter sets the commit time (as described above) to be at least | |
| 275 | + min_batch_time. It defaults to zero microseconds. Increasing this | |
| 276 | + parameter may improve the throughput of multi-threaded, synchronous | |
| 277 | + workloads on very fast disks, at the cost of increasing latency. | |
| 278 | + | |
| 279 | + journal_ioprio=prio | |
| 280 | + The I/O priority (from 0 to 7, where 0 is the highest priority) which | |
| 281 | + should be used for I/O operations submitted by kjournald2 during a | |
| 282 | + commit operation. This defaults to 3, which is a slightly higher | |
| 283 | + priority than the default I/O priority. | |
| 284 | + | |
| 285 | + auto_da_alloc(*), noauto_da_alloc | |
| 286 | + Many broken applications don't use fsync() when replacing existing | |
| 287 | + files via patterns such as fd = open("foo.new")/write(fd,..)/close(fd)/ | |
| 288 | + rename("foo.new", "foo"), or worse yet, fd = open("foo", | |
| 289 | + O_TRUNC)/write(fd,..)/close(fd). If auto_da_alloc is enabled, ext4 | |
| 290 | + will detect the replace-via-rename and replace-via-truncate patterns | |
| 291 | + and force that any delayed allocation blocks are allocated such that at | |
| 292 | + the next journal commit, in the default data=ordered mode, the data | |
| 293 | + blocks of the new file are forced to disk before the rename() operation | |
| 294 | + is committed. This provides roughly the same level of guarantees as | |
| 295 | + ext3, and avoids the "zero-length" problem that can happen when a | |
| 296 | + system crashes before the delayed allocation blocks are forced to disk. | |
| 297 | + | |
| 298 | + noinit_itable | |
| 299 | + Do not initialize any uninitialized inode table blocks in the | |
| 300 | + background. This feature may be used by installation CD's so that the | |
| 301 | + install process can complete as quickly as possible; the inode table | |
| 302 | + initialization process would then be deferred until the next time the | |
| 303 | + file system is unmounted. | |
| 304 | + | |
| 305 | + init_itable=n | |
| 306 | + The lazy itable init code will wait n times the number of milliseconds | |
| 307 | + it took to zero out the previous block group's inode table. This | |
| 308 | + minimizes the impact on the system performance while file system's | |
| 309 | + inode table is being initialized. | |
| 310 | + | |
| 311 | + discard, nodiscard(*) | |
| 312 | + Controls whether ext4 should issue discard/TRIM commands to the | |
| 313 | + underlying block device when blocks are freed. This is useful for SSD | |
| 314 | + devices and sparse/thinly-provisioned LUNs, but it is off by default | |
| 315 | + until sufficient testing has been done. | |
| 316 | + | |
| 317 | + nouid32 | |
| 318 | + Disables 32-bit UIDs and GIDs. This is for interoperability with | |
| 319 | + older kernels which only store and expect 16-bit values. | |
| 320 | + | |
| 321 | + block_validity(*), noblock_validity | |
| 322 | + These options enable or disable the in-kernel facility for tracking | |
| 323 | + filesystem metadata blocks within internal data structures. This | |
| 324 | + allows multi- block allocator and other routines to notice bugs or | |
| 325 | + corrupted allocation bitmaps which cause blocks to be allocated which | |
| 326 | + overlap with filesystem metadata blocks. | |
| 327 | + | |
| 328 | + dioread_lock, dioread_nolock | |
| 329 | + Controls whether or not ext4 should use the DIO read locking. If the | |
| 330 | + dioread_nolock option is specified ext4 will allocate uninitialized | |
| 331 | + extent before buffer write and convert the extent to initialized after | |
| 332 | + IO completes. This approach allows ext4 code to avoid using inode | |
| 333 | + mutex, which improves scalability on high speed storages. However this | |
| 334 | + does not work with data journaling and dioread_nolock option will be | |
| 335 | + ignored with kernel warning. Note that dioread_nolock code path is only | |
| 336 | + used for extent-based files. Because of the restrictions this options | |
| 337 | + comprises it is off by default (e.g. dioread_lock). | |
| 338 | + | |
| 339 | + max_dir_size_kb=n | |
| 340 | + This limits the size of directories so that any attempt to expand them | |
| 341 | + beyond the specified limit in kilobytes will cause an ENOSPC error. | |
| 342 | + This is useful in memory constrained environments, where a very large | |
| 343 | + directory can cause severe performance problems or even provoke the Out | |
| 344 | + Of Memory killer. (For example, if there is only 512mb memory | |
| 345 | + available, a 176mb directory may seriously cramp the system's style.) | |
| 346 | + | |
| 347 | + i_version | |
| 348 | + Enable 64-bit inode version support. This option is off by default. | |
| 349 | + | |
| 350 | + dax | |
| 351 | + Use direct access (no page cache). See | |
| 352 | + Documentation/filesystems/dax.txt. Note that this option is | |
| 353 | + incompatible with data=journal. | |
| 354 | + | |
| 355 | +Data Mode | |
| 356 | +========= | |
| 357 | +There are 3 different data modes: | |
| 358 | + | |
| 359 | +* writeback mode | |
| 360 | + | |
| 361 | + In data=writeback mode, ext4 does not journal data at all. This mode provides | |
| 362 | + a similar level of journaling as that of XFS, JFS, and ReiserFS in its default | |
| 363 | + mode - metadata journaling. A crash+recovery can cause incorrect data to | |
| 364 | + appear in files which were written shortly before the crash. This mode will | |
| 365 | + typically provide the best ext4 performance. | |
| 366 | + | |
| 367 | +* ordered mode | |
| 368 | + | |
| 369 | + In data=ordered mode, ext4 only officially journals metadata, but it logically | |
| 370 | + groups metadata information related to data changes with the data blocks into | |
| 371 | + a single unit called a transaction. When it's time to write the new metadata | |
| 372 | + out to disk, the associated data blocks are written first. In general, this | |
| 373 | + mode performs slightly slower than writeback but significantly faster than | |
| 374 | + journal mode. | |
| 375 | + | |
| 376 | +* journal mode | |
| 377 | + | |
| 378 | + data=journal mode provides full data and metadata journaling. All new data is | |
| 379 | + written to the journal first, and then to its final location. In the event of | |
| 380 | + a crash, the journal can be replayed, bringing both data and metadata into a | |
| 381 | + consistent state. This mode is the slowest except when data needs to be read | |
| 382 | + from and written to disk at the same time where it outperforms all others | |
| 383 | + modes. Enabling this mode will disable delayed allocation and O_DIRECT | |
| 384 | + support. | |
| 385 | + | |
| 386 | +/proc entries | |
| 387 | +============= | |
| 388 | + | |
| 389 | +Information about mounted ext4 file systems can be found in | |
| 390 | +/proc/fs/ext4. Each mounted filesystem will have a directory in | |
| 391 | +/proc/fs/ext4 based on its device name (i.e., /proc/fs/ext4/hdc or | |
| 392 | +/proc/fs/ext4/dm-0). The files in each per-device directory are shown | |
| 393 | +in table below. | |
| 394 | + | |
| 395 | +Files in /proc/fs/ext4/<devname> | |
| 396 | + | |
| 397 | + mb_groups | |
| 398 | + details of multiblock allocator buddy cache of free blocks | |
| 399 | + | |
| 400 | +/sys entries | |
| 401 | +============ | |
| 402 | + | |
| 403 | +Information about mounted ext4 file systems can be found in | |
| 404 | +/sys/fs/ext4. Each mounted filesystem will have a directory in | |
| 405 | +/sys/fs/ext4 based on its device name (i.e., /sys/fs/ext4/hdc or | |
| 406 | +/sys/fs/ext4/dm-0). The files in each per-device directory are shown | |
| 407 | +in table below. | |
| 408 | + | |
| 409 | +Files in /sys/fs/ext4/<devname>: | |
| 410 | + | |
| 411 | +(see also Documentation/ABI/testing/sysfs-fs-ext4) | |
| 412 | + | |
| 413 | + delayed_allocation_blocks | |
| 414 | + This file is read-only and shows the number of blocks that are dirty in | |
| 415 | + the page cache, but which do not have their location in the filesystem | |
| 416 | + allocated yet. | |
| 417 | + | |
| 418 | + inode_goal | |
| 419 | + Tuning parameter which (if non-zero) controls the goal inode used by | |
| 420 | + the inode allocator in preference to all other allocation heuristics. | |
| 421 | + This is intended for debugging use only, and should be 0 on production | |
| 422 | + systems. | |
| 423 | + | |
| 424 | + inode_readahead_blks | |
| 425 | + Tuning parameter which controls the maximum number of inode table | |
| 426 | + blocks that ext4's inode table readahead algorithm will pre-read into | |
| 427 | + the buffer cache. | |
| 428 | + | |
| 429 | + lifetime_write_kbytes | |
| 430 | + This file is read-only and shows the number of kilobytes of data that | |
| 431 | + have been written to this filesystem since it was created. | |
| 432 | + | |
| 433 | + max_writeback_mb_bump | |
| 434 | + The maximum number of megabytes the writeback code will try to write | |
| 435 | + out before move on to another inode. | |
| 436 | + | |
| 437 | + mb_group_prealloc | |
| 438 | + The multiblock allocator will round up allocation requests to a | |
| 439 | + multiple of this tuning parameter if the stripe size is not set in the | |
| 440 | + ext4 superblock | |
| 441 | + | |
| 442 | + mb_max_to_scan | |
| 443 | + The maximum number of extents the multiblock allocator will search to | |
| 444 | + find the best extent. | |
| 445 | + | |
| 446 | + mb_min_to_scan | |
| 447 | + The minimum number of extents the multiblock allocator will search to | |
| 448 | + find the best extent. | |
| 449 | + | |
| 450 | + mb_order2_req | |
| 451 | + Tuning parameter which controls the minimum size for requests (as a | |
| 452 | + power of 2) where the buddy cache is used. | |
| 453 | + | |
| 454 | + mb_stats | |
| 455 | + Controls whether the multiblock allocator should collect statistics, | |
| 456 | + which are shown during the unmount. 1 means to collect statistics, 0 | |
| 457 | + means not to collect statistics. | |
| 458 | + | |
| 459 | + mb_stream_req | |
| 460 | + Files which have fewer blocks than this tunable parameter will have | |
| 461 | + their blocks allocated out of a block group specific preallocation | |
| 462 | + pool, so that small files are packed closely together. Each large file | |
| 463 | + will have its blocks allocated out of its own unique preallocation | |
| 464 | + pool. | |
| 465 | + | |
| 466 | + session_write_kbytes | |
| 467 | + This file is read-only and shows the number of kilobytes of data that | |
| 468 | + have been written to this filesystem since it was mounted. | |
| 469 | + | |
| 470 | + reserved_clusters | |
| 471 | + This is RW file and contains number of reserved clusters in the file | |
| 472 | + system which will be used in the specific situations to avoid costly | |
| 473 | + zeroout, unexpected ENOSPC, or possible data loss. The default is 2% or | |
| 474 | + 4096 clusters, whichever is smaller and this can be changed however it | |
| 475 | + can never exceed number of clusters in the file system. If there is not | |
| 476 | + enough space for the reserved space when mounting the file mount will | |
| 477 | + _not_ fail. | |
| 478 | + | |
| 479 | +Ioctls | |
| 480 | +====== | |
| 481 | + | |
| 482 | +There is some Ext4 specific functionality which can be accessed by applications | |
| 483 | +through the system call interfaces. The list of all Ext4 specific ioctls are | |
| 484 | +shown in the table below. | |
| 485 | + | |
| 486 | +Table of Ext4 specific ioctls | |
| 487 | + | |
| 488 | + EXT4_IOC_GETFLAGS | |
| 489 | + Get additional attributes associated with inode. The ioctl argument is | |
| 490 | + an integer bitfield, with bit values described in ext4.h. This ioctl is | |
| 491 | + an alias for FS_IOC_GETFLAGS. | |
| 492 | + | |
| 493 | + EXT4_IOC_SETFLAGS | |
| 494 | + Set additional attributes associated with inode. The ioctl argument is | |
| 495 | + an integer bitfield, with bit values described in ext4.h. This ioctl is | |
| 496 | + an alias for FS_IOC_SETFLAGS. | |
| 497 | + | |
| 498 | + EXT4_IOC_GETVERSION, EXT4_IOC_GETVERSION_OLD | |
| 499 | + Get the inode i_generation number stored for each inode. The | |
| 500 | + i_generation number is normally changed only when new inode is created | |
| 501 | + and it is particularly useful for network filesystems. The '_OLD' | |
| 502 | + version of this ioctl is an alias for FS_IOC_GETVERSION. | |
| 503 | + | |
| 504 | + EXT4_IOC_SETVERSION, EXT4_IOC_SETVERSION_OLD | |
| 505 | + Set the inode i_generation number stored for each inode. The '_OLD' | |
| 506 | + version of this ioctl is an alias for FS_IOC_SETVERSION. | |
| 507 | + | |
| 508 | + EXT4_IOC_GROUP_EXTEND | |
| 509 | + This ioctl has the same purpose as the resize mount option. It allows | |
| 510 | + to resize filesystem to the end of the last existing block group, | |
| 511 | + further resize has to be done with resize2fs, either online, or | |
| 512 | + offline. The argument points to the unsigned logn number representing | |
| 513 | + the filesystem new block count. | |
| 514 | + | |
| 515 | + EXT4_IOC_MOVE_EXT | |
| 516 | + Move the block extents from orig_fd (the one this ioctl is pointing to) | |
| 517 | + to the donor_fd (the one specified in move_extent structure passed as | |
| 518 | + an argument to this ioctl). Then, exchange inode metadata between | |
| 519 | + orig_fd and donor_fd. This is especially useful for online | |
| 520 | + defragmentation, because the allocator has the opportunity to allocate | |
| 521 | + moved blocks better, ideally into one contiguous extent. | |
| 522 | + | |
| 523 | + EXT4_IOC_GROUP_ADD | |
| 524 | + Add a new group descriptor to an existing or new group descriptor | |
| 525 | + block. The new group descriptor is described by ext4_new_group_input | |
| 526 | + structure, which is passed as an argument to this ioctl. This is | |
| 527 | + especially useful in conjunction with EXT4_IOC_GROUP_EXTEND, which | |
| 528 | + allows online resize of the filesystem to the end of the last existing | |
| 529 | + block group. Those two ioctls combined is used in userspace online | |
| 530 | + resize tool (e.g. resize2fs). | |
| 531 | + | |
| 532 | + EXT4_IOC_MIGRATE | |
| 533 | + This ioctl operates on the filesystem itself. It converts (migrates) | |
| 534 | + ext3 indirect block mapped inode to ext4 extent mapped inode by walking | |
| 535 | + through indirect block mapping of the original inode and converting | |
| 536 | + contiguous block ranges into ext4 extents of the temporary inode. Then, | |
| 537 | + inodes are swapped. This ioctl might help, when migrating from ext3 to | |
| 538 | + ext4 filesystem, however suggestion is to create fresh ext4 filesystem | |
| 539 | + and copy data from the backup. Note, that filesystem has to support | |
| 540 | + extents for this ioctl to work. | |
| 541 | + | |
| 542 | + EXT4_IOC_ALLOC_DA_BLKS | |
| 543 | + Force all of the delay allocated blocks to be allocated to preserve | |
| 544 | + application-expected ext3 behaviour. Note that this will also start | |
| 545 | + triggering a write of the data blocks, but this behaviour may change in | |
| 546 | + the future as it is not necessary and has been done this way only for | |
| 547 | + sake of simplicity. | |
| 548 | + | |
| 549 | + EXT4_IOC_RESIZE_FS | |
| 550 | + Resize the filesystem to a new size. The number of blocks of resized | |
| 551 | + filesystem is passed in via 64 bit integer argument. The kernel | |
| 552 | + allocates bitmaps and inode table, the userspace tool thus just passes | |
| 553 | + the new number of blocks. | |
| 554 | + | |
| 555 | + EXT4_IOC_SWAP_BOOT | |
| 556 | + Swap i_blocks and associated attributes (like i_blocks, i_size, | |
| 557 | + i_flags, ...) from the specified inode with inode EXT4_BOOT_LOADER_INO | |
| 558 | + (#5). This is typically used to store a boot loader in a secure part of | |
| 559 | + the filesystem, where it can't be changed by a normal user by accident. | |
| 560 | + The data blocks of the previous boot loader will be associated with the | |
| 561 | + given inode. | |
| 562 | + | |
| 563 | +References | |
| 564 | +========== | |
| 565 | + | |
| 566 | +kernel source: <file:fs/ext4/> | |
| 567 | + <file:fs/jbd2/> | |
| 568 | + | |
| 569 | +programs: http://e2fsprogs.sourceforge.net/ | |
| 570 | + | |
| 571 | +useful links: http://fedoraproject.org/wiki/ext3-devel | |
| 572 | + http://www.bullopensource.org/ext4/ | |
| 573 | + http://ext4.wiki.kernel.org/index.php/Main_Page | |
| 574 | + http://fedoraproject.org/wiki/Features/Ext4 | |
| @@ -71,6 +71,7 @@ configure specific aspects of kernel behavior to your liking. · 70 unmodified lines | ||
| 71 | 71 | java |
| 72 | 72 | ras |
| 73 | 73 | bcache |
| 74 | + ext4 | |
| 74 | 75 | pm/index |
| 75 | 76 | thunderbolt |
| 76 | 77 | LSM/index |
| @@ -856,6 +856,11 @@ · 855 unmodified lines | ||
| 856 | 856 | causing system reset or hang due to sending |
| 857 | 857 | INIT from AP to BSP. |
| 858 | 858 | |
| 859 | + disable_counter_freezing [HW] | |
| 860 | + Disable Intel PMU counter freezing feature. | |
| 861 | + The feature only exists starting from | |
| 862 | + Arch Perfmon v4 (Skylake and newer). | |
| 863 | + | |
| 859 | 864 | disable_ddw [PPC/PSERIES] |
| 860 | 865 | Disable Dynamic DMA Window support. Use this if |
| 861 | 866 | to workaround buggy firmware. |
| @@ -1063,7 +1068,7 @@ · 201 unmodified lines | ||
| 1063 | 1068 | earlyprintk=serial[,0x...[,baudrate]] |
| 1064 | 1069 | earlyprintk=ttySn[,baudrate] |
| 1065 | 1070 | earlyprintk=dbgp[debugController#] |
| 1066 | − earlyprintk=pciserial,bus:device.function[,baudrate] | |
| 1071 | + earlyprintk=pciserial[,force],bus:device.function[,baudrate] | |
| 1067 | 1072 | earlyprintk=xdbc[xhciController#] |
| 1068 | 1073 | |
| 1069 | 1074 | earlyprintk is useful when the kernel crashes before |
| @@ -1095,6 +1100,10 @@ · 25 unmodified lines | ||
| 1095 | 1100 | |
| 1096 | 1101 | The sclp output can only be used on s390. |
| 1097 | 1102 | |
| 1103 | + The optional "force" to "pciserial" enables use of a | |
| 1104 | + PCI device even when its classcode is not of the | |
| 1105 | + UART class. | |
| 1106 | + | |
| 1098 | 1107 | edac_report= [HW,EDAC] Control how to report EDAC event |
| 1099 | 1108 | Format: {"on" | "off" | "force"} |
| 1100 | 1109 | on: enable EDAC to report H/W event. May be overridden |
| @@ -1385,6 +1394,11 @@ · 284 unmodified lines | ||
| 1385 | 1394 | hvc_iucv_allow= [S390] Comma-separated list of z/VM user IDs. |
| 1386 | 1395 | If specified, z/VM IUCV HVC accepts connections |
| 1387 | 1396 | from listed z/VM user IDs only. |
| 1397 | + | |
| 1398 | + hv_nopvspin [X86,HYPER_V] Disables the paravirt spinlock optimizations | |
| 1399 | + which allow the hypervisor to 'idle' the | |
| 1400 | + guest on lock contention. | |
| 1401 | + | |
| 1388 | 1402 | keep_bootcon [KNL] |
| 1389 | 1403 | Do not unregister boot console at start. This is only |
| 1390 | 1404 | useful for debugging when something happens in the window |
| @@ -1749,12 +1763,24 @@ · 358 unmodified lines | ||
| 1749 | 1763 | nobypass [PPC/POWERNV] |
| 1750 | 1764 | Disable IOMMU bypass, using IOMMU for PCI devices. |
| 1751 | 1765 | |
| 1766 | + iommu.strict= [ARM64] Configure TLB invalidation behaviour | |
| 1767 | + Format: { "0" | "1" } | |
| 1768 | + 0 - Lazy mode. | |
| 1769 | + Request that DMA unmap operations use deferred | |
| 1770 | + invalidation of hardware TLBs, for increased | |
| 1771 | + throughput at the cost of reduced device isolation. | |
| 1772 | + Will fall back to strict mode if not supported by | |
| 1773 | + the relevant IOMMU driver. | |
| 1774 | + 1 - Strict mode (default). | |
| 1775 | + DMA unmap operations invalidate IOMMU hardware TLBs | |
| 1776 | + synchronously. | |
| 1777 | + | |
| 1752 | 1778 | iommu.passthrough= |
| 1753 | 1779 | [ARM64] Configure DMA to bypass the IOMMU by default. |
| 1754 | 1780 | Format: { "0" | "1" } |
| 1755 | 1781 | 0 - Use IOMMU translation for DMA. |
| 1756 | 1782 | 1 - Bypass the IOMMU for DMA. |
| 1757 | − unset - Use IOMMU translation for DMA. | |
| 1783 | + unset - Use value of CONFIG_IOMMU_DEFAULT_PASSTHROUGH. | |
| 1758 | 1784 | |
| 1759 | 1785 | io7= [HW] IO7 for Marvel based alpha systems |
| 1760 | 1786 | See comment before marvel_specify_io7 in |
| @@ -2274,6 +2300,8 @@ · 513 unmodified lines | ||
| 2274 | 2300 | ltpc= [NET] |
| 2275 | 2301 | Format: <io>,<irq>,<dma> |
| 2276 | 2302 | |
| 2303 | + lsm.debug [SECURITY] Enable LSM initialization debugging output. | |
| 2304 | + | |
| 2277 | 2305 | machvec= [IA-64] Force the use of a particular machine-vector |
| 2278 | 2306 | (machvec) in a generic kernel. |
| 2279 | 2307 | Example: machvec=hpzx1_swiotlb |
| @@ -2404,7 +2432,7 @@ · 124 unmodified lines | ||
| 2404 | 2432 | seconds. Use this parameter to check at some |
| 2405 | 2433 | other rate. 0 disables periodic checking. |
| 2406 | 2434 | |
| 2407 | − memtest= [KNL,X86,ARM] Enable memtest | |
| 2435 | + memtest= [KNL,X86,ARM,PPC] Enable memtest | |
| 2408 | 2436 | Format: <integer> |
| 2409 | 2437 | default : 0 <disable> |
| 2410 | 2438 | Specifies the number of memtest passes to be |
| @@ -3540,14 +3568,14 @@ · 1129 unmodified lines | ||
| 3540 | 3568 | |
| 3541 | 3569 | In kernels built with CONFIG_RCU_NOCB_CPU=y, set |
| 3542 | 3570 | the specified list of CPUs to be no-callback CPUs. |
| 3543 | − Invocation of these CPUs' RCU callbacks will | |
| 3544 | − be offloaded to "rcuox/N" kthreads created for | |
| 3545 | − that purpose, where "x" is "b" for RCU-bh, "p" | |
| 3546 | − for RCU-preempt, and "s" for RCU-sched, and "N" | |
| 3547 | − is the CPU number. This reduces OS jitter on the | |
| 3548 | − offloaded CPUs, which can be useful for HPC and | |
| 3549 | − real-time workloads. It can also improve energy | |
| 3550 | − efficiency for asymmetric multiprocessors. | |
| 3571 | + Invocation of these CPUs' RCU callbacks will be | |
| 3572 | + offloaded to "rcuox/N" kthreads created for that | |
| 3573 | + purpose, where "x" is "p" for RCU-preempt, and | |
| 3574 | + "s" for RCU-sched, and "N" is the CPU number. | |
| 3575 | + This reduces OS jitter on the offloaded CPUs, | |
| 3576 | + which can be useful for HPC and real-time | |
| 3577 | + workloads. It can also improve energy efficiency | |
| 3578 | + for asymmetric multiprocessors. | |
| 3551 | 3579 | |
| 3552 | 3580 | rcu_nocb_poll [KNL] |
| 3553 | 3581 | Rather than requiring that offloaded CPUs |
| @@ -3601,7 +3629,14 @@ · 47 unmodified lines | ||
| 3601 | 3629 | Set required age in jiffies for a |
| 3602 | 3630 | given grace period before RCU starts |
| 3603 | 3631 | soliciting quiescent-state help from |
| 3604 | − rcu_note_context_switch(). | |
| 3632 | + rcu_note_context_switch(). If not specified, the | |
| 3633 | + kernel will calculate a value based on the most | |
| 3634 | + recent settings of rcutree.jiffies_till_first_fqs | |
| 3635 | + and rcutree.jiffies_till_next_fqs. | |
| 3636 | + This calculated value may be viewed in | |
| 3637 | + rcutree.jiffies_to_sched_qs. Any attempt to | |
| 3638 | + set rcutree.jiffies_to_sched_qs will be | |
| 3639 | + cheerfully overwritten. | |
| 3605 | 3640 | |
| 3606 | 3641 | rcutree.jiffies_till_first_fqs= [KNL] |
| 3607 | 3642 | Set delay from grace-period initialization to |
| @@ -3869,12 +3904,6 @@ · 261 unmodified lines | ||
| 3869 | 3904 | rcupdate.rcu_self_test= [KNL] |
| 3870 | 3905 | Run the RCU early boot self tests |
| 3871 | 3906 | |
| 3872 | − rcupdate.rcu_self_test_bh= [KNL] | |
| 3873 | − Run the RCU bh early boot self tests | |
| 3874 | − | |
| 3875 | − rcupdate.rcu_self_test_sched= [KNL] | |
| 3876 | − Run the RCU sched early boot self tests | |
| 3877 | − | |
| 3878 | 3907 | rdinit= [KNL] |
| 3879 | 3908 | Format: <full_path> |
| 3880 | 3909 | Run specified binary instead of /init from the ramdisk, |
| @@ -4610,7 +4639,8 @@ · 729 unmodified lines | ||
| 4610 | 4639 | |
| 4611 | 4640 | usbcore.old_scheme_first= |
| 4612 | 4641 | [USB] Start with the old device initialization |
| 4613 | − scheme (default 0 = off). | |
| 4642 | + scheme, applies only to low and full-speed devices | |
| 4643 | + (default 0 = off). | |
| 4614 | 4644 | |
| 4615 | 4645 | usbcore.usbfs_memory_mb= |
| 4616 | 4646 | [USB] Memory limit (in MB) for buffers allocated by |
| @@ -4825,6 +4855,18 @@ · 208 unmodified lines | ||
| 4825 | 4855 | This is actually a boot loader parameter; the value is |
| 4826 | 4856 | passed to the kernel using a special protocol. |
| 4827 | 4857 | |
| 4858 | + vm_debug[=options] [KNL] Available with CONFIG_DEBUG_VM=y. | |
| 4859 | + May slow down system boot speed, especially when | |
| 4860 | + enabled on systems with a large amount of memory. | |
| 4861 | + All options are enabled by default, and this | |
| 4862 | + interface is meant to allow for selectively | |
| 4863 | + enabling or disabling specific virtual memory | |
| 4864 | + debugging features. | |
| 4865 | + | |
| 4866 | + Available options are: | |
| 4867 | + P Enable page structure init time poisoning | |
| 4868 | + - Disable all of the above options | |
| 4869 | + | |
| 4828 | 4870 | vmalloc=nn[KMG] [KNL,BOOT] Forces the vmalloc area to have an exact |
| 4829 | 4871 | size of <nn>. This can be used to increase the |
| 4830 | 4872 | minimum size (128MB on x86). It can also be used to |
| @@ -553,7 +553,7 @@ When nested virtualization is in use, three operating systems are involved: · 552 unmodified lines | ||
| 553 | 553 | the bare metal hypervisor, the nested hypervisor and the nested virtual |
| 554 | 554 | machine. VMENTER operations from the nested hypervisor into the nested |
| 555 | 555 | guest will always be processed by the bare metal hypervisor. If KVM is the |
| 556 | −bare metal hypervisor it wiil: | |
| 556 | +bare metal hypervisor it will: | |
| 557 | 557 | |
| 558 | 558 | - Flush the L1D cache on every switch from the nested hypervisor to the |
| 559 | 559 | nested virtual machine, so that the nested hypervisor's secrets are not |
| @@ -29,6 +29,7 @@ the Linux memory management. · 28 unmodified lines | ||
| 29 | 29 | hugetlbpage |
| 30 | 30 | idle_page_tracking |
| 31 | 31 | ksm |
| 32 | + memory-hotplug | |
| 32 | 33 | numa_memory_policy |
| 33 | 34 | pagemap |
| 34 | 35 | soft-dirty |
| @@ -1,47 +1,29 @@ | ||
| 1 | +.. _admin_guide_memory_hotplug: | |
| 2 | + | |
| 1 | 3 | ============== |
| 2 | 4 | Memory Hotplug |
| 3 | 5 | ============== |
| 4 | 6 | |
| 5 | 7 | :Created: Jul 28 2007 |
| 6 | −:Updated: Add description of notifier of memory hotplug: Oct 11 2007 | |
| 8 | +:Updated: Add some details about locking internals: Aug 20 2018 | |
| 7 | 9 | |
| 8 | 10 | This document is about memory hotplug including how-to-use and current status. |
| 9 | 11 | Because Memory Hotplug is still under development, contents of this text will |
| 10 | 12 | be changed often. |
| 11 | 13 | |
| 12 | −.. CONTENTS | |
| 13 | − | |
| 14 | − 1. Introduction | |
| 15 | − 1.1 purpose of memory hotplug | |
| 16 | − 1.2. Phases of memory hotplug | |
| 17 | − 1.3. Unit of Memory online/offline operation | |
| 18 | − 2. Kernel Configuration | |
| 19 | − 3. sysfs files for memory hotplug | |
| 20 | − 4. Physical memory hot-add phase | |
| 21 | − 4.1 Hardware(Firmware) Support | |
| 22 | − 4.2 Notify memory hot-add event by hand | |
| 23 | − 5. Logical Memory hot-add phase | |
| 24 | − 5.1. State of memory | |
| 25 | − 5.2. How to online memory | |
| 26 | − 6. Logical memory remove | |
| 27 | − 6.1 Memory offline and ZONE_MOVABLE | |
| 28 | − 6.2. How to offline memory | |
| 29 | − 7. Physical memory remove | |
| 30 | − 8. Memory hotplug event notifier | |
| 31 | − 9. Future Work List | |
| 32 | − | |
| 14 | +.. contents:: :local: | |
| 33 | 15 | |
| 34 | 16 | .. note:: |
| 35 | 17 | |
| 36 | 18 | (1) x86_64's has special implementation for memory hotplug. |
| 37 | 19 | This text does not describe it. |
| 38 | − (2) This text assumes that sysfs is mounted at /sys. | |
| 20 | + (2) This text assumes that sysfs is mounted at ``/sys``. | |
| 39 | 21 | |
| 40 | 22 | |
| 41 | 23 | Introduction |
| 42 | 24 | ============ |
| 43 | 25 | |
| 44 | −purpose of memory hotplug | |
| 26 | +Purpose of memory hotplug | |
| 45 | 27 | ------------------------- |
| 46 | 28 | |
| 47 | 29 | Memory Hotplug allows users to increase/decrease the amount of memory. |
| @@ -57,7 +39,6 @@ hardware which supports memory power management. · 9 unmodified lines | ||
| 57 | 39 | |
| 58 | 40 | Linux memory hotplug is designed for both purpose. |
| 59 | 41 | |
| 60 | − | |
| 61 | 42 | Phases of memory hotplug |
| 62 | 43 | ------------------------ |
| 63 | 44 | |
| @@ -92,7 +73,6 @@ phase by hand. · 28 unmodified lines | ||
| 92 | 73 | (However, if you writes udev's hotplug scripts for memory hotplug, these |
| 93 | 74 | phases can be execute in seamless way.) |
| 94 | 75 | |
| 95 | − | |
| 96 | 76 | Unit of Memory online/offline operation |
| 97 | 77 | --------------------------------------- |
| 98 | 78 | |
| @@ -107,10 +87,9 @@ unit upon which memory online/offline operations are to be performed. The · 8 unmodified lines | ||
| 107 | 87 | default size of a memory block is the same as memory section size unless an |
| 108 | 88 | architecture specifies otherwise. (see :ref:`memory_hotplug_sysfs_files`.) |
| 109 | 89 | |
| 110 | −To determine the size (in bytes) of a memory block please read this file: | |
| 111 | − | |
| 112 | −/sys/devices/system/memory/block_size_bytes | |
| 90 | +To determine the size (in bytes) of a memory block please read this file:: | |
| 113 | 91 | |
| 92 | + /sys/devices/system/memory/block_size_bytes | |
| 114 | 93 | |
| 115 | 94 | Kernel Configuration |
| 116 | 95 | ==================== |
| @@ -119,22 +98,22 @@ To use memory hotplug feature, kernel must be compiled with following · 2 unmodified lines | ||
| 119 | 98 | config options. |
| 120 | 99 | |
| 121 | 100 | - For all memory hotplug: |
| 122 | − - Memory model -> Sparse Memory (CONFIG_SPARSEMEM) | |
| 123 | − - Allow for memory hot-add (CONFIG_MEMORY_HOTPLUG) | |
| 101 | + - Memory model -> Sparse Memory (``CONFIG_SPARSEMEM``) | |
| 102 | + - Allow for memory hot-add (``CONFIG_MEMORY_HOTPLUG``) | |
| 124 | 103 | |
| 125 | 104 | - To enable memory removal, the following are also necessary: |
| 126 | − - Allow for memory hot remove (CONFIG_MEMORY_HOTREMOVE) | |
| 127 | − - Page Migration (CONFIG_MIGRATION) | |
| 105 | + - Allow for memory hot remove (``CONFIG_MEMORY_HOTREMOVE``) | |
| 106 | + - Page Migration (``CONFIG_MIGRATION``) | |
| 128 | 107 | |
| 129 | 108 | - For ACPI memory hotplug, the following are also necessary: |
| 130 | − - Memory hotplug (under ACPI Support menu) (CONFIG_ACPI_HOTPLUG_MEMORY) | |
| 109 | + - Memory hotplug (under ACPI Support menu) (``CONFIG_ACPI_HOTPLUG_MEMORY``) | |
| 131 | 110 | - This option can be kernel module. |
| 132 | 111 | |
| 133 | 112 | - As a related configuration, if your box has a feature of NUMA-node hotplug |
| 134 | 113 | via ACPI, then this option is necessary too. |
| 135 | 114 | |
| 136 | 115 | - ACPI0004,PNP0A05 and PNP0A06 Container Driver (under ACPI Support menu) |
| 137 | − (CONFIG_ACPI_CONTAINER). | |
| 116 | + (``CONFIG_ACPI_CONTAINER``). | |
| 138 | 117 | |
| 139 | 118 | This option can be kernel module too. |
| 140 | 119 | |
| @@ -145,10 +124,11 @@ sysfs files for memory hotplug · 4 unmodified lines | ||
| 145 | 124 | ============================== |
| 146 | 125 | |
| 147 | 126 | All memory blocks have their device information in sysfs. Each memory block |
| 148 | −is described under /sys/devices/system/memory as: | |
| 127 | +is described under ``/sys/devices/system/memory`` as:: | |
| 149 | 128 | |
| 150 | 129 | /sys/devices/system/memory/memoryXXX |
| 151 | − (XXX is the memory block id.) | |
| 130 | + | |
| 131 | +where XXX is the memory block id. | |
| 152 | 132 | |
| 153 | 133 | For the memory block covered by the sysfs directory. It is expected that all |
| 154 | 134 | memory sections in this range are present and no memory holes exist in the |
| @@ -157,7 +137,7 @@ the existence of one should not affect the hotplug capabilities of the memory · 2 unmodified lines | ||
| 157 | 137 | block. |
| 158 | 138 | |
| 159 | 139 | For example, assume 1GiB memory block size. A device for a memory starting at |
| 160 | −0x100000000 is /sys/device/system/memory/memory4:: | |
| 140 | +0x100000000 is ``/sys/device/system/memory/memory4``:: | |
| 161 | 141 | |
| 162 | 142 | (0x100000000 / 1Gib = 4) |
| 163 | 143 | |
| @@ -165,11 +145,11 @@ This device covers address range [0x100000000 ... 0x140000000) · 1 unmodified line | ||
| 165 | 145 | |
| 166 | 146 | Under each memory block, you can see 5 files: |
| 167 | 147 | |
| 168 | −- /sys/devices/system/memory/memoryXXX/phys_index | |
| 169 | −- /sys/devices/system/memory/memoryXXX/phys_device | |
| 170 | −- /sys/devices/system/memory/memoryXXX/state | |
| 171 | −- /sys/devices/system/memory/memoryXXX/removable | |
| 172 | −- /sys/devices/system/memory/memoryXXX/valid_zones | |
| 148 | +- ``/sys/devices/system/memory/memoryXXX/phys_index`` | |
| 149 | +- ``/sys/devices/system/memory/memoryXXX/phys_device`` | |
| 150 | +- ``/sys/devices/system/memory/memoryXXX/state`` | |
| 151 | +- ``/sys/devices/system/memory/memoryXXX/removable`` | |
| 152 | +- ``/sys/devices/system/memory/memoryXXX/valid_zones`` | |
| 173 | 153 | |
| 174 | 154 | =================== ============================================================ |
| 175 | 155 | ``phys_index`` read-only and contains memory block id, same as XXX. |
| @@ -207,13 +187,15 @@ Under each memory block, you can see 5 files: · 31 unmodified lines | ||
| 207 | 187 | These directories/files appear after physical memory hotplug phase. |
| 208 | 188 | |
| 209 | 189 | If CONFIG_NUMA is enabled the memoryXXX/ directories can also be accessed |
| 210 | −via symbolic links located in the /sys/devices/system/node/node* directories. | |
| 190 | +via symbolic links located in the ``/sys/devices/system/node/node*`` directories. | |
| 191 | + | |
| 192 | +For example:: | |
| 211 | 193 | |
| 212 | −For example: | |
| 213 | −/sys/devices/system/node/node0/memory9 -> ../../memory/memory9 | |
| 194 | + /sys/devices/system/node/node0/memory9 -> ../../memory/memory9 | |
| 214 | 195 | |
| 215 | −A backlink will also be created: | |
| 216 | −/sys/devices/system/memory/memory9/node0 -> ../../node/node0 | |
| 196 | +A backlink will also be created:: | |
| 197 | + | |
| 198 | + /sys/devices/system/memory/memory9/node0 -> ../../node/node0 | |
| 217 | 199 | |
| 218 | 200 | .. _memory_hotplug_physical_mem: |
| 219 | 201 | |
| @@ -240,7 +222,6 @@ If firmware supports NUMA-node hotplug, and defines an object _HID "ACPI0004", · 20 unmodified lines | ||
| 240 | 222 | calls hotplug code for all of objects which are defined in it. |
| 241 | 223 | If memory device is found, memory hotplug code will be called. |
| 242 | 224 | |
| 243 | − | |
| 244 | 225 | Notify memory hot-add event by hand |
| 245 | 226 | ----------------------------------- |
| 246 | 227 | |
| @@ -251,8 +232,9 @@ CONFIG_ARCH_MEMORY_PROBE and can be configured on powerpc, sh, and x86 · 4 unmodified lines | ||
| 251 | 232 | if hotplug is supported, although for x86 this should be handled by ACPI |
| 252 | 233 | notification. |
| 253 | 234 | |
| 254 | −Probe interface is located at | |
| 255 | −/sys/devices/system/memory/probe | |
| 235 | +Probe interface is located at:: | |
| 236 | + | |
| 237 | + /sys/devices/system/memory/probe | |
| 256 | 238 | |
| 257 | 239 | You can tell the physical address of new memory to the kernel by:: |
| 258 | 240 | |
| @@ -263,7 +245,6 @@ memory_block_size] memory range is hot-added. In this case, hotplug script is · 4 unmodified lines | ||
| 263 | 245 | not called (in current implementation). You'll have to online memory by |
| 264 | 246 | yourself. Please see :ref:`memory_hotplug_how_to_online_memory`. |
| 265 | 247 | |
| 266 | − | |
| 267 | 248 | Logical Memory hot-add phase |
| 268 | 249 | ============================ |
| 269 | 250 | |
| @@ -301,7 +282,7 @@ This sets a global policy and impacts all memory blocks that will subsequently · 31 unmodified lines | ||
| 301 | 282 | be hotplugged. Currently offline blocks keep their state. It is possible, under |
| 302 | 283 | certain circumstances, that some memory blocks will be added but will fail to |
| 303 | 284 | online. User space tools can check their "state" files |
| 304 | −(/sys/devices/system/memory/memoryXXX/state) and try to online them manually. | |
| 285 | +(``/sys/devices/system/memory/memoryXXX/state``) and try to online them manually. | |
| 305 | 286 | |
| 306 | 287 | If the automatic onlining wasn't requested, failed, or some memory block was |
| 307 | 288 | offlined it is possible to change the individual block's state by writing to the |
| @@ -334,8 +315,6 @@ available memory will be increased. · 26 unmodified lines | ||
| 334 | 315 | |
| 335 | 316 | This may be changed in future. |
| 336 | 317 | |
| 337 | − | |
| 338 | − | |
| 339 | 318 | Logical memory remove |
| 340 | 319 | ===================== |
| 341 | 320 | |
| @@ -413,87 +392,45 @@ Need more implementation yet.... · 71 unmodified lines | ||
| 413 | 392 | - Notification completion of remove works by OS to firmware. |
| 414 | 393 | - Guard from remove if not yet. |
| 415 | 394 | |
| 416 | −Memory hotplug event notifier | |
| 417 | −============================= | |
| 418 | − | |
| 419 | −Hotplugging events are sent to a notification queue. | |
| 420 | − | |
| 421 | −There are six types of notification defined in include/linux/memory.h: | |
| 422 | − | |
| 423 | −MEM_GOING_ONLINE | |
| 424 | − Generated before new memory becomes available in order to be able to | |
| 425 | − prepare subsystems to handle memory. The page allocator is still unable | |
| 426 | − to allocate from the new memory. | |
| 427 | − | |
| 428 | −MEM_CANCEL_ONLINE | |
| 429 | − Generated if MEMORY_GOING_ONLINE fails. | |
| 430 | − | |
| 431 | −MEM_ONLINE | |
| 432 | − Generated when memory has successfully brought online. The callback may | |
| 433 | − allocate pages from the new memory. | |
| 434 | − | |
| 435 | −MEM_GOING_OFFLINE | |
| 436 | − Generated to begin the process of offlining memory. Allocations are no | |
| 437 | − longer possible from the memory but some of the memory to be offlined | |
| 438 | − is still in use. The callback can be used to free memory known to a | |
| 439 | − subsystem from the indicated memory block. | |
| 440 | − | |
| 441 | −MEM_CANCEL_OFFLINE | |
| 442 | − Generated if MEMORY_GOING_OFFLINE fails. Memory is available again from | |
| 443 | − the memory block that we attempted to offline. | |
| 444 | − | |
| 445 | −MEM_OFFLINE | |
| 446 | − Generated after offlining memory is complete. | |
| 447 | − | |
| 448 | −A callback routine can be registered by calling:: | |
| 449 | − | |
| 450 | − hotplug_memory_notifier(callback_func, priority) | |
| 451 | − | |
| 452 | −Callback functions with higher values of priority are called before callback | |
| 453 | −functions with lower values. | |
| 454 | 395 | |
| 455 | −A callback function must have the following prototype:: | |
| 396 | +Locking Internals | |
| 397 | +================= | |
| 456 | 398 | |
| 457 | − int callback_func( | |
| 458 | − struct notifier_block *self, unsigned long action, void *arg); | |
| 399 | +When adding/removing memory that uses memory block devices (i.e. ordinary RAM), | |
| 400 | +the device_hotplug_lock should be held to: | |
| 459 | 401 | |
| 460 | −The first argument of the callback function (self) is a pointer to the block | |
| 461 | −of the notifier chain that points to the callback function itself. | |
| 462 | −The second argument (action) is one of the event types described above. | |
| 463 | −The third argument (arg) passes a pointer of struct memory_notify:: | |
| 402 | +- synchronize against online/offline requests (e.g. via sysfs). This way, memory | |
| 403 | + block devices can only be accessed (.online/.state attributes) by user | |
| 404 | + space once memory has been fully added. And when removing memory, we | |
| 405 | + know nobody is in critical sections. | |
| 406 | +- synchronize against CPU hotplug and similar (e.g. relevant for ACPI and PPC) | |
| 464 | 407 | |
| 465 | − struct memory_notify { | |
| 466 | − unsigned long start_pfn; | |
| 467 | − unsigned long nr_pages; | |
| 468 | − int status_change_nid_normal; | |
| 469 | − int status_change_nid_high; | |
| 470 | − int status_change_nid; | |
| 471 | − } | |
| 408 | +Especially, there is a possible lock inversion that is avoided using | |
| 409 | +device_hotplug_lock when adding memory and user space tries to online that | |
| 410 | +memory faster than expected: | |
| 472 | 411 | |
| 473 | −- start_pfn is start_pfn of online/offline memory. | |
| 474 | −- nr_pages is # of pages of online/offline memory. | |
| 475 | −- status_change_nid_normal is set node id when N_NORMAL_MEMORY of nodemask | |
| 476 | − is (will be) set/clear, if this is -1, then nodemask status is not changed. | |
| 477 | −- status_change_nid_high is set node id when N_HIGH_MEMORY of nodemask | |
| 478 | − is (will be) set/clear, if this is -1, then nodemask status is not changed. | |
| 479 | −- status_change_nid is set node id when N_MEMORY of nodemask is (will be) | |
| 480 | − set/clear. It means a new(memoryless) node gets new memory by online and a | |
| 481 | − node loses all memory. If this is -1, then nodemask status is not changed. | |
| 412 | +- device_online() will first take the device_lock(), followed by | |
| 413 | + mem_hotplug_lock | |
| 414 | +- add_memory_resource() will first take the mem_hotplug_lock, followed by | |
| 415 | + the device_lock() (while creating the devices, during bus_add_device()). | |
| 482 | 416 | |
| 483 | − If status_changed_nid* >= 0, callback should create/discard structures for the | |
| 484 | − node if necessary. | |
| 417 | +As the device is visible to user space before taking the device_lock(), this | |
| 418 | +can result in a lock inversion. | |
| 485 | 419 | |
| 486 | −The callback routine shall return one of the values | |
| 487 | −NOTIFY_DONE, NOTIFY_OK, NOTIFY_BAD, NOTIFY_STOP | |
| 488 | −defined in include/linux/notifier.h | |
| 420 | +onlining/offlining of memory should be done via device_online()/ | |
| 421 | +device_offline() - to make sure it is properly synchronized to actions | |
| 422 | +via sysfs. Holding device_hotplug_lock is advised (to e.g. protect online_type) | |
| 489 | 423 | |
| 490 | −NOTIFY_DONE and NOTIFY_OK have no effect on the further processing. | |
| 424 | +When adding/removing/onlining/offlining memory or adding/removing | |
| 425 | +heterogeneous/device memory, we should always hold the mem_hotplug_lock in | |
| 426 | +write mode to serialise memory hotplug (e.g. access to global/zone | |
| 427 | +variables). | |
| 491 | 428 | |
| 492 | −NOTIFY_BAD is used as response to the MEM_GOING_ONLINE, MEM_GOING_OFFLINE, | |
| 493 | −MEM_ONLINE, or MEM_OFFLINE action to cancel hotplugging. It stops | |
| 494 | −further processing of the notification queue. | |
| 429 | +In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read | |
| 430 | +mode allows for a quite efficient get_online_mems/put_online_mems | |
| 431 | +implementation, so code accessing memory can protect from that memory | |
| 432 | +vanishing. | |
| 495 | 433 | |
| 496 | −NOTIFY_STOP stops further processing of the notification queue. | |
| 497 | 434 | |
| 498 | 435 | Future Work |
| 499 | 436 | =========== |
| @@ -150,7 +150,7 @@ data structures necessary to handle the given policy and, possibly, to add · 149 unmodified lines | ||
| 150 | 150 | a governor ``sysfs`` interface to it. Next, the governor is started by |
| 151 | 151 | invoking its ``->start()`` callback. |
| 152 | 152 | |
| 153 | −That callback it expected to register per-CPU utilization update callbacks for | |
| 153 | +That callback is expected to register per-CPU utilization update callbacks for | |
| 154 | 154 | all of the online CPUs belonging to the given policy with the CPU scheduler. |
| 155 | 155 | The utilization update callbacks will be invoked by the CPU scheduler on |
| 156 | 156 | important events, like task enqueue and dequeue, on every iteration of the |
| @@ -465,6 +465,13 @@ Next, the following policy attributes have special meaning if · 464 unmodified lines | ||
| 465 | 465 | policy for the time interval between the last two invocations of the |
| 466 | 466 | driver's utilization update callback by the CPU scheduler for that CPU. |
| 467 | 467 | |
| 468 | +One more policy attribute is present if the `HWP feature is enabled in the | |
| 469 | +processor <Active Mode With HWP_>`_: | |
| 470 | + | |
| 471 | +``base_frequency`` | |
| 472 | + Shows the base frequency of the CPU. Any frequency above this will be | |
| 473 | + in the turbo frequency range. | |
| 474 | + | |
| 468 | 475 | The meaning of these attributes in the `passive mode <Passive Mode_>`_ is the |
| 469 | 476 | same as for other scaling drivers. |
| 470 | 477 | |
| @@ -26,23 +26,34 @@ information is helpful. Any exploit code is very helpful and will not · 25 unmodified lines | ||
| 26 | 26 | be released without consent from the reporter unless it has already been |
| 27 | 27 | made public. |
| 28 | 28 | |
| 29 | −Disclosure | |
| 30 | −---------- | |
| 31 | − | |
| 32 | −The goal of the Linux kernel security team is to work with the bug | |
| 33 | −submitter to understand and fix the bug. We prefer to publish the fix as | |
| 34 | −soon as possible, but try to avoid public discussion of the bug itself | |
| 35 | −and leave that to others. | |
| 36 | − | |
| 37 | −Publishing the fix may be delayed when the bug or the fix is not yet | |
| 38 | −fully understood, the solution is not well-tested or for vendor | |
| 39 | −coordination. However, we expect these delays to be short, measurable in | |
| 40 | −days, not weeks or months. A release date is negotiated by the security | |
| 41 | −team working with the bug submitter as well as vendors. However, the | |
| 42 | −kernel security team holds the final say when setting a timeframe. The | |
| 43 | −timeframe varies from immediate (esp. if it's already publicly known bug) | |
| 44 | −to a few weeks. As a basic default policy, we expect report date to | |
| 45 | −release date to be on the order of 7 days. | |
| 29 | +Disclosure and embargoed information | |
| 30 | +------------------------------------ | |
| 31 | + | |
| 32 | +The security list is not a disclosure channel. For that, see Coordination | |
| 33 | +below. | |
| 34 | + | |
| 35 | +Once a robust fix has been developed, our preference is to release the | |
| 36 | +fix in a timely fashion, treating it no differently than any of the other | |
| 37 | +thousands of changes and fixes the Linux kernel project releases every | |
| 38 | +month. | |
| 39 | + | |
| 40 | +However, at the request of the reporter, we will postpone releasing the | |
| 41 | +fix for up to 5 business days after the date of the report or after the | |
| 42 | +embargo has lifted; whichever comes first. The only exception to that | |
| 43 | +rule is if the bug is publicly known, in which case the preference is to | |
| 44 | +release the fix as soon as it's available. | |
| 45 | + | |
| 46 | +Whilst embargoed information may be shared with trusted individuals in | |
| 47 | +order to develop a fix, such information will not be published alongside | |
| 48 | +the fix or on any other disclosure channel without the permission of the | |
| 49 | +reporter. This includes but is not limited to the original bug report | |
| 50 | +and followup discussions (if any), exploits, CVE information or the | |
| 51 | +identity of the reporter. | |
| 52 | + | |
| 53 | +In other words our only interest is in getting bugs fixed. All other | |
| 54 | +information submitted to the security list and any followup discussions | |
| 55 | +of the report are treated confidentially even after the embargo has been | |
| 56 | +lifted, in perpetuity. | |
| 46 | 57 | |
| 47 | 58 | Coordination |
| 48 | 59 | ------------ |
| @@ -68,7 +79,7 @@ may delay the bug handling. If a reporter wishes to have a CVE identifier · 19 unmodified lines | ||
| 68 | 79 | assigned ahead of public disclosure, they will need to contact the private |
| 69 | 80 | linux-distros list, described above. When such a CVE identifier is known |
| 70 | 81 | before a patch is provided, it is desirable to mention it in the commit |
| 71 | −message, though. | |
| 82 | +message if the reporter agrees. | |
| 72 | 83 | |
| 73 | 84 | Non-disclosure agreements |
| 74 | 85 | ------------------------- |
| @@ -1,50 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - this file | |
| 3 | −Booting | |
| 4 | − - requirements for booting | |
| 5 | −CCN.txt | |
| 6 | − - Cache Coherent Network ring-bus and perf PMU driver. | |
| 7 | −Interrupts | |
| 8 | − - ARM Interrupt subsystem documentation | |
| 9 | −IXP4xx | |
| 10 | − - Intel IXP4xx Network processor. | |
| 11 | −Netwinder | |
| 12 | − - Netwinder specific documentation | |
| 13 | −Porting | |
| 14 | − - Symbol definitions for porting Linux to a new ARM machine. | |
| 15 | −Setup | |
| 16 | − - Kernel initialization parameters on ARM Linux | |
| 17 | −README | |
| 18 | − - General ARM documentation | |
| 19 | −SA1100/ | |
| 20 | − - SA1100 documentation | |
| 21 | −Samsung-S3C24XX/ | |
| 22 | − - S3C24XX ARM Linux Overview | |
| 23 | −SPEAr/ | |
| 24 | − - ST SPEAr platform Linux Overview | |
| 25 | −VFP/ | |
| 26 | − - Release notes for Linux Kernel Vector Floating Point support code | |
| 27 | −cluster-pm-race-avoidance.txt | |
| 28 | − - Algorithm for CPU and Cluster setup/teardown | |
| 29 | −empeg/ | |
| 30 | − - Ltd's Empeg MP3 Car Audio Player | |
| 31 | −firmware.txt | |
| 32 | − - Secure firmware registration and calling. | |
| 33 | −kernel_mode_neon.txt | |
| 34 | − - How to use NEON instructions in kernel mode | |
| 35 | −kernel_user_helpers.txt | |
| 36 | − - Helper functions in kernel space made available for userspace. | |
| 37 | −mem_alignment | |
| 38 | − - alignment abort handler documentation | |
| 39 | −memory.txt | |
| 40 | − - description of the virtual memory layout | |
| 41 | −nwfpe/ | |
| 42 | − - NWFPE floating point emulator documentation | |
| 43 | −swp_emulation | |
| 44 | − - SWP/SWPB emulation handler/logging description | |
| 45 | −tcm.txt | |
| 46 | − - ARM Tightly Coupled Memory | |
| 47 | −uefi.txt | |
| 48 | − - [U]EFI configuration and runtime services documentation | |
| 49 | −vlocks.txt | |
| 50 | − - Voting locks, low-level mechanism relying on memory system atomic writes. | |
| @@ -26,6 +26,7 @@ Offset Value Purpose · 25 unmodified lines | ||
| 26 | 26 | 0x20 0xfcba0d10 (Magic cookie) AFTR |
| 27 | 27 | 0x24 exynos_cpu_resume_ns AFTR |
| 28 | 28 | 0x28 + 4*cpu 0x8 (Magic cookie, Exynos3250) AFTR |
| 29 | +0x28 0x0 or last value during resume (Exynos542x) System suspend | |
| 29 | 30 | |
| 30 | 31 | |
| 31 | 32 | 2. Secure mode |
| @@ -78,11 +78,11 @@ HWCAP_EVTSTRM · 77 unmodified lines | ||
| 78 | 78 | |
| 79 | 79 | HWCAP_AES |
| 80 | 80 | |
| 81 | − Functionality implied by ID_AA64ISAR1_EL1.AES == 0b0001. | |
| 81 | + Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0001. | |
| 82 | 82 | |
| 83 | 83 | HWCAP_PMULL |
| 84 | 84 | |
| 85 | − Functionality implied by ID_AA64ISAR1_EL1.AES == 0b0010. | |
| 85 | + Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0010. | |
| 86 | 86 | |
| 87 | 87 | HWCAP_SHA1 |
| 88 | 88 | |
| @@ -153,7 +153,7 @@ HWCAP_ASIMDDP · 64 unmodified lines | ||
| 153 | 153 | |
| 154 | 154 | HWCAP_SHA512 |
| 155 | 155 | |
| 156 | − Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0002. | |
| 156 | + Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0010. | |
| 157 | 157 | |
| 158 | 158 | HWCAP_SVE |
| 159 | 159 | |
| @@ -173,8 +173,12 @@ HWCAP_USCAT · 13 unmodified lines | ||
| 173 | 173 | |
| 174 | 174 | HWCAP_ILRCPC |
| 175 | 175 | |
| 176 | − Functionality implied by ID_AA64ISR1_EL1.LRCPC == 0b0002. | |
| 176 | + Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0010. | |
| 177 | 177 | |
| 178 | 178 | HWCAP_FLAGM |
| 179 | 179 | |
| 180 | 180 | Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0001. |
| 181 | + | |
| 182 | +HWCAP_SSBS | |
| 183 | + | |
| 184 | + Functionality implied by ID_AA64PFR1_EL1.SSBS == 0b0010. | |
| @@ -0,0 +1,38 @@ | ||
| 1 | +HugeTLBpage on ARM64 | |
| 2 | +==================== | |
| 3 | + | |
| 4 | +Hugepage relies on making efficient use of TLBs to improve performance of | |
| 5 | +address translations. The benefit depends on both - | |
| 6 | + | |
| 7 | + - the size of hugepages | |
| 8 | + - size of entries supported by the TLBs | |
| 9 | + | |
| 10 | +The ARM64 port supports two flavours of hugepages. | |
| 11 | + | |
| 12 | +1) Block mappings at the pud/pmd level | |
| 13 | +-------------------------------------- | |
| 14 | + | |
| 15 | +These are regular hugepages where a pmd or a pud page table entry points to a | |
| 16 | +block of memory. Regardless of the supported size of entries in TLB, block | |
| 17 | +mappings reduce the depth of page table walk needed to translate hugepage | |
| 18 | +addresses. | |
| 19 | + | |
| 20 | +2) Using the Contiguous bit | |
| 21 | +--------------------------- | |
| 22 | + | |
| 23 | +The architecture provides a contiguous bit in the translation table entries | |
| 24 | +(D4.5.3, ARM DDI 0487C.a) that hints to the MMU to indicate that it is one of a | |
| 25 | +contiguous set of entries that can be cached in a single TLB entry. | |
| 26 | + | |
| 27 | +The contiguous bit is used in Linux to increase the mapping size at the pmd and | |
| 28 | +pte (last) level. The number of supported contiguous entries varies by page size | |
| 29 | +and level of the page table. | |
| 30 | + | |
| 31 | + | |
| 32 | +The following hugepage sizes are supported - | |
| 33 | + | |
| 34 | + CONT PTE PMD CONT PMD PUD | |
| 35 | + -------- --- -------- --- | |
| 36 | + 4K: 64K 2M 32M 1G | |
| 37 | + 16K: 2M 32M 1G | |
| 38 | + 64K: 2M 512M 16G | |
| @@ -56,6 +56,7 @@ stable kernels. · 55 unmodified lines | ||
| 56 | 56 | | ARM | Cortex-A72 | #853709 | N/A | |
| 57 | 57 | | ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 | |
| 58 | 58 | | ARM | Cortex-A55 | #1024718 | ARM64_ERRATUM_1024718 | |
| 59 | +| ARM | Cortex-A76 | #1188873 | ARM64_ERRATUM_1188873 | | |
| 59 | 60 | | ARM | MMU-500 | #841119,#826419 | N/A | |
| 60 | 61 | | | | | | |
| 61 | 62 | | Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 | |
| @@ -1,34 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - This file | |
| 3 | −bfq-iosched.txt | |
| 4 | − - BFQ IO scheduler and its tunables | |
| 5 | −biodoc.txt | |
| 6 | − - Notes on the Generic Block Layer Rewrite in Linux 2.5 | |
| 7 | −biovecs.txt | |
| 8 | − - Immutable biovecs and biovec iterators | |
| 9 | −capability.txt | |
| 10 | − - Generic Block Device Capability (/sys/block/<device>/capability) | |
| 11 | −cfq-iosched.txt | |
| 12 | − - CFQ IO scheduler tunables | |
| 13 | −cmdline-partition.txt | |
| 14 | − - how to specify block device partitions on kernel command line | |
| 15 | −data-integrity.txt | |
| 16 | − - Block data integrity | |
| 17 | −deadline-iosched.txt | |
| 18 | − - Deadline IO scheduler tunables | |
| 19 | −ioprio.txt | |
| 20 | − - Block io priorities (in CFQ scheduler) | |
| 21 | −pr.txt | |
| 22 | − - Block layer support for Persistent Reservations | |
| 23 | −null_blk.txt | |
| 24 | − - Null block for block-layer benchmarking. | |
| 25 | −queue-sysfs.txt | |
| 26 | − - Queue's sysfs entries | |
| 27 | −request.txt | |
| 28 | − - The members of struct request (in include/linux/blkdev.h) | |
| 29 | −stat.txt | |
| 30 | − - Block layer statistics in /sys/block/<device>/stat | |
| 31 | −switching-sched.txt | |
| 32 | − - Switching I/O schedulers at runtime | |
| 33 | −writeback_cache_control.txt | |
| 34 | − - Control of volatile write back caches | |
| @@ -1,18 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - this file | |
| 3 | −README.DAC960 | |
| 4 | − - info on Mylex DAC960/DAC1100 PCI RAID Controller Driver for Linux. | |
| 5 | −cciss.txt | |
| 6 | − - info, major/minor #'s for Compaq's SMART Array Controllers. | |
| 7 | −cpqarray.txt | |
| 8 | − - info on using Compaq's SMART2 Intelligent Disk Array Controllers. | |
| 9 | −floppy.txt | |
| 10 | − - notes and driver options for the floppy disk driver. | |
| 11 | −mflash.txt | |
| 12 | − - info on mGine m(g)flash driver for linux. | |
| 13 | −nbd.txt | |
| 14 | − - info on a TCP implementation of a network block device. | |
| 15 | −paride.txt | |
| 16 | − - information about the parallel port IDE subsystem. | |
| 17 | −ramdisk.txt | |
| 18 | − - short guide on how to set up and use the RAM disk. | |
| @@ -1,756 +0,0 @@ | ||
| 1 | − Linux Driver for Mylex DAC960/AcceleRAID/eXtremeRAID PCI RAID Controllers | |
| 2 | − | |
| 3 | − Version 2.2.11 for Linux 2.2.19 | |
| 4 | − Version 2.4.11 for Linux 2.4.12 | |
| 5 | − | |
| 6 | − PRODUCTION RELEASE | |
| 7 | − | |
| 8 | − 11 October 2001 | |
| 9 | − | |
| 10 | − Leonard N. Zubkoff | |
| 11 | − Dandelion Digital | |
| 12 | − lnz@dandelion.com | |
| 13 | − | |
| 14 | − Copyright 1998-2001 by Leonard N. Zubkoff <lnz@dandelion.com> | |
| 15 | − | |
| 16 | − | |
| 17 | − INTRODUCTION | |
| 18 | − | |
| 19 | −Mylex, Inc. designs and manufactures a variety of high performance PCI RAID | |
| 20 | −controllers. Mylex Corporation is located at 34551 Ardenwood Blvd., Fremont, | |
| 21 | −California 94555, USA and can be reached at 510.796.6100 or on the World Wide | |
| 22 | −Web at http://www.mylex.com. Mylex Technical Support can be reached by | |
| 23 | −electronic mail at mylexsup@us.ibm.com, by voice at 510.608.2400, or by FAX at | |
| 24 | −510.745.7715. Contact information for offices in Europe and Japan is available | |
| 25 | −on their Web site. | |
| 26 | − | |
| 27 | −The latest information on Linux support for DAC960 PCI RAID Controllers, as | |
| 28 | −well as the most recent release of this driver, will always be available from | |
| 29 | −my Linux Home Page at URL "http://www.dandelion.com/Linux/". The Linux DAC960 | |
| 30 | −driver supports all current Mylex PCI RAID controllers including the new | |
| 31 | −eXtremeRAID 2000/3000 and AcceleRAID 352/170/160 models which have an entirely | |
| 32 | −new firmware interface from the older eXtremeRAID 1100, AcceleRAID 150/200/250, | |
| 33 | −and DAC960PJ/PG/PU/PD/PL. See below for a complete controller list as well as | |
| 34 | −minimum firmware version requirements. For simplicity, in most places this | |
| 35 | −documentation refers to DAC960 generically rather than explicitly listing all | |
| 36 | −the supported models. | |
| 37 | − | |
| 38 | −Driver bug reports should be sent via electronic mail to "lnz@dandelion.com". | |
| 39 | −Please include with the bug report the complete configuration messages reported | |
| 40 | −by the driver at startup, along with any subsequent system messages relevant to | |
| 41 | −the controller's operation, and a detailed description of your system's | |
| 42 | −hardware configuration. Driver bugs are actually quite rare; if you encounter | |
| 43 | −problems with disks being marked offline, for example, please contact Mylex | |
| 44 | −Technical Support as the problem is related to the hardware configuration | |
| 45 | −rather than the Linux driver. | |
| 46 | − | |
| 47 | −Please consult the RAID controller documentation for detailed information | |
| 48 | −regarding installation and configuration of the controllers. This document | |
| 49 | −primarily provides information specific to the Linux support. | |
| 50 | − | |
| 51 | − | |
| 52 | − DRIVER FEATURES | |
| 53 | − | |
| 54 | −The DAC960 RAID controllers are supported solely as high performance RAID | |
| 55 | −controllers, not as interfaces to arbitrary SCSI devices. The Linux DAC960 | |
| 56 | −driver operates at the block device level, the same level as the SCSI and IDE | |
| 57 | −drivers. Unlike other RAID controllers currently supported on Linux, the | |
| 58 | −DAC960 driver is not dependent on the SCSI subsystem, and hence avoids all the | |
| 59 | −complexity and unnecessary code that would be associated with an implementation | |
| 60 | −as a SCSI driver. The DAC960 driver is designed for as high a performance as | |
| 61 | −possible with no compromises or extra code for compatibility with lower | |
| 62 | −performance devices. The DAC960 driver includes extensive error logging and | |
| 63 | −online configuration management capabilities. Except for initial configuration | |
| 64 | −of the controller and adding new disk drives, most everything can be handled | |
| 65 | −from Linux while the system is operational. | |
| 66 | − | |
| 67 | −The DAC960 driver is architected to support up to 8 controllers per system. | |
| 68 | −Each DAC960 parallel SCSI controller can support up to 15 disk drives per | |
| 69 | −channel, for a maximum of 60 drives on a four channel controller; the fibre | |
| 70 | −channel eXtremeRAID 3000 controller supports up to 125 disk drives per loop for | |
| 71 | −a total of 250 drives. The drives installed on a controller are divided into | |
| 72 | −one or more "Drive Groups", and then each Drive Group is subdivided further | |
| 73 | −into 1 to 32 "Logical Drives". Each Logical Drive has a specific RAID Level | |
| 74 | −and caching policy associated with it, and it appears to Linux as a single | |
| 75 | −block device. Logical Drives are further subdivided into up to 7 partitions | |
| 76 | −through the normal Linux and PC disk partitioning schemes. Logical Drives are | |
| 77 | −also known as "System Drives", and Drive Groups are also called "Packs". Both | |
| 78 | −terms are in use in the Mylex documentation; I have chosen to standardize on | |
| 79 | −the more generic "Logical Drive" and "Drive Group". | |
| 80 | − | |
| 81 | −DAC960 RAID disk devices are named in the style of the obsolete Device File | |
| 82 | −System (DEVFS). The device corresponding to Logical Drive D on Controller C | |
| 83 | −is referred to as /dev/rd/cCdD, and the partitions are called /dev/rd/cCdDp1 | |
| 84 | −through /dev/rd/cCdDp7. For example, partition 3 of Logical Drive 5 on | |
| 85 | −Controller 2 is referred to as /dev/rd/c2d5p3. Note that unlike with SCSI | |
| 86 | −disks the device names will not change in the event of a disk drive failure. | |
| 87 | −The DAC960 driver is assigned major numbers 48 - 55 with one major number per | |
| 88 | −controller. The 8 bits of minor number are divided into 5 bits for the Logical | |
| 89 | −Drive and 3 bits for the partition. | |
| 90 | − | |
| 91 | − | |
| 92 | − SUPPORTED DAC960/AcceleRAID/eXtremeRAID PCI RAID CONTROLLERS | |
| 93 | − | |
| 94 | −The following list comprises the supported DAC960, AcceleRAID, and eXtremeRAID | |
| 95 | −PCI RAID Controllers as of the date of this document. It is recommended that | |
| 96 | −anyone purchasing a Mylex PCI RAID Controller not in the following table | |
| 97 | −contact the author beforehand to verify that it is or will be supported. | |
| 98 | − | |
| 99 | −eXtremeRAID 3000 | |
| 100 | − 1 Wide Ultra-2/LVD SCSI channel | |
| 101 | − 2 External Fibre FC-AL channels | |
| 102 | − 233MHz StrongARM SA 110 Processor | |
| 103 | − 64 Bit 33MHz PCI (backward compatible with 32 Bit PCI slots) | |
| 104 | − 32MB/64MB ECC SDRAM Memory | |
| 105 | − | |
| 106 | −eXtremeRAID 2000 | |
| 107 | − 4 Wide Ultra-160 LVD SCSI channels | |
| 108 | − 233MHz StrongARM SA 110 Processor | |
| 109 | − 64 Bit 33MHz PCI (backward compatible with 32 Bit PCI slots) | |
| 110 | − 32MB/64MB ECC SDRAM Memory | |
| 111 | − | |
| 112 | −AcceleRAID 352 | |
| 113 | − 2 Wide Ultra-160 LVD SCSI channels | |
| 114 | − 100MHz Intel i960RN RISC Processor | |
| 115 | − 64 Bit 33MHz PCI (backward compatible with 32 Bit PCI slots) | |
| 116 | − 32MB/64MB ECC SDRAM Memory | |
| 117 | − | |
| 118 | −AcceleRAID 170 | |
| 119 | − 1 Wide Ultra-160 LVD SCSI channel | |
| 120 | − 100MHz Intel i960RM RISC Processor | |
| 121 | − 16MB/32MB/64MB ECC SDRAM Memory | |
| 122 | − | |
| 123 | −AcceleRAID 160 (AcceleRAID 170LP) | |
| 124 | − 1 Wide Ultra-160 LVD SCSI channel | |
| 125 | − 100MHz Intel i960RS RISC Processor | |
| 126 | − Built in 16M ECC SDRAM Memory | |
| 127 | − PCI Low Profile Form Factor - fit for 2U height | |
| 128 | − | |
| 129 | −eXtremeRAID 1100 (DAC1164P) | |
| 130 | − 3 Wide Ultra-2/LVD SCSI channels | |
| 131 | − 233MHz StrongARM SA 110 Processor | |
| 132 | − 64 Bit 33MHz PCI (backward compatible with 32 Bit PCI slots) | |
| 133 | − 16MB/32MB/64MB Parity SDRAM Memory with Battery Backup | |
| 134 | − | |
| 135 | −AcceleRAID 250 (DAC960PTL1) | |
| 136 | − Uses onboard Symbios SCSI chips on certain motherboards | |
| 137 | − Also includes one onboard Wide Ultra-2/LVD SCSI Channel | |
| 138 | − 66MHz Intel i960RD RISC Processor | |
| 139 | − 4MB/8MB/16MB/32MB/64MB/128MB ECC EDO Memory | |
| 140 | − | |
| 141 | −AcceleRAID 200 (DAC960PTL0) | |
| 142 | − Uses onboard Symbios SCSI chips on certain motherboards | |
| 143 | − Includes no onboard SCSI Channels | |
| 144 | − 66MHz Intel i960RD RISC Processor | |
| 145 | − 4MB/8MB/16MB/32MB/64MB/128MB ECC EDO Memory | |
| 146 | − | |
| 147 | −AcceleRAID 150 (DAC960PRL) | |
| 148 | − Uses onboard Symbios SCSI chips on certain motherboards | |
| 149 | − Also includes one onboard Wide Ultra-2/LVD SCSI Channel | |
| 150 | − 33MHz Intel i960RP RISC Processor | |
| 151 | − 4MB Parity EDO Memory | |
| 152 | − | |
| 153 | −DAC960PJ 1/2/3 Wide Ultra SCSI-3 Channels | |
| 154 | − 66MHz Intel i960RD RISC Processor | |
| 155 | − 4MB/8MB/16MB/32MB/64MB/128MB ECC EDO Memory | |
| 156 | − | |
| 157 | −DAC960PG 1/2/3 Wide Ultra SCSI-3 Channels | |
| 158 | − 33MHz Intel i960RP RISC Processor | |
| 159 | − 4MB/8MB ECC EDO Memory | |
| 160 | − | |
| 161 | −DAC960PU 1/2/3 Wide Ultra SCSI-3 Channels | |
| 162 | − Intel i960CF RISC Processor | |
| 163 | − 4MB/8MB EDRAM or 2MB/4MB/8MB/16MB/32MB DRAM Memory | |
| 164 | − | |
| 165 | −DAC960PD 1/2/3 Wide Fast SCSI-2 Channels | |
| 166 | − Intel i960CF RISC Processor | |
| 167 | − 4MB/8MB EDRAM or 2MB/4MB/8MB/16MB/32MB DRAM Memory | |
| 168 | − | |
| 169 | −DAC960PL 1/2/3 Wide Fast SCSI-2 Channels | |
| 170 | − Intel i960 RISC Processor | |
| 171 | − 2MB/4MB/8MB/16MB/32MB DRAM Memory | |
| 172 | − | |
| 173 | −DAC960P 1/2/3 Wide Fast SCSI-2 Channels | |
| 174 | − Intel i960 RISC Processor | |
| 175 | − 2MB/4MB/8MB/16MB/32MB DRAM Memory | |
| 176 | − | |
| 177 | −For the eXtremeRAID 2000/3000 and AcceleRAID 352/170/160, firmware version | |
| 178 | −6.00-01 or above is required. | |
| 179 | − | |
| 180 | −For the eXtremeRAID 1100, firmware version 5.06-0-52 or above is required. | |
| 181 | − | |
| 182 | −For the AcceleRAID 250, 200, and 150, firmware version 4.06-0-57 or above is | |
| 183 | −required. | |
| 184 | − | |
| 185 | −For the DAC960PJ and DAC960PG, firmware version 4.06-0-00 or above is required. | |
| 186 | − | |
| 187 | −For the DAC960PU, DAC960PD, DAC960PL, and DAC960P, either firmware version | |
| 188 | −3.51-0-04 or above is required (for dual Flash ROM controllers), or firmware | |
| 189 | −version 2.73-0-00 or above is required (for single Flash ROM controllers) | |
| 190 | − | |
| 191 | −Please note that not all SCSI disk drives are suitable for use with DAC960 | |
| 192 | −controllers, and only particular firmware versions of any given model may | |
| 193 | −actually function correctly. Similarly, not all motherboards have a BIOS that | |
| 194 | −properly initializes the AcceleRAID 250, AcceleRAID 200, AcceleRAID 150, | |
| 195 | −DAC960PJ, and DAC960PG because the Intel i960RD/RP is a multi-function device. | |
| 196 | −If in doubt, contact Mylex RAID Technical Support (mylexsup@us.ibm.com) to | |
| 197 | −verify compatibility. Mylex makes available a hard disk compatibility list at | |
| 198 | −http://www.mylex.com/support/hdcomp/hd-lists.html. | |
| 199 | − | |
| 200 | − | |
| 201 | − DRIVER INSTALLATION | |
| 202 | − | |
| 203 | −This distribution was prepared for Linux kernel version 2.2.19 or 2.4.12. | |
| 204 | − | |
| 205 | −To install the DAC960 RAID driver, you may use the following commands, | |
| 206 | −replacing "/usr/src" with wherever you keep your Linux kernel source tree: | |
| 207 | − | |
| 208 | − cd /usr/src | |
| 209 | − tar -xvzf DAC960-2.2.11.tar.gz (or DAC960-2.4.11.tar.gz) | |
| 210 | − mv README.DAC960 linux/Documentation | |
| 211 | − mv DAC960.[ch] linux/drivers/block | |
| 212 | − patch -p0 < DAC960.patch (if DAC960.patch is included) | |
| 213 | − cd linux | |
| 214 | − make config | |
| 215 | − make bzImage (or zImage) | |
| 216 | − | |
| 217 | −Then install "arch/x86/boot/bzImage" or "arch/x86/boot/zImage" as your | |
| 218 | −standard kernel, run lilo if appropriate, and reboot. | |
| 219 | − | |
| 220 | −To create the necessary devices in /dev, the "make_rd" script included in | |
| 221 | −"DAC960-Utilities.tar.gz" from http://www.dandelion.com/Linux/ may be used. | |
| 222 | −LILO 21 and FDISK v2.9 include DAC960 support; also included in this archive | |
| 223 | −are patches to LILO 20 and FDISK v2.8 that add DAC960 support, along with | |
| 224 | −statically linked executables of LILO and FDISK. This modified version of LILO | |
| 225 | −will allow booting from a DAC960 controller and/or mounting the root file | |
| 226 | −system from a DAC960. | |
| 227 | − | |
| 228 | −Red Hat Linux 6.0 and SuSE Linux 6.1 include support for Mylex PCI RAID | |
| 229 | −controllers. Installing directly onto a DAC960 may be problematic from other | |
| 230 | −Linux distributions until their installation utilities are updated. | |
| 231 | − | |
| 232 | − | |
| 233 | − INSTALLATION NOTES | |
| 234 | − | |
| 235 | −Before installing Linux or adding DAC960 logical drives to an existing Linux | |
| 236 | −system, the controller must first be configured to provide one or more logical | |
| 237 | −drives using the BIOS Configuration Utility or DACCF. Please note that since | |
| 238 | −there are only at most 6 usable partitions on each logical drive, systems | |
| 239 | −requiring more partitions should subdivide a drive group into multiple logical | |
| 240 | −drives, each of which can have up to 6 usable partitions. Also, note that with | |
| 241 | −large disk arrays it is advisable to enable the 8GB BIOS Geometry (255/63) | |
| 242 | −rather than accepting the default 2GB BIOS Geometry (128/32); failing to so do | |
| 243 | −will cause the logical drive geometry to have more than 65535 cylinders which | |
| 244 | −will make it impossible for FDISK to be used properly. The 8GB BIOS Geometry | |
| 245 | −can be enabled by configuring the DAC960 BIOS, which is accessible via Alt-M | |
| 246 | −during the BIOS initialization sequence. | |
| 247 | − | |
| 248 | −For maximum performance and the most efficient E2FSCK performance, it is | |
| 249 | −recommended that EXT2 file systems be built with a 4KB block size and 16 block | |
| 250 | −stride to match the DAC960 controller's 64KB default stripe size. The command | |
| 251 | −"mke2fs -b 4096 -R stride=16 <device>" is appropriate. Unless there will be a | |
| 252 | −large number of small files on the file systems, it is also beneficial to add | |
| 253 | −the "-i 16384" option to increase the bytes per inode parameter thereby | |
| 254 | −reducing the file system metadata. Finally, on systems that will only be run | |
| 255 | −with Linux 2.2 or later kernels it is beneficial to enable sparse superblocks | |
| 256 | −with the "-s 1" option. | |
| 257 | − | |
| 258 | − | |
| 259 | − DAC960 ANNOUNCEMENTS MAILING LIST | |
| 260 | − | |
| 261 | −The DAC960 Announcements Mailing List provides a forum for informing Linux | |
| 262 | −users of new driver releases and other announcements regarding Linux support | |
| 263 | −for DAC960 PCI RAID Controllers. To join the mailing list, send a message to | |
| 264 | −"dac960-announce-request@dandelion.com" with the line "subscribe" in the | |
| 265 | −message body. | |
| 266 | − | |
| 267 | − | |
| 268 | − CONTROLLER CONFIGURATION AND STATUS MONITORING | |
| 269 | − | |
| 270 | −The DAC960 RAID controllers running firmware 4.06 or above include a Background | |
| 271 | −Initialization facility so that system downtime is minimized both for initial | |
| 272 | −installation and subsequent configuration of additional storage. The BIOS | |
| 273 | −Configuration Utility (accessible via Alt-R during the BIOS initialization | |
| 274 | −sequence) is used to quickly configure the controller, and then the logical | |
| 275 | −drives that have been created are available for immediate use even while they | |
| 276 | −are still being initialized by the controller. The primary need for online | |
| 277 | −configuration and status monitoring is then to avoid system downtime when disk | |
| 278 | −drives fail and must be replaced. Mylex's online monitoring and configuration | |
| 279 | −utilities are being ported to Linux and will become available at some point in | |
| 280 | −the future. Note that with a SAF-TE (SCSI Accessed Fault-Tolerant Enclosure) | |
| 281 | −enclosure, the controller is able to rebuild failed drives automatically as | |
| 282 | −soon as a drive replacement is made available. | |
| 283 | − | |
| 284 | −The primary interfaces for controller configuration and status monitoring are | |
| 285 | −special files created in the /proc/rd/... hierarchy along with the normal | |
| 286 | −system console logging mechanism. Whenever the system is operating, the DAC960 | |
| 287 | −driver queries each controller for status information every 10 seconds, and | |
| 288 | −checks for additional conditions every 60 seconds. The initial status of each | |
| 289 | −controller is always available for controller N in /proc/rd/cN/initial_status, | |
| 290 | −and the current status as of the last status monitoring query is available in | |
| 291 | −/proc/rd/cN/current_status. In addition, status changes are also logged by the | |
| 292 | −driver to the system console and will appear in the log files maintained by | |
| 293 | −syslog. The progress of asynchronous rebuild or consistency check operations | |
| 294 | −is also available in /proc/rd/cN/current_status, and progress messages are | |
| 295 | −logged to the system console at most every 60 seconds. | |
| 296 | − | |
| 297 | −Starting with the 2.2.3/2.0.3 versions of the driver, the status information | |
| 298 | −available in /proc/rd/cN/initial_status and /proc/rd/cN/current_status has been | |
| 299 | −augmented to include the vendor, model, revision, and serial number (if | |
| 300 | −available) for each physical device found connected to the controller: | |
| 301 | − | |
| 302 | −***** DAC960 RAID Driver Version 2.2.3 of 19 August 1999 ***** | |
| 303 | −Copyright 1998-1999 by Leonard N. Zubkoff <lnz@dandelion.com> | |
| 304 | −Configuring Mylex DAC960PRL PCI RAID Controller | |
| 305 | − Firmware Version: 4.07-0-07, Channels: 1, Memory Size: 16MB | |
| 306 | − PCI Bus: 1, Device: 4, Function: 1, I/O Address: Unassigned | |
| 307 | − PCI Address: 0xFE300000 mapped at 0xA0800000, IRQ Channel: 21 | |
| 308 | − Controller Queue Depth: 128, Maximum Blocks per Command: 128 | |
| 309 | − Driver Queue Depth: 127, Maximum Scatter/Gather Segments: 33 | |
| 310 | − Stripe Size: 64KB, Segment Size: 8KB, BIOS Geometry: 255/63 | |
| 311 | − SAF-TE Enclosure Management Enabled | |
| 312 | − Physical Devices: | |
| 313 | − 0:0 Vendor: IBM Model: DRVS09D Revision: 0270 | |
| 314 | − Serial Number: 68016775HA | |
| 315 | − Disk Status: Online, 17928192 blocks | |
| 316 | − 0:1 Vendor: IBM Model: DRVS09D Revision: 0270 | |
| 317 | − Serial Number: 68004E53HA | |
| 318 | − Disk Status: Online, 17928192 blocks | |
| 319 | − 0:2 Vendor: IBM Model: DRVS09D Revision: 0270 | |
| 320 | − Serial Number: 13013935HA | |
| 321 | − Disk Status: Online, 17928192 blocks | |
| 322 | − 0:3 Vendor: IBM Model: DRVS09D Revision: 0270 | |
| 323 | − Serial Number: 13016897HA | |
| 324 | − Disk Status: Online, 17928192 blocks | |
| 325 | − 0:4 Vendor: IBM Model: DRVS09D Revision: 0270 | |
| 326 | − Serial Number: 68019905HA | |
| 327 | − Disk Status: Online, 17928192 blocks | |
| 328 | − 0:5 Vendor: IBM Model: DRVS09D Revision: 0270 | |
| 329 | − Serial Number: 68012753HA | |
| 330 | − Disk Status: Online, 17928192 blocks | |
| 331 | − 0:6 Vendor: ESG-SHV Model: SCA HSBP M6 Revision: 0.61 | |
| 332 | − Logical Drives: | |
| 333 | − /dev/rd/c0d0: RAID-5, Online, 89640960 blocks, Write Thru | |
| 334 | − No Rebuild or Consistency Check in Progress | |
| 335 | − | |
| 336 | −To simplify the monitoring process for custom software, the special file | |
| 337 | −/proc/rd/status returns "OK" when all DAC960 controllers in the system are | |
| 338 | −operating normally and no failures have occurred, or "ALERT" if any logical | |
| 339 | −drives are offline or critical or any non-standby physical drives are dead. | |
| 340 | − | |
| 341 | −Configuration commands for controller N are available via the special file | |
| 342 | −/proc/rd/cN/user_command. A human readable command can be written to this | |
| 343 | −special file to initiate a configuration operation, and the results of the | |
| 344 | −operation can then be read back from the special file in addition to being | |
| 345 | −logged to the system console. The shell command sequence | |
| 346 | − | |
| 347 | − echo "<configuration-command>" > /proc/rd/c0/user_command | |
| 348 | − cat /proc/rd/c0/user_command | |
| 349 | − | |
| 350 | −is typically used to execute configuration commands. The configuration | |
| 351 | −commands are: | |
| 352 | − | |
| 353 | − flush-cache | |
| 354 | − | |
| 355 | − The "flush-cache" command flushes the controller's cache. The system | |
| 356 | − automatically flushes the cache at shutdown or if the driver module is | |
| 357 | − unloaded, so this command is only needed to be certain a write back cache | |
| 358 | − is flushed to disk before the system is powered off by a command to a UPS. | |
| 359 | − Note that the flush-cache command also stops an asynchronous rebuild or | |
| 360 | − consistency check, so it should not be used except when the system is being | |
| 361 | − halted. | |
| 362 | − | |
| 363 | − kill <channel>:<target-id> | |
| 364 | − | |
| 365 | − The "kill" command marks the physical drive <channel>:<target-id> as DEAD. | |
| 366 | − This command is provided primarily for testing, and should not be used | |
| 367 | − during normal system operation. | |
| 368 | − | |
| 369 | − make-online <channel>:<target-id> | |
| 370 | − | |
| 371 | − The "make-online" command changes the physical drive <channel>:<target-id> | |
| 372 | − from status DEAD to status ONLINE. In cases where multiple physical drives | |
| 373 | − have been killed simultaneously, this command may be used to bring all but | |
| 374 | − one of them back online, after which a rebuild to the final drive is | |
| 375 | − necessary. | |
| 376 | − | |
| 377 | − Warning: make-online should only be used on a dead physical drive that is | |
| 378 | − an active part of a drive group, never on a standby drive. The command | |
| 379 | − should never be used on a dead drive that is part of a critical logical | |
| 380 | − drive; rebuild should be used if only a single drive is dead. | |
| 381 | − | |
| 382 | − make-standby <channel>:<target-id> | |
| 383 | − | |
| 384 | − The "make-standby" command changes physical drive <channel>:<target-id> | |
| 385 | − from status DEAD to status STANDBY. It should only be used in cases where | |
| 386 | − a dead drive was replaced after an automatic rebuild was performed onto a | |
| 387 | − standby drive. It cannot be used to add a standby drive to the controller | |
| 388 | − configuration if one was not created initially; the BIOS Configuration | |
| 389 | − Utility must be used for that currently. | |
| 390 | − | |
| 391 | − rebuild <channel>:<target-id> | |
| 392 | − | |
| 393 | − The "rebuild" command initiates an asynchronous rebuild onto physical drive | |
| 394 | − <channel>:<target-id>. It should only be used when a dead drive has been | |
| 395 | − replaced. | |
| 396 | − | |
| 397 | − check-consistency <logical-drive-number> | |
| 398 | − | |
| 399 | − The "check-consistency" command initiates an asynchronous consistency check | |
| 400 | − of <logical-drive-number> with automatic restoration. It can be used | |
| 401 | − whenever it is desired to verify the consistency of the redundancy | |
| 402 | − information. | |
| 403 | − | |
| 404 | − cancel-rebuild | |
| 405 | − cancel-consistency-check | |
| 406 | − | |
| 407 | − The "cancel-rebuild" and "cancel-consistency-check" commands cancel any | |
| 408 | − rebuild or consistency check operations previously initiated. | |
| 409 | − | |
| 410 | − | |
| 411 | − EXAMPLE I - DRIVE FAILURE WITHOUT A STANDBY DRIVE | |
| 412 | − | |
| 413 | −The following annotated logs demonstrate the controller configuration and and | |
| 414 | −online status monitoring capabilities of the Linux DAC960 Driver. The test | |
| 415 | −configuration comprises 6 1GB Quantum Atlas I disk drives on two channels of a | |
| 416 | −DAC960PJ controller. The physical drives are configured into a single drive | |
| 417 | −group without a standby drive, and the drive group has been configured into two | |
| 418 | −logical drives, one RAID-5 and one RAID-6. Note that these logs are from an | |
| 419 | −earlier version of the driver and the messages have changed somewhat with newer | |
| 420 | −releases, but the functionality remains similar. First, here is the current | |
| 421 | −status of the RAID configuration: | |
| 422 | − | |
| 423 | −gwynedd:/u/lnz# cat /proc/rd/c0/current_status | |
| 424 | −***** DAC960 RAID Driver Version 2.0.0 of 23 March 1999 ***** | |
| 425 | −Copyright 1998-1999 by Leonard N. Zubkoff <lnz@dandelion.com> | |
| 426 | −Configuring Mylex DAC960PJ PCI RAID Controller | |
| 427 | − Firmware Version: 4.06-0-08, Channels: 3, Memory Size: 8MB | |
| 428 | − PCI Bus: 0, Device: 19, Function: 1, I/O Address: Unassigned | |
| 429 | − PCI Address: 0xFD4FC000 mapped at 0x8807000, IRQ Channel: 9 | |
| 430 | − Controller Queue Depth: 128, Maximum Blocks per Command: 128 | |
| 431 | − Driver Queue Depth: 127, Maximum Scatter/Gather Segments: 33 | |
| 432 | − Stripe Size: 64KB, Segment Size: 8KB, BIOS Geometry: 255/63 | |
| 433 | − Physical Devices: | |
| 434 | − 0:1 - Disk: Online, 2201600 blocks | |
| 435 | − 0:2 - Disk: Online, 2201600 blocks | |
| 436 | − 0:3 - Disk: Online, 2201600 blocks | |
| 437 | − 1:1 - Disk: Online, 2201600 blocks | |
| 438 | − 1:2 - Disk: Online, 2201600 blocks | |
| 439 | − 1:3 - Disk: Online, 2201600 blocks | |
| 440 | − Logical Drives: | |
| 441 | − /dev/rd/c0d0: RAID-5, Online, 5498880 blocks, Write Thru | |
| 442 | − /dev/rd/c0d1: RAID-6, Online, 3305472 blocks, Write Thru | |
| 443 | − No Rebuild or Consistency Check in Progress | |
| 444 | − | |
| 445 | −gwynedd:/u/lnz# cat /proc/rd/status | |
| 446 | −OK | |
| 447 | − | |
| 448 | −The above messages indicate that everything is healthy, and /proc/rd/status | |
| 449 | −returns "OK" indicating that there are no problems with any DAC960 controller | |
| 450 | −in the system. For demonstration purposes, while I/O is active Physical Drive | |
| 451 | −1:1 is now disconnected, simulating a drive failure. The failure is noted by | |
| 452 | −the driver within 10 seconds of the controller's having detected it, and the | |
| 453 | −driver logs the following console status messages indicating that Logical | |
| 454 | −Drives 0 and 1 are now CRITICAL as a result of Physical Drive 1:1 being DEAD: | |
| 455 | − | |
| 456 | −DAC960#0: Physical Drive 1:2 Error Log: Sense Key = 6, ASC = 29, ASCQ = 02 | |
| 457 | −DAC960#0: Physical Drive 1:3 Error Log: Sense Key = 6, ASC = 29, ASCQ = 02 | |
| 458 | −DAC960#0: Physical Drive 1:1 killed because of timeout on SCSI command | |
| 459 | −DAC960#0: Physical Drive 1:1 is now DEAD | |
| 460 | −DAC960#0: Logical Drive 0 (/dev/rd/c0d0) is now CRITICAL | |
| 461 | −DAC960#0: Logical Drive 1 (/dev/rd/c0d1) is now CRITICAL | |
| 462 | − | |
| 463 | −The Sense Keys logged here are just Check Condition / Unit Attention conditions | |
| 464 | −arising from a SCSI bus reset that is forced by the controller during its error | |
| 465 | −recovery procedures. Concurrently with the above, the driver status available | |
| 466 | −from /proc/rd also reflects the drive failure. The status message in | |
| 467 | −/proc/rd/status has changed from "OK" to "ALERT": | |
| 468 | − | |
| 469 | −gwynedd:/u/lnz# cat /proc/rd/status | |
| 470 | −ALERT | |
| 471 | − | |
| 472 | −and /proc/rd/c0/current_status has been updated: | |
| 473 | − | |
| 474 | −gwynedd:/u/lnz# cat /proc/rd/c0/current_status | |
| 475 | − ... | |
| 476 | − Physical Devices: | |
| 477 | − 0:1 - Disk: Online, 2201600 blocks | |
| 478 | − 0:2 - Disk: Online, 2201600 blocks | |
| 479 | − 0:3 - Disk: Online, 2201600 blocks | |
| 480 | − 1:1 - Disk: Dead, 2201600 blocks | |
| 481 | − 1:2 - Disk: Online, 2201600 blocks | |
| 482 | − 1:3 - Disk: Online, 2201600 blocks | |
| 483 | − Logical Drives: | |
| 484 | − /dev/rd/c0d0: RAID-5, Critical, 5498880 blocks, Write Thru | |
| 485 | − /dev/rd/c0d1: RAID-6, Critical, 3305472 blocks, Write Thru | |
| 486 | − No Rebuild or Consistency Check in Progress | |
| 487 | − | |
| 488 | −Since there are no standby drives configured, the system can continue to access | |
| 489 | −the logical drives in a performance degraded mode until the failed drive is | |
| 490 | −replaced and a rebuild operation completed to restore the redundancy of the | |
| 491 | −logical drives. Once Physical Drive 1:1 is replaced with a properly | |
| 492 | −functioning drive, or if the physical drive was killed without having failed | |
| 493 | −(e.g., due to electrical problems on the SCSI bus), the user can instruct the | |
| 494 | −controller to initiate a rebuild operation onto the newly replaced drive: | |
| 495 | − | |
| 496 | −gwynedd:/u/lnz# echo "rebuild 1:1" > /proc/rd/c0/user_command | |
| 497 | −gwynedd:/u/lnz# cat /proc/rd/c0/user_command | |
| 498 | −Rebuild of Physical Drive 1:1 Initiated | |
| 499 | − | |
| 500 | −The echo command instructs the controller to initiate an asynchronous rebuild | |
| 501 | −operation onto Physical Drive 1:1, and the status message that results from the | |
| 502 | −operation is then available for reading from /proc/rd/c0/user_command, as well | |
| 503 | −as being logged to the console by the driver. | |
| 504 | − | |
| 505 | −Within 10 seconds of this command the driver logs the initiation of the | |
| 506 | −asynchronous rebuild operation: | |
| 507 | − | |
| 508 | −DAC960#0: Rebuild of Physical Drive 1:1 Initiated | |
| 509 | −DAC960#0: Physical Drive 1:1 Error Log: Sense Key = 6, ASC = 29, ASCQ = 01 | |
| 510 | −DAC960#0: Physical Drive 1:1 is now WRITE-ONLY | |
| 511 | −DAC960#0: Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 1% completed | |
| 512 | − | |
| 513 | −and /proc/rd/c0/current_status is updated: | |
| 514 | − | |
| 515 | −gwynedd:/u/lnz# cat /proc/rd/c0/current_status | |
| 516 | − ... | |
| 517 | − Physical Devices: | |
| 518 | − 0:1 - Disk: Online, 2201600 blocks | |
| 519 | − 0:2 - Disk: Online, 2201600 blocks | |
| 520 | − 0:3 - Disk: Online, 2201600 blocks | |
| 521 | − 1:1 - Disk: Write-Only, 2201600 blocks | |
| 522 | − 1:2 - Disk: Online, 2201600 blocks | |
| 523 | − 1:3 - Disk: Online, 2201600 blocks | |
| 524 | − Logical Drives: | |
| 525 | − /dev/rd/c0d0: RAID-5, Critical, 5498880 blocks, Write Thru | |
| 526 | − /dev/rd/c0d1: RAID-6, Critical, 3305472 blocks, Write Thru | |
| 527 | − Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 6% completed | |
| 528 | − | |
| 529 | −As the rebuild progresses, the current status in /proc/rd/c0/current_status is | |
| 530 | −updated every 10 seconds: | |
| 531 | − | |
| 532 | −gwynedd:/u/lnz# cat /proc/rd/c0/current_status | |
| 533 | − ... | |
| 534 | − Physical Devices: | |
| 535 | − 0:1 - Disk: Online, 2201600 blocks | |
| 536 | − 0:2 - Disk: Online, 2201600 blocks | |
| 537 | − 0:3 - Disk: Online, 2201600 blocks | |
| 538 | − 1:1 - Disk: Write-Only, 2201600 blocks | |
| 539 | − 1:2 - Disk: Online, 2201600 blocks | |
| 540 | − 1:3 - Disk: Online, 2201600 blocks | |
| 541 | − Logical Drives: | |
| 542 | − /dev/rd/c0d0: RAID-5, Critical, 5498880 blocks, Write Thru | |
| 543 | − /dev/rd/c0d1: RAID-6, Critical, 3305472 blocks, Write Thru | |
| 544 | − Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 15% completed | |
| 545 | − | |
| 546 | −and every minute a progress message is logged to the console by the driver: | |
| 547 | − | |
| 548 | −DAC960#0: Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 32% completed | |
| 549 | −DAC960#0: Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 63% completed | |
| 550 | −DAC960#0: Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 94% completed | |
| 551 | −DAC960#0: Rebuild in Progress: Logical Drive 1 (/dev/rd/c0d1) 94% completed | |
| 552 | − | |
| 553 | −Finally, the rebuild completes successfully. The driver logs the status of the | |
| 554 | −logical and physical drives and the rebuild completion: | |
| 555 | − | |
| 556 | −DAC960#0: Rebuild Completed Successfully | |
| 557 | −DAC960#0: Physical Drive 1:1 is now ONLINE | |
| 558 | −DAC960#0: Logical Drive 0 (/dev/rd/c0d0) is now ONLINE | |
| 559 | −DAC960#0: Logical Drive 1 (/dev/rd/c0d1) is now ONLINE | |
| 560 | − | |
| 561 | −/proc/rd/c0/current_status is updated: | |
| 562 | − | |
| 563 | −gwynedd:/u/lnz# cat /proc/rd/c0/current_status | |
| 564 | − ... | |
| 565 | − Physical Devices: | |
| 566 | − 0:1 - Disk: Online, 2201600 blocks | |
| 567 | − 0:2 - Disk: Online, 2201600 blocks | |
| 568 | − 0:3 - Disk: Online, 2201600 blocks | |
| 569 | − 1:1 - Disk: Online, 2201600 blocks | |
| 570 | − 1:2 - Disk: Online, 2201600 blocks | |
| 571 | − 1:3 - Disk: Online, 2201600 blocks | |
| 572 | − Logical Drives: | |
| 573 | − /dev/rd/c0d0: RAID-5, Online, 5498880 blocks, Write Thru | |
| 574 | − /dev/rd/c0d1: RAID-6, Online, 3305472 blocks, Write Thru | |
| 575 | − Rebuild Completed Successfully | |
| 576 | − | |
| 577 | −and /proc/rd/status indicates that everything is healthy once again: | |
| 578 | − | |
| 579 | −gwynedd:/u/lnz# cat /proc/rd/status | |
| 580 | −OK | |
| 581 | − | |
| 582 | − | |
| 583 | − EXAMPLE II - DRIVE FAILURE WITH A STANDBY DRIVE | |
| 584 | − | |
| 585 | −The following annotated logs demonstrate the controller configuration and and | |
| 586 | −online status monitoring capabilities of the Linux DAC960 Driver. The test | |
| 587 | −configuration comprises 6 1GB Quantum Atlas I disk drives on two channels of a | |
| 588 | −DAC960PJ controller. The physical drives are configured into a single drive | |
| 589 | −group with a standby drive, and the drive group has been configured into two | |
| 590 | −logical drives, one RAID-5 and one RAID-6. Note that these logs are from an | |
| 591 | −earlier version of the driver and the messages have changed somewhat with newer | |
| 592 | −releases, but the functionality remains similar. First, here is the current | |
| 593 | −status of the RAID configuration: | |
| 594 | − | |
| 595 | −gwynedd:/u/lnz# cat /proc/rd/c0/current_status | |
| 596 | −***** DAC960 RAID Driver Version 2.0.0 of 23 March 1999 ***** | |
| 597 | −Copyright 1998-1999 by Leonard N. Zubkoff <lnz@dandelion.com> | |
| 598 | −Configuring Mylex DAC960PJ PCI RAID Controller | |
| 599 | − Firmware Version: 4.06-0-08, Channels: 3, Memory Size: 8MB | |
| 600 | − PCI Bus: 0, Device: 19, Function: 1, I/O Address: Unassigned | |
| 601 | − PCI Address: 0xFD4FC000 mapped at 0x8807000, IRQ Channel: 9 | |
| 602 | − Controller Queue Depth: 128, Maximum Blocks per Command: 128 | |
| 603 | − Driver Queue Depth: 127, Maximum Scatter/Gather Segments: 33 | |
| 604 | − Stripe Size: 64KB, Segment Size: 8KB, BIOS Geometry: 255/63 | |
| 605 | − Physical Devices: | |
| 606 | − 0:1 - Disk: Online, 2201600 blocks | |
| 607 | − 0:2 - Disk: Online, 2201600 blocks | |
| 608 | − 0:3 - Disk: Online, 2201600 blocks | |
| 609 | − 1:1 - Disk: Online, 2201600 blocks | |
| 610 | − 1:2 - Disk: Online, 2201600 blocks | |
| 611 | − 1:3 - Disk: Standby, 2201600 blocks | |
| 612 | − Logical Drives: | |
| 613 | − /dev/rd/c0d0: RAID-5, Online, 4399104 blocks, Write Thru | |
| 614 | − /dev/rd/c0d1: RAID-6, Online, 2754560 blocks, Write Thru | |
| 615 | − No Rebuild or Consistency Check in Progress | |
| 616 | − | |
| 617 | −gwynedd:/u/lnz# cat /proc/rd/status | |
| 618 | −OK | |
| 619 | − | |
| 620 | −The above messages indicate that everything is healthy, and /proc/rd/status | |
| 621 | −returns "OK" indicating that there are no problems with any DAC960 controller | |
| 622 | −in the system. For demonstration purposes, while I/O is active Physical Drive | |
| 623 | −1:2 is now disconnected, simulating a drive failure. The failure is noted by | |
| 624 | −the driver within 10 seconds of the controller's having detected it, and the | |
| 625 | −driver logs the following console status messages: | |
| 626 | − | |
| 627 | −DAC960#0: Physical Drive 1:1 Error Log: Sense Key = 6, ASC = 29, ASCQ = 02 | |
| 628 | −DAC960#0: Physical Drive 1:3 Error Log: Sense Key = 6, ASC = 29, ASCQ = 02 | |
| 629 | −DAC960#0: Physical Drive 1:2 killed because of timeout on SCSI command | |
| 630 | −DAC960#0: Physical Drive 1:2 is now DEAD | |
| 631 | −DAC960#0: Physical Drive 1:2 killed because it was removed | |
| 632 | −DAC960#0: Logical Drive 0 (/dev/rd/c0d0) is now CRITICAL | |
| 633 | −DAC960#0: Logical Drive 1 (/dev/rd/c0d1) is now CRITICAL | |
| 634 | − | |
| 635 | −Since a standby drive is configured, the controller automatically begins | |
| 636 | −rebuilding onto the standby drive: | |
| 637 | − | |
| 638 | −DAC960#0: Physical Drive 1:3 is now WRITE-ONLY | |
| 639 | −DAC960#0: Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 4% completed | |
| 640 | − | |
| 641 | −Concurrently with the above, the driver status available from /proc/rd also | |
| 642 | −reflects the drive failure and automatic rebuild. The status message in | |
| 643 | −/proc/rd/status has changed from "OK" to "ALERT": | |
| 644 | − | |
| 645 | −gwynedd:/u/lnz# cat /proc/rd/status | |
| 646 | −ALERT | |
| 647 | − | |
| 648 | −and /proc/rd/c0/current_status has been updated: | |
| 649 | − | |
| 650 | −gwynedd:/u/lnz# cat /proc/rd/c0/current_status | |
| 651 | − ... | |
| 652 | − Physical Devices: | |
| 653 | − 0:1 - Disk: Online, 2201600 blocks | |
| 654 | − 0:2 - Disk: Online, 2201600 blocks | |
| 655 | − 0:3 - Disk: Online, 2201600 blocks | |
| 656 | − 1:1 - Disk: Online, 2201600 blocks | |
| 657 | − 1:2 - Disk: Dead, 2201600 blocks | |
| 658 | − 1:3 - Disk: Write-Only, 2201600 blocks | |
| 659 | − Logical Drives: | |
| 660 | − /dev/rd/c0d0: RAID-5, Critical, 4399104 blocks, Write Thru | |
| 661 | − /dev/rd/c0d1: RAID-6, Critical, 2754560 blocks, Write Thru | |
| 662 | − Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 4% completed | |
| 663 | − | |
| 664 | −As the rebuild progresses, the current status in /proc/rd/c0/current_status is | |
| 665 | −updated every 10 seconds: | |
| 666 | − | |
| 667 | −gwynedd:/u/lnz# cat /proc/rd/c0/current_status | |
| 668 | − ... | |
| 669 | − Physical Devices: | |
| 670 | − 0:1 - Disk: Online, 2201600 blocks | |
| 671 | − 0:2 - Disk: Online, 2201600 blocks | |
| 672 | − 0:3 - Disk: Online, 2201600 blocks | |
| 673 | − 1:1 - Disk: Online, 2201600 blocks | |
| 674 | − 1:2 - Disk: Dead, 2201600 blocks | |
| 675 | − 1:3 - Disk: Write-Only, 2201600 blocks | |
| 676 | − Logical Drives: | |
| 677 | − /dev/rd/c0d0: RAID-5, Critical, 4399104 blocks, Write Thru | |
| 678 | − /dev/rd/c0d1: RAID-6, Critical, 2754560 blocks, Write Thru | |
| 679 | − Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 40% completed | |
| 680 | − | |
| 681 | −and every minute a progress message is logged on the console by the driver: | |
| 682 | − | |
| 683 | −DAC960#0: Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 40% completed | |
| 684 | −DAC960#0: Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 76% completed | |
| 685 | −DAC960#0: Rebuild in Progress: Logical Drive 1 (/dev/rd/c0d1) 66% completed | |
| 686 | −DAC960#0: Rebuild in Progress: Logical Drive 1 (/dev/rd/c0d1) 84% completed | |
| 687 | − | |
| 688 | −Finally, the rebuild completes successfully. The driver logs the status of the | |
| 689 | −logical and physical drives and the rebuild completion: | |
| 690 | − | |
| 691 | −DAC960#0: Rebuild Completed Successfully | |
| 692 | −DAC960#0: Physical Drive 1:3 is now ONLINE | |
| 693 | −DAC960#0: Logical Drive 0 (/dev/rd/c0d0) is now ONLINE | |
| 694 | −DAC960#0: Logical Drive 1 (/dev/rd/c0d1) is now ONLINE | |
| 695 | − | |
| 696 | −/proc/rd/c0/current_status is updated: | |
| 697 | − | |
| 698 | −***** DAC960 RAID Driver Version 2.0.0 of 23 March 1999 ***** | |
| 699 | −Copyright 1998-1999 by Leonard N. Zubkoff <lnz@dandelion.com> | |
| 700 | −Configuring Mylex DAC960PJ PCI RAID Controller | |
| 701 | − Firmware Version: 4.06-0-08, Channels: 3, Memory Size: 8MB | |
| 702 | − PCI Bus: 0, Device: 19, Function: 1, I/O Address: Unassigned | |
| 703 | − PCI Address: 0xFD4FC000 mapped at 0x8807000, IRQ Channel: 9 | |
| 704 | − Controller Queue Depth: 128, Maximum Blocks per Command: 128 | |
| 705 | − Driver Queue Depth: 127, Maximum Scatter/Gather Segments: 33 | |
| 706 | − Stripe Size: 64KB, Segment Size: 8KB, BIOS Geometry: 255/63 | |
| 707 | − Physical Devices: | |
| 708 | − 0:1 - Disk: Online, 2201600 blocks | |
| 709 | − 0:2 - Disk: Online, 2201600 blocks | |
| 710 | − 0:3 - Disk: Online, 2201600 blocks | |
| 711 | − 1:1 - Disk: Online, 2201600 blocks | |
| 712 | − 1:2 - Disk: Dead, 2201600 blocks | |
| 713 | − 1:3 - Disk: Online, 2201600 blocks | |
| 714 | − Logical Drives: | |
| 715 | − /dev/rd/c0d0: RAID-5, Online, 4399104 blocks, Write Thru | |
| 716 | − /dev/rd/c0d1: RAID-6, Online, 2754560 blocks, Write Thru | |
| 717 | − Rebuild Completed Successfully | |
| 718 | − | |
| 719 | −and /proc/rd/status indicates that everything is healthy once again: | |
| 720 | − | |
| 721 | −gwynedd:/u/lnz# cat /proc/rd/status | |
| 722 | −OK | |
| 723 | − | |
| 724 | −Note that the absence of a viable standby drive does not create an "ALERT" | |
| 725 | −status. Once dead Physical Drive 1:2 has been replaced, the controller must be | |
| 726 | −told that this has occurred and that the newly replaced drive should become the | |
| 727 | −new standby drive: | |
| 728 | − | |
| 729 | −gwynedd:/u/lnz# echo "make-standby 1:2" > /proc/rd/c0/user_command | |
| 730 | −gwynedd:/u/lnz# cat /proc/rd/c0/user_command | |
| 731 | −Make Standby of Physical Drive 1:2 Succeeded | |
| 732 | − | |
| 733 | −The echo command instructs the controller to make Physical Drive 1:2 into a | |
| 734 | −standby drive, and the status message that results from the operation is then | |
| 735 | −available for reading from /proc/rd/c0/user_command, as well as being logged to | |
| 736 | −the console by the driver. Within 60 seconds of this command the driver logs: | |
| 737 | − | |
| 738 | −DAC960#0: Physical Drive 1:2 Error Log: Sense Key = 6, ASC = 29, ASCQ = 01 | |
| 739 | −DAC960#0: Physical Drive 1:2 is now STANDBY | |
| 740 | −DAC960#0: Make Standby of Physical Drive 1:2 Succeeded | |
| 741 | − | |
| 742 | −and /proc/rd/c0/current_status is updated: | |
| 743 | − | |
| 744 | −gwynedd:/u/lnz# cat /proc/rd/c0/current_status | |
| 745 | − ... | |
| 746 | − Physical Devices: | |
| 747 | − 0:1 - Disk: Online, 2201600 blocks | |
| 748 | − 0:2 - Disk: Online, 2201600 blocks | |
| 749 | − 0:3 - Disk: Online, 2201600 blocks | |
| 750 | − 1:1 - Disk: Online, 2201600 blocks | |
| 751 | − 1:2 - Disk: Standby, 2201600 blocks | |
| 752 | − 1:3 - Disk: Online, 2201600 blocks | |
| 753 | − Logical Drives: | |
| 754 | − /dev/rd/c0d0: RAID-5, Online, 4399104 blocks, Write Thru | |
| 755 | − /dev/rd/c0d1: RAID-6, Online, 2754560 blocks, Write Thru | |
| 756 | − Rebuild Completed Successfully | |
| @@ -190,7 +190,7 @@ whitespace: · 189 unmodified lines | ||
| 190 | 190 | notify_free Depending on device usage scenario it may account |
| 191 | 191 | a) the number of pages freed because of swap slot free |
| 192 | 192 | notifications or b) the number of pages freed because of |
| 193 | − REQ_DISCARD requests sent by bio. The former ones are | |
| 193 | + REQ_OP_DISCARD requests sent by bio. The former ones are | |
| 194 | 194 | sent to a swap block device when a swap slot is freed, |
| 195 | 195 | which implies that this disk is being used as a swap disk. |
| 196 | 196 | The latter ones are sent by filesystem mounted with |
| @@ -1,11 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - this file (info on CD-ROMs and Linux) | |
| 3 | −Makefile | |
| 4 | − - only used to generate TeX output from the documentation. | |
| 5 | −cdrom-standard.tex | |
| 6 | − - LaTeX document on standardizing the CD-ROM programming interface. | |
| 7 | −ide-cd | |
| 8 | − - info on setting up and using ATAPI (aka IDE) CD-ROMs. | |
| 9 | −packet-writing.txt | |
| 10 | − - Info on the CDRW packet writing module | |
| 11 | − | |
| @@ -1,26 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - this file | |
| 3 | −blkio-controller.txt | |
| 4 | − - Description for Block IO Controller, implementation and usage details. | |
| 5 | −cgroups.txt | |
| 6 | − - Control Groups definition, implementation details, examples and API. | |
| 7 | −cpuacct.txt | |
| 8 | − - CPU Accounting Controller; account CPU usage for groups of tasks. | |
| 9 | −cpusets.txt | |
| 10 | − - documents the cpusets feature; assign CPUs and Mem to a set of tasks. | |
| 11 | −admin-guide/devices.rst | |
| 12 | − - Device Whitelist Controller; description, interface and security. | |
| 13 | −freezer-subsystem.txt | |
| 14 | − - checkpointing; rationale to not use signals, interface. | |
| 15 | −hugetlb.txt | |
| 16 | − - HugeTLB Controller implementation and usage details. | |
| 17 | −memcg_test.txt | |
| 18 | − - Memory Resource Controller; implementation details. | |
| 19 | −memory.txt | |
| 20 | − - Memory Resource Controller; design, accounting, interface, testing. | |
| 21 | −net_cls.txt | |
| 22 | − - Network classifier cgroups details and usages. | |
| 23 | −net_prio.txt | |
| 24 | − - Network priority cgroups details and usages. | |
| 25 | −pids.txt | |
| 26 | − - Process number cgroups details and usages. | |
| @@ -27,7 +27,7 @@ cgroup. · 26 unmodified lines | ||
| 27 | 27 | Currently user space applications can easily take away all the rdma verb |
| 28 | 28 | specific resources such as AH, CQ, QP, MR etc. Due to which other applications |
| 29 | 29 | in other cgroup or kernel space ULPs may not even get chance to allocate any |
| 30 | −rdma resources. This can leads to service unavailability. | |
| 30 | +rdma resources. This can lead to service unavailability. | |
| 31 | 31 | |
| 32 | 32 | Therefore RDMA controller is needed through which resource consumption |
| 33 | 33 | of processes can be limited. Through this controller different rdma |
| @@ -259,7 +259,7 @@ latex_elements = { · 258 unmodified lines | ||
| 259 | 259 | 'papersize': 'a4paper', |
| 260 | 260 | |
| 261 | 261 | # The font size ('10pt', '11pt' or '12pt'). |
| 262 | −'pointsize': '8pt', | |
| 262 | +'pointsize': '11pt', | |
| 263 | 263 | |
| 264 | 264 | # Latex figure (float) alignment |
| 265 | 265 | #'figure_align': 'htbp', |
| @@ -272,8 +272,8 @@ latex_elements = { · 6 unmodified lines | ||
| 272 | 272 | 'preamble': ''' |
| 273 | 273 | % Use some font with UTF-8 support with XeLaTeX |
| 274 | 274 | \\usepackage{fontspec} |
| 275 | − \\setsansfont{DejaVu Serif} | |
| 276 | − \\setromanfont{DejaVu Sans} | |
| 275 | + \\setsansfont{DejaVu Sans} | |
| 276 | + \\setromanfont{DejaVu Serif} | |
| 277 | 277 | \\setmonofont{DejaVu Sans Mono} |
| 278 | 278 | |
| 279 | 279 | ''' |
| @@ -383,6 +383,10 @@ latex_documents = [ · 103 unmodified lines | ||
| 383 | 383 | 'The kernel development community', 'manual'), |
| 384 | 384 | ('filesystems/index', 'filesystems.tex', 'Linux Filesystems API', |
| 385 | 385 | 'The kernel development community', 'manual'), |
| 386 | + ('admin-guide/ext4', 'ext4-admin-guide.tex', 'ext4 Administration Guide', | |
| 387 | + 'ext4 Community', 'manual'), | |
| 388 | + ('filesystems/ext4/index', 'ext4-data-structures.tex', | |
| 389 | + 'ext4 Data Structures and Algorithms', 'ext4 Community', 'manual'), | |
| 386 | 390 | ('gpu/index', 'gpu.tex', 'Linux GPU Driver Developer\'s Guide', |
| 387 | 391 | 'The kernel development community', 'manual'), |
| 388 | 392 | ('input/index', 'linux-input.tex', 'The Linux input driver subsystem', |
| @@ -5,54 +5,23 @@ Boot time memory management · 4 unmodified lines | ||
| 5 | 5 | Early system initialization cannot use "normal" memory management |
| 6 | 6 | simply because it is not set up yet. But there is still need to |
| 7 | 7 | allocate memory for various data structures, for instance for the |
| 8 | −physical page allocator. To address this, a specialized allocator | |
| 9 | −called the :ref:`Boot Memory Allocator <bootmem>`, or bootmem, was | |
| 10 | −introduced. Several years later PowerPC developers added a "Logical | |
| 11 | −Memory Blocks" allocator, which was later adopted by other | |
| 12 | −architectures and renamed to :ref:`memblock <memblock>`. There is also | |
| 13 | −a compatibility layer called `nobootmem` that translates bootmem | |
| 14 | −allocation interfaces to memblock calls. | |
| 8 | +physical page allocator. | |
| 15 | 9 | |
| 16 | −The selection of the early allocator is done using | |
| 17 | −``CONFIG_NO_BOOTMEM`` and ``CONFIG_HAVE_MEMBLOCK`` kernel | |
| 18 | −configuration options. These options are enabled or disabled | |
| 19 | −statically by the architectures' Kconfig files. | |
| 20 | − | |
| 21 | −* Architectures that rely only on bootmem select | |
| 22 | − ``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=n``. | |
| 23 | −* The users of memblock with the nobootmem compatibility layer set | |
| 24 | − ``CONFIG_NO_BOOTMEM=y && CONFIG_HAVE_MEMBLOCK=y``. | |
| 25 | −* And for those that use both memblock and bootmem the configuration | |
| 26 | − includes ``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=y``. | |
| 27 | − | |
| 28 | −Whichever allocator is used, it is the responsibility of the | |
| 29 | −architecture specific initialization to set it up in | |
| 30 | −:c:func:`setup_arch` and tear it down in :c:func:`mem_init` functions. | |
| 10 | +A specialized allocator called ``memblock`` performs the | |
| 11 | +boot time memory management. The architecture specific initialization | |
| 12 | +must set it up in :c:func:`setup_arch` and tear it down in | |
| 13 | +:c:func:`mem_init` functions. | |
| 31 | 14 | |
| 32 | 15 | Once the early memory management is available it offers a variety of |
| 33 | 16 | functions and macros for memory allocations. The allocation request |
| 34 | 17 | may be directed to the first (and probably the only) node or to a |
| 35 | 18 | particular node in a NUMA system. There are API variants that panic |
| 36 | −when an allocation fails and those that don't. And more recent and | |
| 37 | −advanced memblock even allows controlling its own behaviour. | |
| 38 | − | |
| 39 | −.. _bootmem: | |
| 40 | − | |
| 41 | −Bootmem | |
| 42 | −======= | |
| 43 | − | |
| 44 | −(mostly stolen from Mel Gorman's "Understanding the Linux Virtual | |
| 45 | −Memory Manager" `book`_) | |
| 46 | − | |
| 47 | −.. _book: https://www.kernel.org/doc/gorman/ | |
| 48 | − | |
| 49 | −.. kernel-doc:: mm/bootmem.c | |
| 50 | − :doc: bootmem overview | |
| 19 | +when an allocation fails and those that don't. | |
| 51 | 20 | |
| 52 | −.. _memblock: | |
| 21 | +Memblock also offers a variety of APIs that control its own behaviour. | |
| 53 | 22 | |
| 54 | −Memblock | |
| 55 | −======== | |
| 23 | +Memblock Overview | |
| 24 | +================= | |
| 56 | 25 | |
| 57 | 26 | .. kernel-doc:: mm/memblock.c |
| 58 | 27 | :doc: memblock overview |
| @@ -61,26 +30,6 @@ Memblock · 2 unmodified lines | ||
| 61 | 30 | Functions and structures |
| 62 | 31 | ======================== |
| 63 | 32 | |
| 64 | −Common API | |
| 65 | −---------- | |
| 66 | − | |
| 67 | −The functions that are described in this section are available | |
| 68 | −regardless of what early memory manager is enabled. | |
| 69 | − | |
| 70 | −.. kernel-doc:: mm/nobootmem.c | |
| 71 | − | |
| 72 | −Bootmem specific API | |
| 73 | −-------------------- | |
| 74 | − | |
| 75 | −These interfaces available only with bootmem, i.e when ``CONFIG_NO_BOOTMEM=n`` | |
| 76 | − | |
| 77 | −.. kernel-doc:: include/linux/bootmem.h | |
| 78 | −.. kernel-doc:: mm/bootmem.c | |
| 79 | − :nodocs: | |
| 80 | − | |
| 81 | −Memblock specific API | |
| 82 | −--------------------- | |
| 83 | − | |
| 84 | 33 | Here is the description of memblock data structures, functions and |
| 85 | 34 | macros. Some of them are actually internal, but since they are |
| 86 | 35 | documented it would be silly to omit them. Besides, reading the |
| @@ -89,4 +38,4 @@ really happens under the hood. · 2 unmodified lines | ||
| 89 | 38 | |
| 90 | 39 | .. kernel-doc:: include/linux/memblock.h |
| 91 | 40 | .. kernel-doc:: mm/memblock.c |
| 92 | − :nodocs: | |
| 41 | + :functions: | |
| @@ -1,3 +1,5 @@ | ||
| 1 | +.. _gfp_mask_from_fs_io: | |
| 2 | + | |
| 1 | 3 | ================================= |
| 2 | 4 | GFP masks used from FS/IO context |
| 3 | 5 | ================================= |
| @@ -1,4 +1,4 @@ | ||
| 1 | −.. SPDX-License-Identifier: CC-BY-SA-4.0 | |
| 1 | +.. SPDX-License-Identifier: GPL-2.0+ | |
| 2 | 2 | |
| 3 | 3 | ============= |
| 4 | 4 | ID Allocation |
| @@ -21,16 +21,20 @@ Core utilities · 20 unmodified lines | ||
| 21 | 21 | local_ops |
| 22 | 22 | workqueue |
| 23 | 23 | genericirq |
| 24 | + xarray | |
| 24 | 25 | flexible-arrays |
| 25 | 26 | librs |
| 26 | 27 | genalloc |
| 27 | 28 | errseq |
| 28 | 29 | printk-formats |
| 29 | 30 | circular-buffers |
| 31 | + memory-allocation | |
| 30 | 32 | mm-api |
| 31 | 33 | gfp_mask-from-fs-io |
| 32 | 34 | timekeeping |
| 33 | 35 | boot-time-mm |
| 36 | + memory-hotplug | |
| 37 | + | |
| 34 | 38 | |
| 35 | 39 | Interfaces for kernel debugging |
| 36 | 40 | =============================== |
| @@ -0,0 +1,122 @@ | ||
| 1 | +======================= | |
| 2 | +Memory Allocation Guide | |
| 3 | +======================= | |
| 4 | + | |
| 5 | +Linux provides a variety of APIs for memory allocation. You can | |
| 6 | +allocate small chunks using `kmalloc` or `kmem_cache_alloc` families, | |
| 7 | +large virtually contiguous areas using `vmalloc` and its derivatives, | |
| 8 | +or you can directly request pages from the page allocator with | |
| 9 | +`alloc_pages`. It is also possible to use more specialized allocators, | |
| 10 | +for instance `cma_alloc` or `zs_malloc`. | |
| 11 | + | |
| 12 | +Most of the memory allocation APIs use GFP flags to express how that | |
| 13 | +memory should be allocated. The GFP acronym stands for "get free | |
| 14 | +pages", the underlying memory allocation function. | |
| 15 | + | |
| 16 | +Diversity of the allocation APIs combined with the numerous GFP flags | |
| 17 | +makes the question "How should I allocate memory?" not that easy to | |
| 18 | +answer, although very likely you should use | |
| 19 | + | |
| 20 | +:: | |
| 21 | + | |
| 22 | + kzalloc(<size>, GFP_KERNEL); | |
| 23 | + | |
| 24 | +Of course there are cases when other allocation APIs and different GFP | |
| 25 | +flags must be used. | |
| 26 | + | |
| 27 | +Get Free Page flags | |
| 28 | +=================== | |
| 29 | + | |
| 30 | +The GFP flags control the allocators behavior. They tell what memory | |
| 31 | +zones can be used, how hard the allocator should try to find free | |
| 32 | +memory, whether the memory can be accessed by the userspace etc. The | |
| 33 | +:ref:`Documentation/core-api/mm-api.rst <mm-api-gfp-flags>` provides | |
| 34 | +reference documentation for the GFP flags and their combinations and | |
| 35 | +here we briefly outline their recommended usage: | |
| 36 | + | |
| 37 | + * Most of the time ``GFP_KERNEL`` is what you need. Memory for the | |
| 38 | + kernel data structures, DMAable memory, inode cache, all these and | |
| 39 | + many other allocations types can use ``GFP_KERNEL``. Note, that | |
| 40 | + using ``GFP_KERNEL`` implies ``GFP_RECLAIM``, which means that | |
| 41 | + direct reclaim may be triggered under memory pressure; the calling | |
| 42 | + context must be allowed to sleep. | |
| 43 | + * If the allocation is performed from an atomic context, e.g interrupt | |
| 44 | + handler, use ``GFP_NOWAIT``. This flag prevents direct reclaim and | |
| 45 | + IO or filesystem operations. Consequently, under memory pressure | |
| 46 | + ``GFP_NOWAIT`` allocation is likely to fail. Allocations which | |
| 47 | + have a reasonable fallback should be using ``GFP_NOWARN``. | |
| 48 | + * If you think that accessing memory reserves is justified and the kernel | |
| 49 | + will be stressed unless allocation succeeds, you may use ``GFP_ATOMIC``. | |
| 50 | + * Untrusted allocations triggered from userspace should be a subject | |
| 51 | + of kmem accounting and must have ``__GFP_ACCOUNT`` bit set. There | |
| 52 | + is the handy ``GFP_KERNEL_ACCOUNT`` shortcut for ``GFP_KERNEL`` | |
| 53 | + allocations that should be accounted. | |
| 54 | + * Userspace allocations should use either of the ``GFP_USER``, | |
| 55 | + ``GFP_HIGHUSER`` or ``GFP_HIGHUSER_MOVABLE`` flags. The longer | |
| 56 | + the flag name the less restrictive it is. | |
| 57 | + | |
| 58 | + ``GFP_HIGHUSER_MOVABLE`` does not require that allocated memory | |
| 59 | + will be directly accessible by the kernel and implies that the | |
| 60 | + data is movable. | |
| 61 | + | |
| 62 | + ``GFP_HIGHUSER`` means that the allocated memory is not movable, | |
| 63 | + but it is not required to be directly accessible by the kernel. An | |
| 64 | + example may be a hardware allocation that maps data directly into | |
| 65 | + userspace but has no addressing limitations. | |
| 66 | + | |
| 67 | + ``GFP_USER`` means that the allocated memory is not movable and it | |
| 68 | + must be directly accessible by the kernel. | |
| 69 | + | |
| 70 | +You may notice that quite a few allocations in the existing code | |
| 71 | +specify ``GFP_NOIO`` or ``GFP_NOFS``. Historically, they were used to | |
| 72 | +prevent recursion deadlocks caused by direct memory reclaim calling | |
| 73 | +back into the FS or IO paths and blocking on already held | |
| 74 | +resources. Since 4.12 the preferred way to address this issue is to | |
| 75 | +use new scope APIs described in | |
| 76 | +:ref:`Documentation/core-api/gfp_mask-from-fs-io.rst <gfp_mask_from_fs_io>`. | |
| 77 | + | |
| 78 | +Other legacy GFP flags are ``GFP_DMA`` and ``GFP_DMA32``. They are | |
| 79 | +used to ensure that the allocated memory is accessible by hardware | |
| 80 | +with limited addressing capabilities. So unless you are writing a | |
| 81 | +driver for a device with such restrictions, avoid using these flags. | |
| 82 | +And even with hardware with restrictions it is preferable to use | |
| 83 | +`dma_alloc*` APIs. | |
| 84 | + | |
| 85 | +Selecting memory allocator | |
| 86 | +========================== | |
| 87 | + | |
| 88 | +The most straightforward way to allocate memory is to use a function | |
| 89 | +from the :c:func:`kmalloc` family. And, to be on the safe size it's | |
| 90 | +best to use routines that set memory to zero, like | |
| 91 | +:c:func:`kzalloc`. If you need to allocate memory for an array, there | |
| 92 | +are :c:func:`kmalloc_array` and :c:func:`kcalloc` helpers. | |
| 93 | + | |
| 94 | +The maximal size of a chunk that can be allocated with `kmalloc` is | |
| 95 | +limited. The actual limit depends on the hardware and the kernel | |
| 96 | +configuration, but it is a good practice to use `kmalloc` for objects | |
| 97 | +smaller than page size. | |
| 98 | + | |
| 99 | +For large allocations you can use :c:func:`vmalloc` and | |
| 100 | +:c:func:`vzalloc`, or directly request pages from the page | |
| 101 | +allocator. The memory allocated by `vmalloc` and related functions is | |
| 102 | +not physically contiguous. | |
| 103 | + | |
| 104 | +If you are not sure whether the allocation size is too large for | |
| 105 | +`kmalloc`, it is possible to use :c:func:`kvmalloc` and its | |
| 106 | +derivatives. It will try to allocate memory with `kmalloc` and if the | |
| 107 | +allocation fails it will be retried with `vmalloc`. There are | |
| 108 | +restrictions on which GFP flags can be used with `kvmalloc`; please | |
| 109 | +see :c:func:`kvmalloc_node` reference documentation. Note that | |
| 110 | +`kvmalloc` may return memory that is not physically contiguous. | |
| 111 | + | |
| 112 | +If you need to allocate many identical objects you can use the slab | |
| 113 | +cache allocator. The cache should be set up with | |
| 114 | +:c:func:`kmem_cache_create` before it can be used. Afterwards | |
| 115 | +:c:func:`kmem_cache_alloc` and its convenience wrappers can allocate | |
| 116 | +memory from that cache. | |
| 117 | + | |
| 118 | +When the allocated memory is no longer needed it must be freed. You | |
| 119 | +can use :c:func:`kvfree` for the memory allocated with `kmalloc`, | |
| 120 | +`vmalloc` and `kvmalloc`. The slab caches should be freed with | |
| 121 | +:c:func:`kmem_cache_free`. And don't forget to destroy the cache with | |
| 122 | +:c:func:`kmem_cache_destroy`. | |
| @@ -0,0 +1,125 @@ | ||
| 1 | +.. _memory_hotplug: | |
| 2 | + | |
| 3 | +============== | |
| 4 | +Memory hotplug | |
| 5 | +============== | |
| 6 | + | |
| 7 | +Memory hotplug event notifier | |
| 8 | +============================= | |
| 9 | + | |
| 10 | +Hotplugging events are sent to a notification queue. | |
| 11 | + | |
| 12 | +There are six types of notification defined in ``include/linux/memory.h``: | |
| 13 | + | |
| 14 | +MEM_GOING_ONLINE | |
| 15 | + Generated before new memory becomes available in order to be able to | |
| 16 | + prepare subsystems to handle memory. The page allocator is still unable | |
| 17 | + to allocate from the new memory. | |
| 18 | + | |
| 19 | +MEM_CANCEL_ONLINE | |
| 20 | + Generated if MEM_GOING_ONLINE fails. | |
| 21 | + | |
| 22 | +MEM_ONLINE | |
| 23 | + Generated when memory has successfully brought online. The callback may | |
| 24 | + allocate pages from the new memory. | |
| 25 | + | |
| 26 | +MEM_GOING_OFFLINE | |
| 27 | + Generated to begin the process of offlining memory. Allocations are no | |
| 28 | + longer possible from the memory but some of the memory to be offlined | |
| 29 | + is still in use. The callback can be used to free memory known to a | |
| 30 | + subsystem from the indicated memory block. | |
| 31 | + | |
| 32 | +MEM_CANCEL_OFFLINE | |
| 33 | + Generated if MEM_GOING_OFFLINE fails. Memory is available again from | |
| 34 | + the memory block that we attempted to offline. | |
| 35 | + | |
| 36 | +MEM_OFFLINE | |
| 37 | + Generated after offlining memory is complete. | |
| 38 | + | |
| 39 | +A callback routine can be registered by calling:: | |
| 40 | + | |
| 41 | + hotplug_memory_notifier(callback_func, priority) | |
| 42 | + | |
| 43 | +Callback functions with higher values of priority are called before callback | |
| 44 | +functions with lower values. | |
| 45 | + | |
| 46 | +A callback function must have the following prototype:: | |
| 47 | + | |
| 48 | + int callback_func( | |
| 49 | + struct notifier_block *self, unsigned long action, void *arg); | |
| 50 | + | |
| 51 | +The first argument of the callback function (self) is a pointer to the block | |
| 52 | +of the notifier chain that points to the callback function itself. | |
| 53 | +The second argument (action) is one of the event types described above. | |
| 54 | +The third argument (arg) passes a pointer of struct memory_notify:: | |
| 55 | + | |
| 56 | + struct memory_notify { | |
| 57 | + unsigned long start_pfn; | |
| 58 | + unsigned long nr_pages; | |
| 59 | + int status_change_nid_normal; | |
| 60 | + int status_change_nid_high; | |
| 61 | + int status_change_nid; | |
| 62 | + } | |
| 63 | + | |
| 64 | +- start_pfn is start_pfn of online/offline memory. | |
| 65 | +- nr_pages is # of pages of online/offline memory. | |
| 66 | +- status_change_nid_normal is set node id when N_NORMAL_MEMORY of nodemask | |
| 67 | + is (will be) set/clear, if this is -1, then nodemask status is not changed. | |
| 68 | +- status_change_nid_high is set node id when N_HIGH_MEMORY of nodemask | |
| 69 | + is (will be) set/clear, if this is -1, then nodemask status is not changed. | |
| 70 | +- status_change_nid is set node id when N_MEMORY of nodemask is (will be) | |
| 71 | + set/clear. It means a new(memoryless) node gets new memory by online and a | |
| 72 | + node loses all memory. If this is -1, then nodemask status is not changed. | |
| 73 | + | |
| 74 | + If status_changed_nid* >= 0, callback should create/discard structures for the | |
| 75 | + node if necessary. | |
| 76 | + | |
| 77 | +The callback routine shall return one of the values | |
| 78 | +NOTIFY_DONE, NOTIFY_OK, NOTIFY_BAD, NOTIFY_STOP | |
| 79 | +defined in ``include/linux/notifier.h`` | |
| 80 | + | |
| 81 | +NOTIFY_DONE and NOTIFY_OK have no effect on the further processing. | |
| 82 | + | |
| 83 | +NOTIFY_BAD is used as response to the MEM_GOING_ONLINE, MEM_GOING_OFFLINE, | |
| 84 | +MEM_ONLINE, or MEM_OFFLINE action to cancel hotplugging. It stops | |
| 85 | +further processing of the notification queue. | |
| 86 | + | |
| 87 | +NOTIFY_STOP stops further processing of the notification queue. | |
| 88 | + | |
| 89 | +Locking Internals | |
| 90 | +================= | |
| 91 | + | |
| 92 | +When adding/removing memory that uses memory block devices (i.e. ordinary RAM), | |
| 93 | +the device_hotplug_lock should be held to: | |
| 94 | + | |
| 95 | +- synchronize against online/offline requests (e.g. via sysfs). This way, memory | |
| 96 | + block devices can only be accessed (.online/.state attributes) by user | |
| 97 | + space once memory has been fully added. And when removing memory, we | |
| 98 | + know nobody is in critical sections. | |
| 99 | +- synchronize against CPU hotplug and similar (e.g. relevant for ACPI and PPC) | |
| 100 | + | |
| 101 | +Especially, there is a possible lock inversion that is avoided using | |
| 102 | +device_hotplug_lock when adding memory and user space tries to online that | |
| 103 | +memory faster than expected: | |
| 104 | + | |
| 105 | +- device_online() will first take the device_lock(), followed by | |
| 106 | + mem_hotplug_lock | |
| 107 | +- add_memory_resource() will first take the mem_hotplug_lock, followed by | |
| 108 | + the device_lock() (while creating the devices, during bus_add_device()). | |
| 109 | + | |
| 110 | +As the device is visible to user space before taking the device_lock(), this | |
| 111 | +can result in a lock inversion. | |
| 112 | + | |
| 113 | +onlining/offlining of memory should be done via device_online()/ | |
| 114 | +device_offline() - to make sure it is properly synchronized to actions | |
| 115 | +via sysfs. Holding device_hotplug_lock is advised (to e.g. protect online_type) | |
| 116 | + | |
| 117 | +When adding/removing/onlining/offlining memory or adding/removing | |
| 118 | +heterogeneous/device memory, we should always hold the mem_hotplug_lock in | |
| 119 | +write mode to serialise memory hotplug (e.g. access to global/zone | |
| 120 | +variables). | |
| 121 | + | |
| 122 | +In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read | |
| 123 | +mode allows for a quite efficient get_online_mems/put_online_mems | |
| 124 | +implementation, so code accessing memory can protect from that memory | |
| 125 | +vanishing. | |
| @@ -14,6 +14,8 @@ User Space Memory Access · 13 unmodified lines | ||
| 14 | 14 | .. kernel-doc:: mm/util.c |
| 15 | 15 | :functions: get_user_pages_fast |
| 16 | 16 | |
| 17 | +.. _mm-api-gfp-flags: | |
| 18 | + | |
| 17 | 19 | Memory Allocation Controls |
| 18 | 20 | ========================== |
| 19 | 21 | |
| @@ -376,15 +376,15 @@ correctness of the format string and va_list arguments. · 375 unmodified lines | ||
| 376 | 376 | |
| 377 | 377 | Passed by reference. |
| 378 | 378 | |
| 379 | −kobjects | |
| 380 | −-------- | |
| 379 | +Device tree nodes | |
| 380 | +----------------- | |
| 381 | 381 | |
| 382 | 382 | :: |
| 383 | 383 | |
| 384 | 384 | %pOF[fnpPcCF] |
| 385 | 385 | |
| 386 | 386 | |
| 387 | −For printing kobject based structs (device nodes). Default behaviour is | |
| 387 | +For printing device tree node structures. Default behaviour is | |
| 388 | 388 | equivalent to %pOFf. |
| 389 | 389 | |
| 390 | 390 | - f - device node full_name |
| @@ -420,9 +420,8 @@ struct clk · 29 unmodified lines | ||
| 420 | 420 | %pC pll1 |
| 421 | 421 | %pCn pll1 |
| 422 | 422 | |
| 423 | −For printing struct clk structures. %pC and %pCn print the name | |
| 424 | −(Common Clock Framework) or address (legacy clock framework) of the | |
| 425 | −structure. | |
| 423 | +For printing struct clk structures. %pC and %pCn print the name of the clock | |
| 424 | +(Common Clock Framework) or a unique 32-bit ID (legacy clock framework). | |
| 426 | 425 | |
| 427 | 426 | Passed by reference. |
| 428 | 427 | |
| @@ -0,0 +1,435 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0+ | |
| 2 | + | |
| 3 | +====== | |
| 4 | +XArray | |
| 5 | +====== | |
| 6 | + | |
| 7 | +:Author: Matthew Wilcox | |
| 8 | + | |
| 9 | +Overview | |
| 10 | +======== | |
| 11 | + | |
| 12 | +The XArray is an abstract data type which behaves like a very large array | |
| 13 | +of pointers. It meets many of the same needs as a hash or a conventional | |
| 14 | +resizable array. Unlike a hash, it allows you to sensibly go to the | |
| 15 | +next or previous entry in a cache-efficient manner. In contrast to a | |
| 16 | +resizable array, there is no need to copy data or change MMU mappings in | |
| 17 | +order to grow the array. It is more memory-efficient, parallelisable | |
| 18 | +and cache friendly than a doubly-linked list. It takes advantage of | |
| 19 | +RCU to perform lookups without locking. | |
| 20 | + | |
| 21 | +The XArray implementation is efficient when the indices used are densely | |
| 22 | +clustered; hashing the object and using the hash as the index will not | |
| 23 | +perform well. The XArray is optimised for small indices, but still has | |
| 24 | +good performance with large indices. If your index can be larger than | |
| 25 | +``ULONG_MAX`` then the XArray is not the data type for you. The most | |
| 26 | +important user of the XArray is the page cache. | |
| 27 | + | |
| 28 | +Each non-``NULL`` entry in the array has three bits associated with | |
| 29 | +it called marks. Each mark may be set or cleared independently of | |
| 30 | +the others. You can iterate over entries which are marked. | |
| 31 | + | |
| 32 | +Normal pointers may be stored in the XArray directly. They must be 4-byte | |
| 33 | +aligned, which is true for any pointer returned from :c:func:`kmalloc` and | |
| 34 | +:c:func:`alloc_page`. It isn't true for arbitrary user-space pointers, | |
| 35 | +nor for function pointers. You can store pointers to statically allocated | |
| 36 | +objects, as long as those objects have an alignment of at least 4. | |
| 37 | + | |
| 38 | +You can also store integers between 0 and ``LONG_MAX`` in the XArray. | |
| 39 | +You must first convert it into an entry using :c:func:`xa_mk_value`. | |
| 40 | +When you retrieve an entry from the XArray, you can check whether it is | |
| 41 | +a value entry by calling :c:func:`xa_is_value`, and convert it back to | |
| 42 | +an integer by calling :c:func:`xa_to_value`. | |
| 43 | + | |
| 44 | +Some users want to store tagged pointers instead of using the marks | |
| 45 | +described above. They can call :c:func:`xa_tag_pointer` to create an | |
| 46 | +entry with a tag, :c:func:`xa_untag_pointer` to turn a tagged entry | |
| 47 | +back into an untagged pointer and :c:func:`xa_pointer_tag` to retrieve | |
| 48 | +the tag of an entry. Tagged pointers use the same bits that are used | |
| 49 | +to distinguish value entries from normal pointers, so each user must | |
| 50 | +decide whether they want to store value entries or tagged pointers in | |
| 51 | +any particular XArray. | |
| 52 | + | |
| 53 | +The XArray does not support storing :c:func:`IS_ERR` pointers as some | |
| 54 | +conflict with value entries or internal entries. | |
| 55 | + | |
| 56 | +An unusual feature of the XArray is the ability to create entries which | |
| 57 | +occupy a range of indices. Once stored to, looking up any index in | |
| 58 | +the range will return the same entry as looking up any other index in | |
| 59 | +the range. Setting a mark on one index will set it on all of them. | |
| 60 | +Storing to any index will store to all of them. Multi-index entries can | |
| 61 | +be explicitly split into smaller entries, or storing ``NULL`` into any | |
| 62 | +entry will cause the XArray to forget about the range. | |
| 63 | + | |
| 64 | +Normal API | |
| 65 | +========== | |
| 66 | + | |
| 67 | +Start by initialising an XArray, either with :c:func:`DEFINE_XARRAY` | |
| 68 | +for statically allocated XArrays or :c:func:`xa_init` for dynamically | |
| 69 | +allocated ones. A freshly-initialised XArray contains a ``NULL`` | |
| 70 | +pointer at every index. | |
| 71 | + | |
| 72 | +You can then set entries using :c:func:`xa_store` and get entries | |
| 73 | +using :c:func:`xa_load`. xa_store will overwrite any entry with the | |
| 74 | +new entry and return the previous entry stored at that index. You can | |
| 75 | +use :c:func:`xa_erase` instead of calling :c:func:`xa_store` with a | |
| 76 | +``NULL`` entry. There is no difference between an entry that has never | |
| 77 | +been stored to and one that has most recently had ``NULL`` stored to it. | |
| 78 | + | |
| 79 | +You can conditionally replace an entry at an index by using | |
| 80 | +:c:func:`xa_cmpxchg`. Like :c:func:`cmpxchg`, it will only succeed if | |
| 81 | +the entry at that index has the 'old' value. It also returns the entry | |
| 82 | +which was at that index; if it returns the same entry which was passed as | |
| 83 | +'old', then :c:func:`xa_cmpxchg` succeeded. | |
| 84 | + | |
| 85 | +If you want to only store a new entry to an index if the current entry | |
| 86 | +at that index is ``NULL``, you can use :c:func:`xa_insert` which | |
| 87 | +returns ``-EEXIST`` if the entry is not empty. | |
| 88 | + | |
| 89 | +You can enquire whether a mark is set on an entry by using | |
| 90 | +:c:func:`xa_get_mark`. If the entry is not ``NULL``, you can set a mark | |
| 91 | +on it by using :c:func:`xa_set_mark` and remove the mark from an entry by | |
| 92 | +calling :c:func:`xa_clear_mark`. You can ask whether any entry in the | |
| 93 | +XArray has a particular mark set by calling :c:func:`xa_marked`. | |
| 94 | + | |
| 95 | +You can copy entries out of the XArray into a plain array by calling | |
| 96 | +:c:func:`xa_extract`. Or you can iterate over the present entries in | |
| 97 | +the XArray by calling :c:func:`xa_for_each`. You may prefer to use | |
| 98 | +:c:func:`xa_find` or :c:func:`xa_find_after` to move to the next present | |
| 99 | +entry in the XArray. | |
| 100 | + | |
| 101 | +Calling :c:func:`xa_store_range` stores the same entry in a range | |
| 102 | +of indices. If you do this, some of the other operations will behave | |
| 103 | +in a slightly odd way. For example, marking the entry at one index | |
| 104 | +may result in the entry being marked at some, but not all of the other | |
| 105 | +indices. Storing into one index may result in the entry retrieved by | |
| 106 | +some, but not all of the other indices changing. | |
| 107 | + | |
| 108 | +Finally, you can remove all entries from an XArray by calling | |
| 109 | +:c:func:`xa_destroy`. If the XArray entries are pointers, you may wish | |
| 110 | +to free the entries first. You can do this by iterating over all present | |
| 111 | +entries in the XArray using the :c:func:`xa_for_each` iterator. | |
| 112 | + | |
| 113 | +ID assignment | |
| 114 | +------------- | |
| 115 | + | |
| 116 | +You can call :c:func:`xa_alloc` to store the entry at any unused index | |
| 117 | +in the XArray. If you need to modify the array from interrupt context, | |
| 118 | +you can use :c:func:`xa_alloc_bh` or :c:func:`xa_alloc_irq` to disable | |
| 119 | +interrupts while allocating the ID. Unlike :c:func:`xa_store`, allocating | |
| 120 | +a ``NULL`` pointer does not delete an entry. Instead it reserves an | |
| 121 | +entry like :c:func:`xa_reserve` and you can release it using either | |
| 122 | +:c:func:`xa_erase` or :c:func:`xa_release`. To use ID assignment, the | |
| 123 | +XArray must be defined with :c:func:`DEFINE_XARRAY_ALLOC`, or initialised | |
| 124 | +by passing ``XA_FLAGS_ALLOC`` to :c:func:`xa_init_flags`, | |
| 125 | + | |
| 126 | +Memory allocation | |
| 127 | +----------------- | |
| 128 | + | |
| 129 | +The :c:func:`xa_store`, :c:func:`xa_cmpxchg`, :c:func:`xa_alloc`, | |
| 130 | +:c:func:`xa_reserve` and :c:func:`xa_insert` functions take a gfp_t | |
| 131 | +parameter in case the XArray needs to allocate memory to store this entry. | |
| 132 | +If the entry is being deleted, no memory allocation needs to be performed, | |
| 133 | +and the GFP flags specified will be ignored. | |
| 134 | + | |
| 135 | +It is possible for no memory to be allocatable, particularly if you pass | |
| 136 | +a restrictive set of GFP flags. In that case, the functions return a | |
| 137 | +special value which can be turned into an errno using :c:func:`xa_err`. | |
| 138 | +If you don't need to know exactly which error occurred, using | |
| 139 | +:c:func:`xa_is_err` is slightly more efficient. | |
| 140 | + | |
| 141 | +Locking | |
| 142 | +------- | |
| 143 | + | |
| 144 | +When using the Normal API, you do not have to worry about locking. | |
| 145 | +The XArray uses RCU and an internal spinlock to synchronise access: | |
| 146 | + | |
| 147 | +No lock needed: | |
| 148 | + * :c:func:`xa_empty` | |
| 149 | + * :c:func:`xa_marked` | |
| 150 | + | |
| 151 | +Takes RCU read lock: | |
| 152 | + * :c:func:`xa_load` | |
| 153 | + * :c:func:`xa_for_each` | |
| 154 | + * :c:func:`xa_find` | |
| 155 | + * :c:func:`xa_find_after` | |
| 156 | + * :c:func:`xa_extract` | |
| 157 | + * :c:func:`xa_get_mark` | |
| 158 | + | |
| 159 | +Takes xa_lock internally: | |
| 160 | + * :c:func:`xa_store` | |
| 161 | + * :c:func:`xa_insert` | |
| 162 | + * :c:func:`xa_erase` | |
| 163 | + * :c:func:`xa_erase_bh` | |
| 164 | + * :c:func:`xa_erase_irq` | |
| 165 | + * :c:func:`xa_cmpxchg` | |
| 166 | + * :c:func:`xa_store_range` | |
| 167 | + * :c:func:`xa_alloc` | |
| 168 | + * :c:func:`xa_alloc_bh` | |
| 169 | + * :c:func:`xa_alloc_irq` | |
| 170 | + * :c:func:`xa_destroy` | |
| 171 | + * :c:func:`xa_set_mark` | |
| 172 | + * :c:func:`xa_clear_mark` | |
| 173 | + | |
| 174 | +Assumes xa_lock held on entry: | |
| 175 | + * :c:func:`__xa_store` | |
| 176 | + * :c:func:`__xa_insert` | |
| 177 | + * :c:func:`__xa_erase` | |
| 178 | + * :c:func:`__xa_cmpxchg` | |
| 179 | + * :c:func:`__xa_alloc` | |
| 180 | + * :c:func:`__xa_set_mark` | |
| 181 | + * :c:func:`__xa_clear_mark` | |
| 182 | + | |
| 183 | +If you want to take advantage of the lock to protect the data structures | |
| 184 | +that you are storing in the XArray, you can call :c:func:`xa_lock` | |
| 185 | +before calling :c:func:`xa_load`, then take a reference count on the | |
| 186 | +object you have found before calling :c:func:`xa_unlock`. This will | |
| 187 | +prevent stores from removing the object from the array between looking | |
| 188 | +up the object and incrementing the refcount. You can also use RCU to | |
| 189 | +avoid dereferencing freed memory, but an explanation of that is beyond | |
| 190 | +the scope of this document. | |
| 191 | + | |
| 192 | +The XArray does not disable interrupts or softirqs while modifying | |
| 193 | +the array. It is safe to read the XArray from interrupt or softirq | |
| 194 | +context as the RCU lock provides enough protection. | |
| 195 | + | |
| 196 | +If, for example, you want to store entries in the XArray in process | |
| 197 | +context and then erase them in softirq context, you can do that this way:: | |
| 198 | + | |
| 199 | + void foo_init(struct foo *foo) | |
| 200 | + { | |
| 201 | + xa_init_flags(&foo->array, XA_FLAGS_LOCK_BH); | |
| 202 | + } | |
| 203 | + | |
| 204 | + int foo_store(struct foo *foo, unsigned long index, void *entry) | |
| 205 | + { | |
| 206 | + int err; | |
| 207 | + | |
| 208 | + xa_lock_bh(&foo->array); | |
| 209 | + err = xa_err(__xa_store(&foo->array, index, entry, GFP_KERNEL)); | |
| 210 | + if (!err) | |
| 211 | + foo->count++; | |
| 212 | + xa_unlock_bh(&foo->array); | |
| 213 | + return err; | |
| 214 | + } | |
| 215 | + | |
| 216 | + /* foo_erase() is only called from softirq context */ | |
| 217 | + void foo_erase(struct foo *foo, unsigned long index) | |
| 218 | + { | |
| 219 | + xa_lock(&foo->array); | |
| 220 | + __xa_erase(&foo->array, index); | |
| 221 | + foo->count--; | |
| 222 | + xa_unlock(&foo->array); | |
| 223 | + } | |
| 224 | + | |
| 225 | +If you are going to modify the XArray from interrupt or softirq context, | |
| 226 | +you need to initialise the array using :c:func:`xa_init_flags`, passing | |
| 227 | +``XA_FLAGS_LOCK_IRQ`` or ``XA_FLAGS_LOCK_BH``. | |
| 228 | + | |
| 229 | +The above example also shows a common pattern of wanting to extend the | |
| 230 | +coverage of the xa_lock on the store side to protect some statistics | |
| 231 | +associated with the array. | |
| 232 | + | |
| 233 | +Sharing the XArray with interrupt context is also possible, either | |
| 234 | +using :c:func:`xa_lock_irqsave` in both the interrupt handler and process | |
| 235 | +context, or :c:func:`xa_lock_irq` in process context and :c:func:`xa_lock` | |
| 236 | +in the interrupt handler. Some of the more common patterns have helper | |
| 237 | +functions such as :c:func:`xa_erase_bh` and :c:func:`xa_erase_irq`. | |
| 238 | + | |
| 239 | +Sometimes you need to protect access to the XArray with a mutex because | |
| 240 | +that lock sits above another mutex in the locking hierarchy. That does | |
| 241 | +not entitle you to use functions like :c:func:`__xa_erase` without taking | |
| 242 | +the xa_lock; the xa_lock is used for lockdep validation and will be used | |
| 243 | +for other purposes in the future. | |
| 244 | + | |
| 245 | +The :c:func:`__xa_set_mark` and :c:func:`__xa_clear_mark` functions are also | |
| 246 | +available for situations where you look up an entry and want to atomically | |
| 247 | +set or clear a mark. It may be more efficient to use the advanced API | |
| 248 | +in this case, as it will save you from walking the tree twice. | |
| 249 | + | |
| 250 | +Advanced API | |
| 251 | +============ | |
| 252 | + | |
| 253 | +The advanced API offers more flexibility and better performance at the | |
| 254 | +cost of an interface which can be harder to use and has fewer safeguards. | |
| 255 | +No locking is done for you by the advanced API, and you are required | |
| 256 | +to use the xa_lock while modifying the array. You can choose whether | |
| 257 | +to use the xa_lock or the RCU lock while doing read-only operations on | |
| 258 | +the array. You can mix advanced and normal operations on the same array; | |
| 259 | +indeed the normal API is implemented in terms of the advanced API. The | |
| 260 | +advanced API is only available to modules with a GPL-compatible license. | |
| 261 | + | |
| 262 | +The advanced API is based around the xa_state. This is an opaque data | |
| 263 | +structure which you declare on the stack using the :c:func:`XA_STATE` | |
| 264 | +macro. This macro initialises the xa_state ready to start walking | |
| 265 | +around the XArray. It is used as a cursor to maintain the position | |
| 266 | +in the XArray and let you compose various operations together without | |
| 267 | +having to restart from the top every time. | |
| 268 | + | |
| 269 | +The xa_state is also used to store errors. You can call | |
| 270 | +:c:func:`xas_error` to retrieve the error. All operations check whether | |
| 271 | +the xa_state is in an error state before proceeding, so there's no need | |
| 272 | +for you to check for an error after each call; you can make multiple | |
| 273 | +calls in succession and only check at a convenient point. The only | |
| 274 | +errors currently generated by the XArray code itself are ``ENOMEM`` and | |
| 275 | +``EINVAL``, but it supports arbitrary errors in case you want to call | |
| 276 | +:c:func:`xas_set_err` yourself. | |
| 277 | + | |
| 278 | +If the xa_state is holding an ``ENOMEM`` error, calling :c:func:`xas_nomem` | |
| 279 | +will attempt to allocate more memory using the specified gfp flags and | |
| 280 | +cache it in the xa_state for the next attempt. The idea is that you take | |
| 281 | +the xa_lock, attempt the operation and drop the lock. The operation | |
| 282 | +attempts to allocate memory while holding the lock, but it is more | |
| 283 | +likely to fail. Once you have dropped the lock, :c:func:`xas_nomem` | |
| 284 | +can try harder to allocate more memory. It will return ``true`` if it | |
| 285 | +is worth retrying the operation (i.e. that there was a memory error *and* | |
| 286 | +more memory was allocated). If it has previously allocated memory, and | |
| 287 | +that memory wasn't used, and there is no error (or some error that isn't | |
| 288 | +``ENOMEM``), then it will free the memory previously allocated. | |
| 289 | + | |
| 290 | +Internal Entries | |
| 291 | +---------------- | |
| 292 | + | |
| 293 | +The XArray reserves some entries for its own purposes. These are never | |
| 294 | +exposed through the normal API, but when using the advanced API, it's | |
| 295 | +possible to see them. Usually the best way to handle them is to pass them | |
| 296 | +to :c:func:`xas_retry`, and retry the operation if it returns ``true``. | |
| 297 | + | |
| 298 | +.. flat-table:: | |
| 299 | + :widths: 1 1 6 | |
| 300 | + | |
| 301 | + * - Name | |
| 302 | + - Test | |
| 303 | + - Usage | |
| 304 | + | |
| 305 | + * - Node | |
| 306 | + - :c:func:`xa_is_node` | |
| 307 | + - An XArray node. May be visible when using a multi-index xa_state. | |
| 308 | + | |
| 309 | + * - Sibling | |
| 310 | + - :c:func:`xa_is_sibling` | |
| 311 | + - A non-canonical entry for a multi-index entry. The value indicates | |
| 312 | + which slot in this node has the canonical entry. | |
| 313 | + | |
| 314 | + * - Retry | |
| 315 | + - :c:func:`xa_is_retry` | |
| 316 | + - This entry is currently being modified by a thread which has the | |
| 317 | + xa_lock. The node containing this entry may be freed at the end | |
| 318 | + of this RCU period. You should restart the lookup from the head | |
| 319 | + of the array. | |
| 320 | + | |
| 321 | + * - Zero | |
| 322 | + - :c:func:`xa_is_zero` | |
| 323 | + - Zero entries appear as ``NULL`` through the Normal API, but occupy | |
| 324 | + an entry in the XArray which can be used to reserve the index for | |
| 325 | + future use. | |
| 326 | + | |
| 327 | +Other internal entries may be added in the future. As far as possible, they | |
| 328 | +will be handled by :c:func:`xas_retry`. | |
| 329 | + | |
| 330 | +Additional functionality | |
| 331 | +------------------------ | |
| 332 | + | |
| 333 | +The :c:func:`xas_create_range` function allocates all the necessary memory | |
| 334 | +to store every entry in a range. It will set ENOMEM in the xa_state if | |
| 335 | +it cannot allocate memory. | |
| 336 | + | |
| 337 | +You can use :c:func:`xas_init_marks` to reset the marks on an entry | |
| 338 | +to their default state. This is usually all marks clear, unless the | |
| 339 | +XArray is marked with ``XA_FLAGS_TRACK_FREE``, in which case mark 0 is set | |
| 340 | +and all other marks are clear. Replacing one entry with another using | |
| 341 | +:c:func:`xas_store` will not reset the marks on that entry; if you want | |
| 342 | +the marks reset, you should do that explicitly. | |
| 343 | + | |
| 344 | +The :c:func:`xas_load` will walk the xa_state as close to the entry | |
| 345 | +as it can. If you know the xa_state has already been walked to the | |
| 346 | +entry and need to check that the entry hasn't changed, you can use | |
| 347 | +:c:func:`xas_reload` to save a function call. | |
| 348 | + | |
| 349 | +If you need to move to a different index in the XArray, call | |
| 350 | +:c:func:`xas_set`. This resets the cursor to the top of the tree, which | |
| 351 | +will generally make the next operation walk the cursor to the desired | |
| 352 | +spot in the tree. If you want to move to the next or previous index, | |
| 353 | +call :c:func:`xas_next` or :c:func:`xas_prev`. Setting the index does | |
| 354 | +not walk the cursor around the array so does not require a lock to be | |
| 355 | +held, while moving to the next or previous index does. | |
| 356 | + | |
| 357 | +You can search for the next present entry using :c:func:`xas_find`. This | |
| 358 | +is the equivalent of both :c:func:`xa_find` and :c:func:`xa_find_after`; | |
| 359 | +if the cursor has been walked to an entry, then it will find the next | |
| 360 | +entry after the one currently referenced. If not, it will return the | |
| 361 | +entry at the index of the xa_state. Using :c:func:`xas_next_entry` to | |
| 362 | +move to the next present entry instead of :c:func:`xas_find` will save | |
| 363 | +a function call in the majority of cases at the expense of emitting more | |
| 364 | +inline code. | |
| 365 | + | |
| 366 | +The :c:func:`xas_find_marked` function is similar. If the xa_state has | |
| 367 | +not been walked, it will return the entry at the index of the xa_state, | |
| 368 | +if it is marked. Otherwise, it will return the first marked entry after | |
| 369 | +the entry referenced by the xa_state. The :c:func:`xas_next_marked` | |
| 370 | +function is the equivalent of :c:func:`xas_next_entry`. | |
| 371 | + | |
| 372 | +When iterating over a range of the XArray using :c:func:`xas_for_each` | |
| 373 | +or :c:func:`xas_for_each_marked`, it may be necessary to temporarily stop | |
| 374 | +the iteration. The :c:func:`xas_pause` function exists for this purpose. | |
| 375 | +After you have done the necessary work and wish to resume, the xa_state | |
| 376 | +is in an appropriate state to continue the iteration after the entry | |
| 377 | +you last processed. If you have interrupts disabled while iterating, | |
| 378 | +then it is good manners to pause the iteration and reenable interrupts | |
| 379 | +every ``XA_CHECK_SCHED`` entries. | |
| 380 | + | |
| 381 | +The :c:func:`xas_get_mark`, :c:func:`xas_set_mark` and | |
| 382 | +:c:func:`xas_clear_mark` functions require the xa_state cursor to have | |
| 383 | +been moved to the appropriate location in the xarray; they will do | |
| 384 | +nothing if you have called :c:func:`xas_pause` or :c:func:`xas_set` | |
| 385 | +immediately before. | |
| 386 | + | |
| 387 | +You can call :c:func:`xas_set_update` to have a callback function | |
| 388 | +called each time the XArray updates a node. This is used by the page | |
| 389 | +cache workingset code to maintain its list of nodes which contain only | |
| 390 | +shadow entries. | |
| 391 | + | |
| 392 | +Multi-Index Entries | |
| 393 | +------------------- | |
| 394 | + | |
| 395 | +The XArray has the ability to tie multiple indices together so that | |
| 396 | +operations on one index affect all indices. For example, storing into | |
| 397 | +any index will change the value of the entry retrieved from any index. | |
| 398 | +Setting or clearing a mark on any index will set or clear the mark | |
| 399 | +on every index that is tied together. The current implementation | |
| 400 | +only allows tying ranges which are aligned powers of two together; | |
| 401 | +eg indices 64-127 may be tied together, but 2-6 may not be. This may | |
| 402 | +save substantial quantities of memory; for example tying 512 entries | |
| 403 | +together will save over 4kB. | |
| 404 | + | |
| 405 | +You can create a multi-index entry by using :c:func:`XA_STATE_ORDER` | |
| 406 | +or :c:func:`xas_set_order` followed by a call to :c:func:`xas_store`. | |
| 407 | +Calling :c:func:`xas_load` with a multi-index xa_state will walk the | |
| 408 | +xa_state to the right location in the tree, but the return value is not | |
| 409 | +meaningful, potentially being an internal entry or ``NULL`` even when there | |
| 410 | +is an entry stored within the range. Calling :c:func:`xas_find_conflict` | |
| 411 | +will return the first entry within the range or ``NULL`` if there are no | |
| 412 | +entries in the range. The :c:func:`xas_for_each_conflict` iterator will | |
| 413 | +iterate over every entry which overlaps the specified range. | |
| 414 | + | |
| 415 | +If :c:func:`xas_load` encounters a multi-index entry, the xa_index | |
| 416 | +in the xa_state will not be changed. When iterating over an XArray | |
| 417 | +or calling :c:func:`xas_find`, if the initial index is in the middle | |
| 418 | +of a multi-index entry, it will not be altered. Subsequent calls | |
| 419 | +or iterations will move the index to the first index in the range. | |
| 420 | +Each entry will only be returned once, no matter how many indices it | |
| 421 | +occupies. | |
| 422 | + | |
| 423 | +Using :c:func:`xas_next` or :c:func:`xas_prev` with a multi-index xa_state | |
| 424 | +is not supported. Using either of these functions on a multi-index entry | |
| 425 | +will reveal sibling entries; these should be skipped over by the caller. | |
| 426 | + | |
| 427 | +Storing ``NULL`` into any index of a multi-index entry will set the entry | |
| 428 | +at every index to ``NULL`` and dissolve the tie. Splitting a multi-index | |
| 429 | +entry into entries occupying smaller ranges is not yet supported. | |
| 430 | + | |
| 431 | +Functions and structures | |
| 432 | +======================== | |
| 433 | + | |
| 434 | +.. kernel-doc:: include/linux/xarray.h | |
| 435 | +.. kernel-doc:: lib/xarray.c | |
| @@ -86,9 +86,11 @@ transitions. · 85 unmodified lines | ||
| 86 | 86 | This will give a fine grained information about all the CPU frequency |
| 87 | 87 | transitions. The cat output here is a two dimensional matrix, where an entry |
| 88 | 88 | <i,j> (row i, column j) represents the count of number of transitions from |
| 89 | −Freq_i to Freq_j. Freq_i is in descending order with increasing rows and | |
| 90 | −Freq_j is in descending order with increasing columns. The output here also | |
| 91 | −contains the actual freq values for each row and column for better readability. | |
| 89 | +Freq_i to Freq_j. Freq_i rows and Freq_j columns follow the sorting order in | |
| 90 | +which the driver has provided the frequency table initially to the cpufreq core | |
| 91 | +and so can be sorted (ascending or descending) or unsorted. The output here | |
| 92 | +also contains the actual freq values for each row and column for better | |
| 93 | +readability. | |
| 92 | 94 | |
| 93 | 95 | If the transition table is bigger than PAGE_SIZE, reading this will |
| 94 | 96 | return an -EFBIG error. |
| @@ -183,6 +183,10 @@ and looks like the following: · 182 unmodified lines | ||
| 183 | 183 | |
| 184 | 184 | void (*describe)(const struct key *key, struct seq_file *m); |
| 185 | 185 | void (*destroy)(void *payload); |
| 186 | + int (*query)(const struct kernel_pkey_params *params, | |
| 187 | + struct kernel_pkey_query *info); | |
| 188 | + int (*eds_op)(struct kernel_pkey_params *params, | |
| 189 | + const void *in, void *out); | |
| 186 | 190 | int (*verify_signature)(const struct key *key, |
| 187 | 191 | const struct public_key_signature *sig); |
| 188 | 192 | }; |
| @@ -207,12 +211,22 @@ There are a number of operations defined by the subtype: · 18 unmodified lines | ||
| 207 | 211 | asymmetric key will look after freeing the fingerprint and releasing the |
| 208 | 212 | reference on the subtype module. |
| 209 | 213 | |
| 210 | − (3) verify_signature(). | |
| 214 | + (3) query(). | |
| 211 | 215 | |
| 212 | − Optional. These are the entry points for the key usage operations. | |
| 213 | − Currently there is only the one defined. If not set, the caller will be | |
| 214 | − given -ENOTSUPP. The subtype may do anything it likes to implement an | |
| 215 | − operation, including offloading to hardware. | |
| 216 | + Mandatory. This is a function for querying the capabilities of a key. | |
| 217 | + | |
| 218 | + (4) eds_op(). | |
| 219 | + | |
| 220 | + Optional. This is the entry point for the encryption, decryption and | |
| 221 | + signature creation operations (which are distinguished by the operation ID | |
| 222 | + in the parameter struct). The subtype may do anything it likes to | |
| 223 | + implement an operation, including offloading to hardware. | |
| 224 | + | |
| 225 | + (5) verify_signature(). | |
| 226 | + | |
| 227 | + Optional. This is the entry point for signature verification. The | |
| 228 | + subtype may do anything it likes to implement an operation, including | |
| 229 | + offloading to hardware. | |
| 216 | 230 | |
| 217 | 231 | |
| 218 | 232 | ========================== |
| @@ -234,6 +248,8 @@ Examples of blob formats for which parsers could be implemented include: · 15 unmodified lines | ||
| 234 | 248 | - X.509 ASN.1 stream. |
| 235 | 249 | - Pointer to TPM key. |
| 236 | 250 | - Pointer to UEFI key. |
| 251 | + - PKCS#8 private key [RFC 5208]. | |
| 252 | + - PKCS#5 encrypted private key [RFC 2898]. | |
| 237 | 253 | |
| 238 | 254 | During key instantiation each parser in the list is tried until one doesn't |
| 239 | 255 | return -EBADMSG. |
| @@ -30,18 +30,29 @@ of many distributions, e.g. : · 29 unmodified lines | ||
| 30 | 30 | - NetBSD |
| 31 | 31 | - FreeBSD |
| 32 | 32 | |
| 33 | −You can get the latest version released from the Coccinelle homepage at | |
| 33 | +Some distribution packages are obsolete and it is recommended | |
| 34 | +to use the latest version released from the Coccinelle homepage at | |
| 34 | 35 | http://coccinelle.lip6.fr/ |
| 35 | 36 | |
| 36 | −Once you have it, run the following command:: | |
| 37 | +Or from Github at: | |
| 37 | 38 | |
| 38 | − ./configure | |
| 39 | +https://github.com/coccinelle/coccinelle | |
| 40 | + | |
| 41 | +Once you have it, run the following commands:: | |
| 42 | + | |
| 43 | + ./autogen | |
| 44 | + ./configure | |
| 39 | 45 | make |
| 40 | 46 | |
| 41 | 47 | as a regular user, and install it with:: |
| 42 | 48 | |
| 43 | 49 | sudo make install |
| 44 | 50 | |
| 51 | +More detailed installation instructions to build from source can be | |
| 52 | +found at: | |
| 53 | + | |
| 54 | +https://github.com/coccinelle/coccinelle/blob/master/install.txt | |
| 55 | + | |
| 45 | 56 | Supplemental documentation |
| 46 | 57 | --------------------------- |
| 47 | 58 | |
| @@ -51,6 +62,10 @@ https://bottest.wiki.kernel.org/coccicheck · 3 unmodified lines | ||
| 51 | 62 | |
| 52 | 63 | The wiki documentation always refers to the linux-next version of the script. |
| 53 | 64 | |
| 65 | +For Semantic Patch Language(SmPL) grammar documentation refer to: | |
| 66 | + | |
| 67 | +http://coccinelle.lip6.fr/documentation.php | |
| 68 | + | |
| 54 | 69 | Using Coccinelle on the Linux kernel |
| 55 | 70 | ------------------------------------ |
| 56 | 71 | |
| @@ -223,7 +238,7 @@ Since coccicheck runs through make, it naturally runs from the kernel · 166 unmodified lines | ||
| 223 | 238 | proper dir, as such the second rule above would be implied for picking up a |
| 224 | 239 | .cocciconfig when using ``make coccicheck``. |
| 225 | 240 | |
| 226 | −``make coccicheck`` also supports using M= targets.If you do not supply | |
| 241 | +``make coccicheck`` also supports using M= targets. If you do not supply | |
| 227 | 242 | any M= target, it is assumed you want to target the entire kernel. |
| 228 | 243 | The kernel coccicheck script has:: |
| 229 | 244 | |
| @@ -159,7 +159,7 @@ Contributing new tests (details) · 158 unmodified lines | ||
| 159 | 159 | * If a test needs specific kernel config options enabled, add a config file in |
| 160 | 160 | the test directory to enable them. |
| 161 | 161 | |
| 162 | − e.g: tools/testing/selftests/android/ion/config | |
| 162 | + e.g: tools/testing/selftests/android/config | |
| 163 | 163 | |
| 164 | 164 | Test Harness |
| 165 | 165 | ============ |
| @@ -33,6 +33,10 @@ Optional feature parameters: · 32 unmodified lines | ||
| 33 | 33 | All write I/O is silently ignored. |
| 34 | 34 | Read I/O is handled correctly. |
| 35 | 35 | |
| 36 | + error_writes: | |
| 37 | + All write I/O is failed with an error signalled. | |
| 38 | + Read I/O is handled correctly. | |
| 39 | + | |
| 36 | 40 | corrupt_bio_byte <Nth_byte> <direction> <value> <flags>: |
| 37 | 41 | During <down interval>, replace <Nth_byte> of the data of |
| 38 | 42 | each matching bio with <value>. |
| @@ -38,7 +38,7 @@ inconsistent file system. · 37 unmodified lines | ||
| 38 | 38 | Any REQ_FUA requests bypass this flushing mechanism and are logged as soon as |
| 39 | 39 | they complete as those requests will obviously bypass the device cache. |
| 40 | 40 | |
| 41 | −Any REQ_DISCARD requests are treated like WRITE requests. Otherwise we would | |
| 41 | +Any REQ_OP_DISCARD requests are treated like WRITE requests. Otherwise we would | |
| 42 | 42 | have all the DISCARD requests, and then the WRITE requests and then the FLUSH |
| 43 | 43 | request. Consider the following example: |
| 44 | 44 | |
| @@ -1,12 +0,0 @@ | ||
| 1 | −Documentation for device trees, a data structure by which bootloaders pass | |
| 2 | −hardware layout to Linux in a device-independent manner, simplifying hardware | |
| 3 | −probing. This subsystem is maintained by Grant Likely | |
| 4 | −<grant.likely@secretlab.ca> and has a mailing list at | |
| 5 | −https://lists.ozlabs.org/listinfo/devicetree-discuss | |
| 6 | − | |
| 7 | −00-INDEX | |
| 8 | − - this file | |
| 9 | −booting-without-of.txt | |
| 10 | − - Booting Linux without Open Firmware, describes history and format of device trees. | |
| 11 | −usage-model.txt | |
| 12 | − - How Linux uses DT and what DT aims to solve. | |
| @@ -14,75 +14,3 @@ compatible: must contain "al,alpine" · 13 unmodified lines | ||
| 14 | 14 | |
| 15 | 15 | ... |
| 16 | 16 | } |
| 17 | − | |
| 18 | −* CPU node: | |
| 19 | − | |
| 20 | −The Alpine platform includes cortex-a15 cores. | |
| 21 | −enable-method: must be "al,alpine-smp" to allow smp [1] | |
| 22 | − | |
| 23 | −Example: | |
| 24 | − | |
| 25 | −cpus { | |
| 26 | − #address-cells = <1>; | |
| 27 | − #size-cells = <0>; | |
| 28 | − enable-method = "al,alpine-smp"; | |
| 29 | − | |
| 30 | − cpu@0 { | |
| 31 | − compatible = "arm,cortex-a15"; | |
| 32 | − device_type = "cpu"; | |
| 33 | − reg = <0>; | |
| 34 | − }; | |
| 35 | − | |
| 36 | − cpu@1 { | |
| 37 | − compatible = "arm,cortex-a15"; | |
| 38 | − device_type = "cpu"; | |
| 39 | − reg = <1>; | |
| 40 | − }; | |
| 41 | − | |
| 42 | − cpu@2 { | |
| 43 | − compatible = "arm,cortex-a15"; | |
| 44 | − device_type = "cpu"; | |
| 45 | − reg = <2>; | |
| 46 | − }; | |
| 47 | − | |
| 48 | − cpu@3 { | |
| 49 | − compatible = "arm,cortex-a15"; | |
| 50 | − device_type = "cpu"; | |
| 51 | − reg = <3>; | |
| 52 | − }; | |
| 53 | −}; | |
| 54 | − | |
| 55 | − | |
| 56 | −* Alpine CPU resume registers | |
| 57 | − | |
| 58 | −The CPU resume register are used to define required resume address after | |
| 59 | −reset. | |
| 60 | − | |
| 61 | −Properties: | |
| 62 | −- compatible : Should contain "al,alpine-cpu-resume". | |
| 63 | −- reg : Offset and length of the register set for the device | |
| 64 | − | |
| 65 | −Example: | |
| 66 | − | |
| 67 | −cpu_resume { | |
| 68 | − compatible = "al,alpine-cpu-resume"; | |
| 69 | − reg = <0xfbff5ed0 0x30>; | |
| 70 | −}; | |
| 71 | − | |
| 72 | −* Alpine System-Fabric Service Registers | |
| 73 | − | |
| 74 | −The System-Fabric Service Registers allow various operation on CPU and | |
| 75 | −system fabric, like powering CPUs off. | |
| 76 | − | |
| 77 | −Properties: | |
| 78 | −- compatible : Should contain "al,alpine-sysfabric-service" and "syscon". | |
| 79 | −- reg : Offset and length of the register set for the device | |
| 80 | − | |
| 81 | −Example: | |
| 82 | − | |
| 83 | −nb_service { | |
| 84 | − compatible = "al,alpine-sysfabric-service", "syscon"; | |
| 85 | − reg = <0xfb070000 0x10000>; | |
| 86 | −}; | |
| 87 | − | |
| 88 | −[1] arm/cpu-enable-method/al,alpine-smp | |
| @@ -57,12 +57,17 @@ Boards with the Amlogic Meson AXG A113D SoC shall have the following properties: · 56 unmodified lines | ||
| 57 | 57 | Required root node property: |
| 58 | 58 | compatible: "amlogic,a113d", "amlogic,meson-axg"; |
| 59 | 59 | |
| 60 | +Boards with the Amlogic Meson G12A S905D2 SoC shall have the following properties: | |
| 61 | + Required root node property: | |
| 62 | + compatible: "amlogic,g12a"; | |
| 63 | + | |
| 60 | 64 | Board compatible values (alphabetically, grouped by SoC): |
| 61 | 65 | |
| 62 | 66 | - "geniatech,atv1200" (Meson6) |
| 63 | 67 | |
| 64 | 68 | - "minix,neo-x8" (Meson8) |
| 65 | 69 | |
| 70 | + - "endless,ec100" (Meson8b) | |
| 66 | 71 | - "hardkernel,odroid-c1" (Meson8b) |
| 67 | 72 | - "tronfy,mxq" (Meson8b) |
| 68 | 73 | |
| @@ -101,6 +106,8 @@ Board compatible values (alphabetically, grouped by SoC): · 32 unmodified lines | ||
| 101 | 106 | |
| 102 | 107 | - "amlogic,s400" (Meson axg a113d) |
| 103 | 108 | |
| 109 | + - "amlogic,u200" (Meson g12a s905d2) | |
| 110 | + | |
| 104 | 111 | Amlogic Meson Firmware registers Interface |
| 105 | 112 | ------------------------------------------ |
| 106 | 113 | |
| @@ -70,173 +70,3 @@ compatible: must be one of: · 69 unmodified lines | ||
| 70 | 70 | - "atmel,samv71q19" |
| 71 | 71 | - "atmel,samv71q20" |
| 72 | 72 | - "atmel,samv71q21" |
| 73 | − | |
| 74 | −Chipid required properties: | |
| 75 | −- compatible: Should be "atmel,sama5d2-chipid" | |
| 76 | −- reg : Should contain registers location and length | |
| 77 | − | |
| 78 | −PIT Timer required properties: | |
| 79 | −- compatible: Should be "atmel,at91sam9260-pit" | |
| 80 | −- reg: Should contain registers location and length | |
| 81 | −- interrupts: Should contain interrupt for the PIT which is the IRQ line | |
| 82 | − shared across all System Controller members. | |
| 83 | − | |
| 84 | −System Timer (ST) required properties: | |
| 85 | −- compatible: Should be "atmel,at91rm9200-st", "syscon", "simple-mfd" | |
| 86 | −- reg: Should contain registers location and length | |
| 87 | −- interrupts: Should contain interrupt for the ST which is the IRQ line | |
| 88 | − shared across all System Controller members. | |
| 89 | −- clocks: phandle to input clock. | |
| 90 | −Its subnodes can be: | |
| 91 | −- watchdog: compatible should be "atmel,at91rm9200-wdt" | |
| 92 | − | |
| 93 | −RSTC Reset Controller required properties: | |
| 94 | −- compatible: Should be "atmel,<chip>-rstc". | |
| 95 | − <chip> can be "at91sam9260" or "at91sam9g45" or "sama5d3" | |
| 96 | −- reg: Should contain registers location and length | |
| 97 | −- clocks: phandle to input clock. | |
| 98 | − | |
| 99 | −Example: | |
| 100 | − | |
| 101 | − rstc@fffffd00 { | |
| 102 | − compatible = "atmel,at91sam9260-rstc"; | |
| 103 | − reg = <0xfffffd00 0x10>; | |
| 104 | − clocks = <&clk32k>; | |
| 105 | − }; | |
| 106 | − | |
| 107 | −RAMC SDRAM/DDR Controller required properties: | |
| 108 | −- compatible: Should be "atmel,at91rm9200-sdramc", "syscon" | |
| 109 | − "atmel,at91sam9260-sdramc", | |
| 110 | − "atmel,at91sam9g45-ddramc", | |
| 111 | − "atmel,sama5d3-ddramc", | |
| 112 | −- reg: Should contain registers location and length | |
| 113 | − | |
| 114 | −Examples: | |
| 115 | − | |
| 116 | − ramc0: ramc@ffffe800 { | |
| 117 | − compatible = "atmel,at91sam9g45-ddramc"; | |
| 118 | − reg = <0xffffe800 0x200>; | |
| 119 | − }; | |
| 120 | − | |
| 121 | −SHDWC Shutdown Controller | |
| 122 | − | |
| 123 | −required properties: | |
| 124 | −- compatible: Should be "atmel,<chip>-shdwc". | |
| 125 | − <chip> can be "at91sam9260", "at91sam9rl" or "at91sam9x5". | |
| 126 | −- reg: Should contain registers location and length | |
| 127 | −- clocks: phandle to input clock. | |
| 128 | − | |
| 129 | −optional properties: | |
| 130 | −- atmel,wakeup-mode: String, operation mode of the wakeup mode. | |
| 131 | − Supported values are: "none", "high", "low", "any". | |
| 132 | −- atmel,wakeup-counter: Counter on Wake-up 0 (between 0x0 and 0xf). | |
| 133 | − | |
| 134 | −optional at91sam9260 properties: | |
| 135 | −- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up. | |
| 136 | − | |
| 137 | −optional at91sam9rl properties: | |
| 138 | −- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up. | |
| 139 | −- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up. | |
| 140 | − | |
| 141 | −optional at91sam9x5 properties: | |
| 142 | −- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up. | |
| 143 | − | |
| 144 | −Example: | |
| 145 | − | |
| 146 | − shdwc@fffffd10 { | |
| 147 | − compatible = "atmel,at91sam9260-shdwc"; | |
| 148 | − reg = <0xfffffd10 0x10>; | |
| 149 | − clocks = <&clk32k>; | |
| 150 | − }; | |
| 151 | − | |
| 152 | −SHDWC SAMA5D2-Compatible Shutdown Controller | |
| 153 | − | |
| 154 | −1) shdwc node | |
| 155 | − | |
| 156 | −required properties: | |
| 157 | −- compatible: should be "atmel,sama5d2-shdwc". | |
| 158 | −- reg: should contain registers location and length | |
| 159 | −- clocks: phandle to input clock. | |
| 160 | −- #address-cells: should be one. The cell is the wake-up input index. | |
| 161 | −- #size-cells: should be zero. | |
| 162 | − | |
| 163 | −optional properties: | |
| 164 | − | |
| 165 | −- debounce-delay-us: minimum wake-up inputs debouncer period in | |
| 166 | − microseconds. It's usually a board-related property. | |
| 167 | −- atmel,wakeup-rtc-timer: boolean to enable Real-Time Clock wake-up. | |
| 168 | − | |
| 169 | −The node contains child nodes for each wake-up input that the platform uses. | |
| 170 | − | |
| 171 | −2) input nodes | |
| 172 | − | |
| 173 | −Wake-up input nodes are usually described in the "board" part of the Device | |
| 174 | −Tree. Note also that input 0 is linked to the wake-up pin and is frequently | |
| 175 | −used. | |
| 176 | − | |
| 177 | −Required properties: | |
| 178 | −- reg: should contain the wake-up input index [0 - 15]. | |
| 179 | − | |
| 180 | −Optional properties: | |
| 181 | −- atmel,wakeup-active-high: boolean, the corresponding wake-up input described | |
| 182 | − by the child, forces the wake-up of the core power supply on a high level. | |
| 183 | − The default is to be active low. | |
| 184 | − | |
| 185 | −Example: | |
| 186 | − | |
| 187 | −On the SoC side: | |
| 188 | − shdwc@f8048010 { | |
| 189 | − compatible = "atmel,sama5d2-shdwc"; | |
| 190 | − reg = <0xf8048010 0x10>; | |
| 191 | − clocks = <&clk32k>; | |
| 192 | − #address-cells = <1>; | |
| 193 | − #size-cells = <0>; | |
| 194 | − atmel,wakeup-rtc-timer; | |
| 195 | − }; | |
| 196 | − | |
| 197 | −On the board side: | |
| 198 | − shdwc@f8048010 { | |
| 199 | − debounce-delay-us = <976>; | |
| 200 | − | |
| 201 | − input@0 { | |
| 202 | − reg = <0>; | |
| 203 | − }; | |
| 204 | − | |
| 205 | − input@1 { | |
| 206 | − reg = <1>; | |
| 207 | − atmel,wakeup-active-high; | |
| 208 | − }; | |
| 209 | − }; | |
| 210 | − | |
| 211 | −Special Function Registers (SFR) | |
| 212 | − | |
| 213 | −Special Function Registers (SFR) manage specific aspects of the integrated | |
| 214 | −memory, bridge implementations, processor and other functionality not controlled | |
| 215 | −elsewhere. | |
| 216 | − | |
| 217 | −required properties: | |
| 218 | −- compatible: Should be "atmel,<chip>-sfr", "syscon" or | |
| 219 | − "atmel,<chip>-sfrbu", "syscon" | |
| 220 | − <chip> can be "sama5d3", "sama5d4" or "sama5d2". | |
| 221 | −- reg: Should contain registers location and length | |
| 222 | − | |
| 223 | − sfr@f0038000 { | |
| 224 | − compatible = "atmel,sama5d3-sfr", "syscon"; | |
| 225 | − reg = <0xf0038000 0x60>; | |
| 226 | − }; | |
| 227 | − | |
| 228 | −Security Module (SECUMOD) | |
| 229 | − | |
| 230 | −The Security Module macrocell provides all necessary secure functions to avoid | |
| 231 | −voltage, temperature, frequency and mechanical attacks on the chip. It also | |
| 232 | −embeds secure memories that can be scrambled | |
| 233 | − | |
| 234 | −required properties: | |
| 235 | −- compatible: Should be "atmel,<chip>-secumod", "syscon". | |
| 236 | − <chip> can be "sama5d2". | |
| 237 | −- reg: Should contain registers location and length | |
| 238 | − | |
| 239 | − secumod@fc040000 { | |
| 240 | − compatible = "atmel,sama5d2-secumod", "syscon"; | |
| 241 | − reg = <0xfc040000 0x100>; | |
| 242 | − }; | |
| @@ -0,0 +1,171 @@ | ||
| 1 | +Atmel system registers | |
| 2 | + | |
| 3 | +Chipid required properties: | |
| 4 | +- compatible: Should be "atmel,sama5d2-chipid" | |
| 5 | +- reg : Should contain registers location and length | |
| 6 | + | |
| 7 | +PIT Timer required properties: | |
| 8 | +- compatible: Should be "atmel,at91sam9260-pit" | |
| 9 | +- reg: Should contain registers location and length | |
| 10 | +- interrupts: Should contain interrupt for the PIT which is the IRQ line | |
| 11 | + shared across all System Controller members. | |
| 12 | + | |
| 13 | +System Timer (ST) required properties: | |
| 14 | +- compatible: Should be "atmel,at91rm9200-st", "syscon", "simple-mfd" | |
| 15 | +- reg: Should contain registers location and length | |
| 16 | +- interrupts: Should contain interrupt for the ST which is the IRQ line | |
| 17 | + shared across all System Controller members. | |
| 18 | +- clocks: phandle to input clock. | |
| 19 | +Its subnodes can be: | |
| 20 | +- watchdog: compatible should be "atmel,at91rm9200-wdt" | |
| 21 | + | |
| 22 | +RSTC Reset Controller required properties: | |
| 23 | +- compatible: Should be "atmel,<chip>-rstc". | |
| 24 | + <chip> can be "at91sam9260" or "at91sam9g45" or "sama5d3" | |
| 25 | +- reg: Should contain registers location and length | |
| 26 | +- clocks: phandle to input clock. | |
| 27 | + | |
| 28 | +Example: | |
| 29 | + | |
| 30 | + rstc@fffffd00 { | |
| 31 | + compatible = "atmel,at91sam9260-rstc"; | |
| 32 | + reg = <0xfffffd00 0x10>; | |
| 33 | + clocks = <&clk32k>; | |
| 34 | + }; | |
| 35 | + | |
| 36 | +RAMC SDRAM/DDR Controller required properties: | |
| 37 | +- compatible: Should be "atmel,at91rm9200-sdramc", "syscon" | |
| 38 | + "atmel,at91sam9260-sdramc", | |
| 39 | + "atmel,at91sam9g45-ddramc", | |
| 40 | + "atmel,sama5d3-ddramc", | |
| 41 | +- reg: Should contain registers location and length | |
| 42 | + | |
| 43 | +Examples: | |
| 44 | + | |
| 45 | + ramc0: ramc@ffffe800 { | |
| 46 | + compatible = "atmel,at91sam9g45-ddramc"; | |
| 47 | + reg = <0xffffe800 0x200>; | |
| 48 | + }; | |
| 49 | + | |
| 50 | +SHDWC Shutdown Controller | |
| 51 | + | |
| 52 | +required properties: | |
| 53 | +- compatible: Should be "atmel,<chip>-shdwc". | |
| 54 | + <chip> can be "at91sam9260", "at91sam9rl" or "at91sam9x5". | |
| 55 | +- reg: Should contain registers location and length | |
| 56 | +- clocks: phandle to input clock. | |
| 57 | + | |
| 58 | +optional properties: | |
| 59 | +- atmel,wakeup-mode: String, operation mode of the wakeup mode. | |
| 60 | + Supported values are: "none", "high", "low", "any". | |
| 61 | +- atmel,wakeup-counter: Counter on Wake-up 0 (between 0x0 and 0xf). | |
| 62 | + | |
| 63 | +optional at91sam9260 properties: | |
| 64 | +- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up. | |
| 65 | + | |
| 66 | +optional at91sam9rl properties: | |
| 67 | +- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up. | |
| 68 | +- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up. | |
| 69 | + | |
| 70 | +optional at91sam9x5 properties: | |
| 71 | +- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up. | |
| 72 | + | |
| 73 | +Example: | |
| 74 | + | |
| 75 | + shdwc@fffffd10 { | |
| 76 | + compatible = "atmel,at91sam9260-shdwc"; | |
| 77 | + reg = <0xfffffd10 0x10>; | |
| 78 | + clocks = <&clk32k>; | |
| 79 | + }; | |
| 80 | + | |
| 81 | +SHDWC SAMA5D2-Compatible Shutdown Controller | |
| 82 | + | |
| 83 | +1) shdwc node | |
| 84 | + | |
| 85 | +required properties: | |
| 86 | +- compatible: should be "atmel,sama5d2-shdwc". | |
| 87 | +- reg: should contain registers location and length | |
| 88 | +- clocks: phandle to input clock. | |
| 89 | +- #address-cells: should be one. The cell is the wake-up input index. | |
| 90 | +- #size-cells: should be zero. | |
| 91 | + | |
| 92 | +optional properties: | |
| 93 | + | |
| 94 | +- debounce-delay-us: minimum wake-up inputs debouncer period in | |
| 95 | + microseconds. It's usually a board-related property. | |
| 96 | +- atmel,wakeup-rtc-timer: boolean to enable Real-Time Clock wake-up. | |
| 97 | + | |
| 98 | +The node contains child nodes for each wake-up input that the platform uses. | |
| 99 | + | |
| 100 | +2) input nodes | |
| 101 | + | |
| 102 | +Wake-up input nodes are usually described in the "board" part of the Device | |
| 103 | +Tree. Note also that input 0 is linked to the wake-up pin and is frequently | |
| 104 | +used. | |
| 105 | + | |
| 106 | +Required properties: | |
| 107 | +- reg: should contain the wake-up input index [0 - 15]. | |
| 108 | + | |
| 109 | +Optional properties: | |
| 110 | +- atmel,wakeup-active-high: boolean, the corresponding wake-up input described | |
| 111 | + by the child, forces the wake-up of the core power supply on a high level. | |
| 112 | + The default is to be active low. | |
| 113 | + | |
| 114 | +Example: | |
| 115 | + | |
| 116 | +On the SoC side: | |
| 117 | + shdwc@f8048010 { | |
| 118 | + compatible = "atmel,sama5d2-shdwc"; | |
| 119 | + reg = <0xf8048010 0x10>; | |
| 120 | + clocks = <&clk32k>; | |
| 121 | + #address-cells = <1>; | |
| 122 | + #size-cells = <0>; | |
| 123 | + atmel,wakeup-rtc-timer; | |
| 124 | + }; | |
| 125 | + | |
| 126 | +On the board side: | |
| 127 | + shdwc@f8048010 { | |
| 128 | + debounce-delay-us = <976>; | |
| 129 | + | |
| 130 | + input@0 { | |
| 131 | + reg = <0>; | |
| 132 | + }; | |
| 133 | + | |
| 134 | + input@1 { | |
| 135 | + reg = <1>; | |
| 136 | + atmel,wakeup-active-high; | |
| 137 | + }; | |
| 138 | + }; | |
| 139 | + | |
| 140 | +Special Function Registers (SFR) | |
| 141 | + | |
| 142 | +Special Function Registers (SFR) manage specific aspects of the integrated | |
| 143 | +memory, bridge implementations, processor and other functionality not controlled | |
| 144 | +elsewhere. | |
| 145 | + | |
| 146 | +required properties: | |
| 147 | +- compatible: Should be "atmel,<chip>-sfr", "syscon" or | |
| 148 | + "atmel,<chip>-sfrbu", "syscon" | |
| 149 | + <chip> can be "sama5d3", "sama5d4" or "sama5d2". | |
| 150 | +- reg: Should contain registers location and length | |
| 151 | + | |
| 152 | + sfr@f0038000 { | |
| 153 | + compatible = "atmel,sama5d3-sfr", "syscon"; | |
| 154 | + reg = <0xf0038000 0x60>; | |
| 155 | + }; | |
| 156 | + | |
| 157 | +Security Module (SECUMOD) | |
| 158 | + | |
| 159 | +The Security Module macrocell provides all necessary secure functions to avoid | |
| 160 | +voltage, temperature, frequency and mechanical attacks on the chip. It also | |
| 161 | +embeds secure memories that can be scrambled | |
| 162 | + | |
| 163 | +required properties: | |
| 164 | +- compatible: Should be "atmel,<chip>-secumod", "syscon". | |
| 165 | + <chip> can be "sama5d2". | |
| 166 | +- reg: Should contain registers location and length | |
| 167 | + | |
| 168 | + secumod@fc040000 { | |
| 169 | + compatible = "atmel,sama5d2-secumod", "syscon"; | |
| 170 | + reg = <0xfc040000 0x100>; | |
| 171 | + }; | |
| @@ -42,6 +42,14 @@ Raspberry Pi Compute Module · 41 unmodified lines | ||
| 42 | 42 | Required root node properties: |
| 43 | 43 | compatible = "raspberrypi,compute-module", "brcm,bcm2835"; |
| 44 | 44 | |
| 45 | +Raspberry Pi Compute Module 3 | |
| 46 | +Required root node properties: | |
| 47 | +compatible = "raspberrypi,3-compute-module", "brcm,bcm2837"; | |
| 48 | + | |
| 49 | +Raspberry Pi Compute Module 3 Lite | |
| 50 | +Required root node properties: | |
| 51 | +compatible = "raspberrypi,3-compute-module-lite", "brcm,bcm2837"; | |
| 52 | + | |
| 45 | 53 | Raspberry Pi Zero |
| 46 | 54 | Required root node properties: |
| 47 | 55 | compatible = "raspberrypi,model-zero", "brcm,bcm2835"; |
| @@ -54,9 +54,7 @@ its hardware characteristcs. · 53 unmodified lines | ||
| 54 | 54 | clocks the core of that coresight component. The latter clock |
| 55 | 55 | is optional. |
| 56 | 56 | |
| 57 | − * port or ports: The representation of the component's port | |
| 58 | − layout using the generic DT graph presentation found in | |
| 59 | − "bindings/graph.txt". | |
| 57 | + * port or ports: see "Graph bindings for Coresight" below. | |
| 60 | 58 | |
| 61 | 59 | * Additional required properties for System Trace Macrocells (STM): |
| 62 | 60 | * reg: along with the physical base address and length of the register |
| @@ -73,7 +71,7 @@ its hardware characteristcs. · 10 unmodified lines | ||
| 73 | 71 | AMBA markee): |
| 74 | 72 | - "arm,coresight-replicator" |
| 75 | 73 | |
| 76 | − * port or ports: same as above. | |
| 74 | + * port or ports: see "Graph bindings for Coresight" below. | |
| 77 | 75 | |
| 78 | 76 | * Optional properties for ETM/PTMs: |
| 79 | 77 | |
| @@ -96,6 +94,20 @@ its hardware characteristcs. · 16 unmodified lines | ||
| 96 | 94 | * interrupts : Exactly one SPI may be listed for reporting the address |
| 97 | 95 | error |
| 98 | 96 | |
| 97 | +Graph bindings for Coresight | |
| 98 | +------------------------------- | |
| 99 | + | |
| 100 | +Coresight components are interconnected to create a data path for the flow of | |
| 101 | +trace data generated from the "sources" to their collection points "sink". | |
| 102 | +Each coresight component must describe the "input" and "output" connections. | |
| 103 | +The connections must be described via generic DT graph bindings as described | |
| 104 | +by the "bindings/graph.txt", where each "port" along with an "endpoint" | |
| 105 | +component represents a hardware port and the connection. | |
| 106 | + | |
| 107 | + * All output ports must be listed inside a child node named "out-ports" | |
| 108 | + * All input ports must be listed inside a child node named "in-ports". | |
| 109 | + * Port address must match the hardware port number. | |
| 110 | + | |
| 99 | 111 | Example: |
| 100 | 112 | |
| 101 | 113 | 1. Sinks |
| @@ -105,10 +117,11 @@ Example: · 3 unmodified lines | ||
| 105 | 117 | |
| 106 | 118 | clocks = <&oscclk6a>; |
| 107 | 119 | clock-names = "apb_pclk"; |
| 108 | − port { | |
| 109 | − etb_in_port: endpoint@0 { | |
| 110 | − slave-mode; | |
| 111 | − remote-endpoint = <&replicator_out_port0>; | |
| 120 | + in-ports { | |
| 121 | + port { | |
| 122 | + etb_in_port: endpoint@0 { | |
| 123 | + remote-endpoint = <&replicator_out_port0>; | |
| 124 | + }; | |
| 112 | 125 | }; |
| 113 | 126 | }; |
| 114 | 127 | }; |
| @@ -119,10 +132,11 @@ Example: · 4 unmodified lines | ||
| 119 | 132 | |
| 120 | 133 | clocks = <&oscclk6a>; |
| 121 | 134 | clock-names = "apb_pclk"; |
| 122 | − port { | |
| 123 | − tpiu_in_port: endpoint@0 { | |
| 124 | − slave-mode; | |
| 125 | − remote-endpoint = <&replicator_out_port1>; | |
| 135 | + in-ports { | |
| 136 | + port { | |
| 137 | + tpiu_in_port: endpoint@0 { | |
| 138 | + remote-endpoint = <&replicator_out_port1>; | |
| 139 | + }; | |
| 126 | 140 | }; |
| 127 | 141 | }; |
| 128 | 142 | }; |
| @@ -133,22 +147,16 @@ Example: · 4 unmodified lines | ||
| 133 | 147 | |
| 134 | 148 | clocks = <&oscclk6a>; |
| 135 | 149 | clock-names = "apb_pclk"; |
| 136 | − ports { | |
| 137 | − #address-cells = <1>; | |
| 138 | − #size-cells = <0>; | |
| 139 | − | |
| 140 | − /* input port */ | |
| 141 | − port@0 { | |
| 142 | − reg = <0>; | |
| 150 | + in-ports { | |
| 151 | + port { | |
| 143 | 152 | etr_in_port: endpoint { |
| 144 | − slave-mode; | |
| 145 | 153 | remote-endpoint = <&replicator2_out_port0>; |
| 146 | 154 | }; |
| 147 | 155 | }; |
| 156 | + }; | |
| 148 | 157 | |
| 149 | − /* CATU link represented by output port */ | |
| 150 | − port@1 { | |
| 151 | − reg = <1>; | |
| 158 | + out-ports { | |
| 159 | + port { | |
| 152 | 160 | etr_out_port: endpoint { |
| 153 | 161 | remote-endpoint = <&catu_in_port>; |
| 154 | 162 | }; |
| @@ -163,7 +171,7 @@ Example: · 8 unmodified lines | ||
| 163 | 171 | */ |
| 164 | 172 | compatible = "arm,coresight-replicator"; |
| 165 | 173 | |
| 166 | − ports { | |
| 174 | + out-ports { | |
| 167 | 175 | #address-cells = <1>; |
| 168 | 176 | #size-cells = <0>; |
| 169 | 177 | |
| @@ -181,12 +189,11 @@ Example: · 11 unmodified lines | ||
| 181 | 189 | remote-endpoint = <&tpiu_in_port>; |
| 182 | 190 | }; |
| 183 | 191 | }; |
| 192 | + }; | |
| 184 | 193 | |
| 185 | − /* replicator input port */ | |
| 186 | − port@2 { | |
| 187 | − reg = <0>; | |
| 194 | + in-ports { | |
| 195 | + port { | |
| 188 | 196 | replicator_in_port0: endpoint { |
| 189 | − slave-mode; | |
| 190 | 197 | remote-endpoint = <&funnel_out_port0>; |
| 191 | 198 | }; |
| 192 | 199 | }; |
| @@ -199,40 +206,36 @@ Example: · 6 unmodified lines | ||
| 199 | 206 | |
| 200 | 207 | clocks = <&oscclk6a>; |
| 201 | 208 | clock-names = "apb_pclk"; |
| 202 | − ports { | |
| 203 | − #address-cells = <1>; | |
| 204 | − #size-cells = <0>; | |
| 205 | − | |
| 206 | − /* funnel output port */ | |
| 207 | − port@0 { | |
| 208 | − reg = <0>; | |
| 209 | + out-ports { | |
| 210 | + port { | |
| 209 | 211 | funnel_out_port0: endpoint { |
| 210 | 212 | remote-endpoint = |
| 211 | 213 | <&replicator_in_port0>; |
| 212 | 214 | }; |
| 213 | 215 | }; |
| 216 | + }; | |
| 214 | 217 | |
| 215 | − /* funnel input ports */ | |
| 216 | − port@1 { | |
| 218 | + in-ports { | |
| 219 | + #address-cells = <1>; | |
| 220 | + #size-cells = <0>; | |
| 221 | + | |
| 222 | + port@0 { | |
| 217 | 223 | reg = <0>; |
| 218 | 224 | funnel_in_port0: endpoint { |
| 219 | − slave-mode; | |
| 220 | 225 | remote-endpoint = <&ptm0_out_port>; |
| 221 | 226 | }; |
| 222 | 227 | }; |
| 223 | 228 | |
| 224 | − port@2 { | |
| 229 | + port@1 { | |
| 225 | 230 | reg = <1>; |
| 226 | 231 | funnel_in_port1: endpoint { |
| 227 | − slave-mode; | |
| 228 | 232 | remote-endpoint = <&ptm1_out_port>; |
| 229 | 233 | }; |
| 230 | 234 | }; |
| 231 | 235 | |
| 232 | − port@3 { | |
| 236 | + port@2 { | |
| 233 | 237 | reg = <2>; |
| 234 | 238 | funnel_in_port2: endpoint { |
| 235 | − slave-mode; | |
| 236 | 239 | remote-endpoint = <&etm0_out_port>; |
| 237 | 240 | }; |
| 238 | 241 | }; |
| @@ -248,9 +251,11 @@ Example: · 9 unmodified lines | ||
| 248 | 251 | cpu = <&cpu0>; |
| 249 | 252 | clocks = <&oscclk6a>; |
| 250 | 253 | clock-names = "apb_pclk"; |
| 251 | − port { | |
| 252 | − ptm0_out_port: endpoint { | |
| 253 | − remote-endpoint = <&funnel_in_port0>; | |
| 254 | + out-ports { | |
| 255 | + port { | |
| 256 | + ptm0_out_port: endpoint { | |
| 257 | + remote-endpoint = <&funnel_in_port0>; | |
| 258 | + }; | |
| 254 | 259 | }; |
| 255 | 260 | }; |
| 256 | 261 | }; |
| @@ -262,9 +267,11 @@ Example: · 5 unmodified lines | ||
| 262 | 267 | cpu = <&cpu1>; |
| 263 | 268 | clocks = <&oscclk6a>; |
| 264 | 269 | clock-names = "apb_pclk"; |
| 265 | − port { | |
| 266 | − ptm1_out_port: endpoint { | |
| 267 | − remote-endpoint = <&funnel_in_port1>; | |
| 270 | + out-ports { | |
| 271 | + port { | |
| 272 | + ptm1_out_port: endpoint { | |
| 273 | + remote-endpoint = <&funnel_in_port1>; | |
| 274 | + }; | |
| 268 | 275 | }; |
| 269 | 276 | }; |
| 270 | 277 | }; |
| @@ -278,9 +285,11 @@ Example: · 7 unmodified lines | ||
| 278 | 285 | |
| 279 | 286 | clocks = <&soc_smc50mhz>; |
| 280 | 287 | clock-names = "apb_pclk"; |
| 281 | − port { | |
| 282 | − stm_out_port: endpoint { | |
| 283 | − remote-endpoint = <&main_funnel_in_port2>; | |
| 288 | + out-ports { | |
| 289 | + port { | |
| 290 | + stm_out_port: endpoint { | |
| 291 | + remote-endpoint = <&main_funnel_in_port2>; | |
| 292 | + }; | |
| 284 | 293 | }; |
| 285 | 294 | }; |
| 286 | 295 | }; |
| @@ -295,10 +304,11 @@ Example: · 8 unmodified lines | ||
| 295 | 304 | clock-names = "apb_pclk"; |
| 296 | 305 | |
| 297 | 306 | interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>; |
| 298 | − port { | |
| 299 | − catu_in_port: endpoint { | |
| 300 | − slave-mode; | |
| 301 | − remote-endpoint = <&etr_out_port>; | |
| 307 | + in-ports { | |
| 308 | + port { | |
| 309 | + catu_in_port: endpoint { | |
| 310 | + remote-endpoint = <&etr_out_port>; | |
| 311 | + }; | |
| 302 | 312 | }; |
| 303 | 313 | }; |
| 304 | 314 | }; |
| @@ -59,9 +59,11 @@ mhz values (normalized w.r.t. the highest value found while parsing the DT). · 58 unmodified lines | ||
| 59 | 59 | =========================================== |
| 60 | 60 | |
| 61 | 61 | Example 1 (ARM 64-bit, 6-cpu system, two clusters): |
| 62 | −capacities-dmips-mhz are scaled w.r.t. 1024 (cpu@0 and cpu@1) | |
| 63 | −supposing cluster0@max-freq=1100 and custer1@max-freq=850, | |
| 64 | −final capacities are 1024 for cluster0 and 446 for cluster1 | |
| 62 | +The capacities-dmips-mhz or DMIPS/MHz values (scaled to 1024) | |
| 63 | +are 1024 and 578 for cluster0 and cluster1. Further normalization | |
| 64 | +is done by the operating system based on cluster0@max-freq=1100 and | |
| 65 | +custer1@max-freq=850, final capacities are 1024 for cluster0 and | |
| 66 | +446 for cluster1 (576*850/1100). | |
| 65 | 67 | |
| 66 | 68 | cpus { |
| 67 | 69 | #address-cells = <2>; |
| @@ -14,7 +14,28 @@ Related properties: (none) · 13 unmodified lines | ||
| 14 | 14 | |
| 15 | 15 | Note: |
| 16 | 16 | This enable method requires valid nodes compatible with |
| 17 | −"al,alpine-cpu-resume" and "al,alpine-nb-service"[1]. | |
| 17 | +"al,alpine-cpu-resume" and "al,alpine-nb-service". | |
| 18 | + | |
| 19 | + | |
| 20 | +* Alpine CPU resume registers | |
| 21 | + | |
| 22 | +The CPU resume register are used to define required resume address after | |
| 23 | +reset. | |
| 24 | + | |
| 25 | +Properties: | |
| 26 | +- compatible : Should contain "al,alpine-cpu-resume". | |
| 27 | +- reg : Offset and length of the register set for the device | |
| 28 | + | |
| 29 | + | |
| 30 | +* Alpine System-Fabric Service Registers | |
| 31 | + | |
| 32 | +The System-Fabric Service Registers allow various operation on CPU and | |
| 33 | +system fabric, like powering CPUs off. | |
| 34 | + | |
| 35 | +Properties: | |
| 36 | +- compatible : Should contain "al,alpine-sysfabric-service" and "syscon". | |
| 37 | +- reg : Offset and length of the register set for the device | |
| 38 | + | |
| 18 | 39 | |
| 19 | 40 | Example: |
| 20 | 41 | |
| @@ -48,5 +69,12 @@ cpus { · 27 unmodified lines | ||
| 48 | 69 | }; |
| 49 | 70 | }; |
| 50 | 71 | |
| 51 | −-- | |
| 52 | −[1] arm/al,alpine.txt | |
| 72 | +cpu_resume { | |
| 73 | + compatible = "al,alpine-cpu-resume"; | |
| 74 | + reg = <0xfbff5ed0 0x30>; | |
| 75 | +}; | |
| 76 | + | |
| 77 | +nb_service { | |
| 78 | + compatible = "al,alpine-sysfabric-service", "syscon"; | |
| 79 | + reg = <0xfb070000 0x10000>; | |
| 80 | +}; | |
| @@ -276,7 +276,7 @@ described below. · 275 unmodified lines | ||
| 276 | 276 | Usage: optional |
| 277 | 277 | Value type: <prop-encoded-array> |
| 278 | 278 | Definition: A u32 value that represents the running time dynamic |
| 279 | − power coefficient in units of mW/MHz/uV^2. The | |
| 279 | + power coefficient in units of uW/MHz/V^2. The | |
| 280 | 280 | coefficient can either be calculated from power |
| 281 | 281 | measurements or derived by analysis. |
| 282 | 282 | |
| @@ -287,7 +287,7 @@ described below. · 4 unmodified lines | ||
| 287 | 287 | |
| 288 | 288 | Pdyn = dynamic-power-coefficient * V^2 * f |
| 289 | 289 | |
| 290 | − where voltage is in uV, frequency is in MHz. | |
| 290 | + where voltage is in V, frequency is in MHz. | |
| 291 | 291 | |
| 292 | 292 | Example 1 (dual-cluster big.LITTLE system 32-bit): |
| 293 | 293 | |
| @@ -0,0 +1,19 @@ | ||
| 1 | +Freescale DCFG | |
| 2 | + | |
| 3 | +DCFG is the device configuration unit, that provides general purpose | |
| 4 | +configuration and status for the device. Such as setting the secondary | |
| 5 | +core start address and release the secondary core from holdoff and startup. | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | + - compatible: Should contain a chip-specific compatible string, | |
| 9 | + Chip-specific strings are of the form "fsl,<chip>-dcfg", | |
| 10 | + The following <chip>s are known to be supported: | |
| 11 | + ls1012a, ls1021a, ls1043a, ls1046a, ls2080a. | |
| 12 | + | |
| 13 | + - reg : should contain base address and length of DCFG memory-mapped registers | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + dcfg: dcfg@1ee0000 { | |
| 17 | + compatible = "fsl,ls1021a-dcfg"; | |
| 18 | + reg = <0x0 0x1ee0000 0x0 0x10000>; | |
| 19 | + }; | |
| @@ -0,0 +1,19 @@ | ||
| 1 | +Freescale SCFG | |
| 2 | + | |
| 3 | +SCFG is the supplemental configuration unit, that provides SoC specific | |
| 4 | +configuration and status registers for the chip. Such as getting PEX port | |
| 5 | +status. | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | + - compatible: Should contain a chip-specific compatible string, | |
| 9 | + Chip-specific strings are of the form "fsl,<chip>-scfg", | |
| 10 | + The following <chip>s are known to be supported: | |
| 11 | + ls1012a, ls1021a, ls1043a, ls1046a, ls2080a. | |
| 12 | + | |
| 13 | + - reg: should contain base address and length of SCFG memory-mapped registers | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + scfg: scfg@1570000 { | |
| 17 | + compatible = "fsl,ls1021a-scfg"; | |
| 18 | + reg = <0x0 0x1570000 0x0 0x10000>; | |
| 19 | + }; | |
| @@ -0,0 +1,183 @@ | ||
| 1 | +NXP i.MX System Controller Firmware (SCFW) | |
| 2 | +-------------------------------------------------------------------- | |
| 3 | + | |
| 4 | +The System Controller Firmware (SCFW) is a low-level system function | |
| 5 | +which runs on a dedicated Cortex-M core to provide power, clock, and | |
| 6 | +resource management. It exists on some i.MX8 processors. e.g. i.MX8QM | |
| 7 | +(QM, QP), and i.MX8QX (QXP, DX). | |
| 8 | + | |
| 9 | +The AP communicates with the SC using a multi-ported MU module found | |
| 10 | +in the LSIO subsystem. The current definition of this MU module provides | |
| 11 | +5 remote AP connections to the SC to support up to 5 execution environments | |
| 12 | +(TZ, HV, standard Linux, etc.). The SC side of this MU module interfaces | |
| 13 | +with the LSIO DSC IP bus. The SC firmware will communicate with this MU | |
| 14 | +using the MSI bus. | |
| 15 | + | |
| 16 | +System Controller Device Node: | |
| 17 | +============================================================ | |
| 18 | + | |
| 19 | +The scu node with the following properties shall be under the /firmware/ node. | |
| 20 | + | |
| 21 | +Required properties: | |
| 22 | +------------------- | |
| 23 | +- compatible: should be "fsl,imx-scu". | |
| 24 | +- mbox-names: should include "tx0", "tx1", "tx2", "tx3", | |
| 25 | + "rx0", "rx1", "rx2", "rx3". | |
| 26 | +- mboxes: List of phandle of 4 MU channels for tx and 4 MU channels | |
| 27 | + for rx. All 8 MU channels must be in the same MU instance. | |
| 28 | + Cross instances are not allowed. The MU instance can only | |
| 29 | + be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users need | |
| 30 | + to make sure use the one which is not conflict with other | |
| 31 | + execution environments. e.g. ATF. | |
| 32 | + Note: | |
| 33 | + Channel 0 must be "tx0" or "rx0". | |
| 34 | + Channel 1 must be "tx1" or "rx1". | |
| 35 | + Channel 2 must be "tx2" or "rx2". | |
| 36 | + Channel 3 must be "tx3" or "rx3". | |
| 37 | + e.g. | |
| 38 | + mboxes = <&lsio_mu1 0 0 | |
| 39 | + &lsio_mu1 0 1 | |
| 40 | + &lsio_mu1 0 2 | |
| 41 | + &lsio_mu1 0 3 | |
| 42 | + &lsio_mu1 1 0 | |
| 43 | + &lsio_mu1 1 1 | |
| 44 | + &lsio_mu1 1 2 | |
| 45 | + &lsio_mu1 1 3>; | |
| 46 | + See Documentation/devicetree/bindings/mailbox/fsl,mu.txt | |
| 47 | + for detailed mailbox binding. | |
| 48 | + | |
| 49 | +i.MX SCU Client Device Node: | |
| 50 | +============================================================ | |
| 51 | + | |
| 52 | +Client nodes are maintained as children of the relevant IMX-SCU device node. | |
| 53 | + | |
| 54 | +Power domain bindings based on SCU Message Protocol | |
| 55 | +------------------------------------------------------------ | |
| 56 | + | |
| 57 | +This binding for the SCU power domain providers uses the generic power | |
| 58 | +domain binding[2]. | |
| 59 | + | |
| 60 | +Required properties: | |
| 61 | +- compatible: Should be "fsl,scu-pd". | |
| 62 | +- #address-cells: Should be 1. | |
| 63 | +- #size-cells: Should be 0. | |
| 64 | + | |
| 65 | +Required properties for power domain sub nodes: | |
| 66 | +- #power-domain-cells: Must be 0. | |
| 67 | + | |
| 68 | +Optional Properties: | |
| 69 | +- reg: Resource ID of this power domain. | |
| 70 | + No exist means uncontrollable by user. | |
| 71 | + See detailed Resource ID list from: | |
| 72 | + include/dt-bindings/power/imx-rsrc.h | |
| 73 | +- power-domains: phandle pointing to the parent power domain. | |
| 74 | + | |
| 75 | +Clock bindings based on SCU Message Protocol | |
| 76 | +------------------------------------------------------------ | |
| 77 | + | |
| 78 | +This binding uses the common clock binding[1]. | |
| 79 | + | |
| 80 | +Required properties: | |
| 81 | +- compatible: Should be "fsl,imx8qxp-clock". | |
| 82 | +- #clock-cells: Should be 1. Contains the Clock ID value. | |
| 83 | +- clocks: List of clock specifiers, must contain an entry for | |
| 84 | + each required entry in clock-names | |
| 85 | +- clock-names: Should include entries "xtal_32KHz", "xtal_24MHz" | |
| 86 | + | |
| 87 | +The clock consumer should specify the desired clock by having the clock | |
| 88 | +ID in its "clocks" phandle cell. | |
| 89 | + | |
| 90 | +See the full list of clock IDs from: | |
| 91 | +include/dt-bindings/clock/imx8qxp-clock.h | |
| 92 | + | |
| 93 | +Pinctrl bindings based on SCU Message Protocol | |
| 94 | +------------------------------------------------------------ | |
| 95 | + | |
| 96 | +This binding uses the i.MX common pinctrl binding[3]. | |
| 97 | + | |
| 98 | +Required properties: | |
| 99 | +- compatible: Should be "fsl,imx8qxp-iomuxc". | |
| 100 | + | |
| 101 | +Required properties for Pinctrl sub nodes: | |
| 102 | +- fsl,pins: Each entry consists of 3 integers which represents | |
| 103 | + the mux and config setting for one pin. The first 2 | |
| 104 | + integers <pin_id mux_mode> are specified using a | |
| 105 | + PIN_FUNC_ID macro, which can be found in | |
| 106 | + <dt-bindings/pinctrl/pads-imx8qxp.h>. | |
| 107 | + The last integer CONFIG is the pad setting value like | |
| 108 | + pull-up on this pin. | |
| 109 | + | |
| 110 | + Please refer to i.MX8QXP Reference Manual for detailed | |
| 111 | + CONFIG settings. | |
| 112 | + | |
| 113 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 114 | +[2] Documentation/devicetree/bindings/power/power_domain.txt | |
| 115 | +[3] Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt | |
| 116 | + | |
| 117 | +Example (imx8qxp): | |
| 118 | +------------- | |
| 119 | +lsio_mu1: mailbox@5d1c0000 { | |
| 120 | + ... | |
| 121 | + #mbox-cells = <2>; | |
| 122 | +}; | |
| 123 | + | |
| 124 | +firmware { | |
| 125 | + scu { | |
| 126 | + compatible = "fsl,imx-scu"; | |
| 127 | + mbox-names = "tx0", "tx1", "tx2", "tx3", | |
| 128 | + "rx0", "rx1", "rx2", "rx3"; | |
| 129 | + mboxes = <&lsio_mu1 0 0 | |
| 130 | + &lsio_mu1 0 1 | |
| 131 | + &lsio_mu1 0 2 | |
| 132 | + &lsio_mu1 0 3 | |
| 133 | + &lsio_mu1 1 0 | |
| 134 | + &lsio_mu1 1 1 | |
| 135 | + &lsio_mu1 1 2 | |
| 136 | + &lsio_mu1 1 3>; | |
| 137 | + | |
| 138 | + clk: clk { | |
| 139 | + compatible = "fsl,imx8qxp-clk"; | |
| 140 | + #clock-cells = <1>; | |
| 141 | + }; | |
| 142 | + | |
| 143 | + iomuxc { | |
| 144 | + compatible = "fsl,imx8qxp-iomuxc"; | |
| 145 | + | |
| 146 | + pinctrl_lpuart0: lpuart0grp { | |
| 147 | + fsl,pins = < | |
| 148 | + SC_P_UART0_RX_ADMA_UART0_RX 0x06000020 | |
| 149 | + SC_P_UART0_TX_ADMA_UART0_TX 0x06000020 | |
| 150 | + >; | |
| 151 | + }; | |
| 152 | + ... | |
| 153 | + }; | |
| 154 | + | |
| 155 | + imx8qx-pm { | |
| 156 | + compatible = "fsl,scu-pd"; | |
| 157 | + #address-cells = <1>; | |
| 158 | + #size-cells = <0>; | |
| 159 | + | |
| 160 | + pd_dma: dma-power-domain { | |
| 161 | + #power-domain-cells = <0>; | |
| 162 | + | |
| 163 | + pd_dma_lpuart0: dma-lpuart0@57 { | |
| 164 | + reg = <SC_R_UART_0>; | |
| 165 | + #power-domain-cells = <0>; | |
| 166 | + power-domains = <&pd_dma>; | |
| 167 | + }; | |
| 168 | + ... | |
| 169 | + }; | |
| 170 | + ... | |
| 171 | + }; | |
| 172 | + }; | |
| 173 | +}; | |
| 174 | + | |
| 175 | +serial@5a060000 { | |
| 176 | + ... | |
| 177 | + pinctrl-names = "default"; | |
| 178 | + pinctrl-0 = <&pinctrl_lpuart0>; | |
| 179 | + clocks = <&clk IMX8QXP_UART0_CLK>, | |
| 180 | + <&clk IMX8QXP_UART0_IPG_CLK>; | |
| 181 | + clock-names = "per", "ipg"; | |
| 182 | + power-domains = <&pd_dma_lpuart0>; | |
| 183 | +}; | |
| @@ -57,6 +57,50 @@ i.MX6SLL EVK board · 56 unmodified lines | ||
| 57 | 57 | Required root node properties: |
| 58 | 58 | - compatible = "fsl,imx6sll-evk", "fsl,imx6sll"; |
| 59 | 59 | |
| 60 | +i.MX6 Quad Plus SABRE Smart Device Board | |
| 61 | +Required root node properties: | |
| 62 | + - compatible = "fsl,imx6qp-sabresd", "fsl,imx6qp"; | |
| 63 | + | |
| 64 | +i.MX6 Quad Plus SABRE Automotive Board | |
| 65 | +Required root node properties: | |
| 66 | + - compatible = "fsl,imx6qp-sabreauto", "fsl,imx6qp"; | |
| 67 | + | |
| 68 | +i.MX6 DualLite SABRE Smart Device Board | |
| 69 | +Required root node properties: | |
| 70 | + - compatible = "fsl,imx6dl-sabresd", "fsl,imx6dl"; | |
| 71 | + | |
| 72 | +i.MX6 DualLite/Solo SABRE Automotive Board | |
| 73 | +Required root node properties: | |
| 74 | + - compatible = "fsl,imx6dl-sabreauto", "fsl,imx6dl"; | |
| 75 | + | |
| 76 | +i.MX6 SoloLite EVK Board | |
| 77 | +Required root node properties: | |
| 78 | + - compatible = "fsl,imx6sl-evk", "fsl,imx6sl"; | |
| 79 | + | |
| 80 | +i.MX6 UltraLite 14x14 EVK Board | |
| 81 | +Required root node properties: | |
| 82 | + - compatible = "fsl,imx6ul-14x14-evk", "fsl,imx6ul"; | |
| 83 | + | |
| 84 | +i.MX6 UltraLiteLite 14x14 EVK Board | |
| 85 | +Required root node properties: | |
| 86 | + - compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull"; | |
| 87 | + | |
| 88 | +i.MX6 ULZ 14x14 EVK Board | |
| 89 | +Required root node properties: | |
| 90 | + - compatible = "fsl,imx6ulz-14x14-evk", "fsl,imx6ull", "fsl,imx6ulz"; | |
| 91 | + | |
| 92 | +i.MX6 SoloX SDB Board | |
| 93 | +Required root node properties: | |
| 94 | + - compatible = "fsl,imx6sx-sdb", "fsl,imx6sx"; | |
| 95 | + | |
| 96 | +i.MX6 SoloX Sabre Auto Board | |
| 97 | +Required root node properties: | |
| 98 | + - compatible = "fsl,imx6sx-sabreauto", "fsl,imx6sx"; | |
| 99 | + | |
| 100 | +i.MX7 SabreSD Board | |
| 101 | +Required root node properties: | |
| 102 | + - compatible = "fsl,imx7d-sdb", "fsl,imx7d"; | |
| 103 | + | |
| 60 | 104 | Generic i.MX boards |
| 61 | 105 | ------------------- |
| 62 | 106 | |
| @@ -101,45 +145,6 @@ Freescale LS1021A Platform Device Tree Bindings · 38 unmodified lines | ||
| 101 | 145 | Required root node compatible properties: |
| 102 | 146 | - compatible = "fsl,ls1021a"; |
| 103 | 147 | |
| 104 | −Freescale SoC-specific Device Tree Bindings | |
| 105 | −------------------------------------------- | |
| 106 | − | |
| 107 | −Freescale SCFG | |
| 108 | − SCFG is the supplemental configuration unit, that provides SoC specific | |
| 109 | −configuration and status registers for the chip. Such as getting PEX port | |
| 110 | −status. | |
| 111 | − Required properties: | |
| 112 | − - compatible: Should contain a chip-specific compatible string, | |
| 113 | − Chip-specific strings are of the form "fsl,<chip>-scfg", | |
| 114 | − The following <chip>s are known to be supported: | |
| 115 | − ls1012a, ls1021a, ls1043a, ls1046a, ls2080a. | |
| 116 | − | |
| 117 | − - reg: should contain base address and length of SCFG memory-mapped registers | |
| 118 | − | |
| 119 | −Example: | |
| 120 | − scfg: scfg@1570000 { | |
| 121 | − compatible = "fsl,ls1021a-scfg"; | |
| 122 | − reg = <0x0 0x1570000 0x0 0x10000>; | |
| 123 | − }; | |
| 124 | − | |
| 125 | −Freescale DCFG | |
| 126 | − DCFG is the device configuration unit, that provides general purpose | |
| 127 | −configuration and status for the device. Such as setting the secondary | |
| 128 | −core start address and release the secondary core from holdoff and startup. | |
| 129 | − Required properties: | |
| 130 | − - compatible: Should contain a chip-specific compatible string, | |
| 131 | − Chip-specific strings are of the form "fsl,<chip>-dcfg", | |
| 132 | − The following <chip>s are known to be supported: | |
| 133 | − ls1012a, ls1021a, ls1043a, ls1046a, ls2080a. | |
| 134 | − | |
| 135 | − - reg : should contain base address and length of DCFG memory-mapped registers | |
| 136 | − | |
| 137 | −Example: | |
| 138 | − dcfg: dcfg@1ee0000 { | |
| 139 | − compatible = "fsl,ls1021a-dcfg"; | |
| 140 | − reg = <0x0 0x1ee0000 0x0 0x10000>; | |
| 141 | − }; | |
| 142 | − | |
| 143 | 148 | Freescale ARMv8 based Layerscape SoC family Device Tree Bindings |
| 144 | 149 | ---------------------------------------------------------------- |
| 145 | 150 | |
| @@ -8,6 +8,14 @@ HiKey960 Board · 7 unmodified lines | ||
| 8 | 8 | Required root node properties: |
| 9 | 9 | - compatible = "hisilicon,hi3660-hikey960", "hisilicon,hi3660"; |
| 10 | 10 | |
| 11 | +Hi3670 SoC | |
| 12 | +Required root node properties: | |
| 13 | + - compatible = "hisilicon,hi3670"; | |
| 14 | + | |
| 15 | +HiKey970 Board | |
| 16 | +Required root node properties: | |
| 17 | + - compatible = "hisilicon,hi3670-hikey970", "hisilicon,hi3670"; | |
| 18 | + | |
| 11 | 19 | Hi3798cv200 SoC |
| 12 | 20 | Required root node properties: |
| 13 | 21 | - compatible = "hisilicon,hi3798cv200"; |
| @@ -45,11 +45,15 @@ Optional Properties: · 44 unmodified lines | ||
| 45 | 45 | debug_messages - Map the Debug message region |
| 46 | 46 | - reg: register space corresponding to the debug_messages |
| 47 | 47 | - ti,system-reboot-controller: If system reboot can be triggered by SoC reboot |
| 48 | +- ti,host-id: Integer value corresponding to the host ID assigned by Firmware | |
| 49 | + for identification of host processing entities such as virtual | |
| 50 | + machines | |
| 48 | 51 | |
| 49 | 52 | Example (K2G): |
| 50 | 53 | ------------- |
| 51 | 54 | pmmc: pmmc { |
| 52 | 55 | compatible = "ti,k2g-sci"; |
| 56 | + ti,host-id = <2>; | |
| 53 | 57 | mbox-names = "rx", "tx"; |
| 54 | 58 | mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>, |
| 55 | 59 | <&msgmgr &msgmgr_proxy_pmmc_tx>; |
| @@ -10,6 +10,7 @@ Required Properties: · 9 unmodified lines | ||
| 10 | 10 | - "mediatek,mt2712-apmixedsys", "syscon" |
| 11 | 11 | - "mediatek,mt6797-apmixedsys" |
| 12 | 12 | - "mediatek,mt7622-apmixedsys" |
| 13 | + - "mediatek,mt7623-apmixedsys", "mediatek,mt2701-apmixedsys" | |
| 13 | 14 | - "mediatek,mt8135-apmixedsys" |
| 14 | 15 | - "mediatek,mt8173-apmixedsys" |
| 15 | 16 | - #clock-cells: Must be 1 |
| @@ -8,6 +8,7 @@ Required Properties: · 7 unmodified lines | ||
| 8 | 8 | - compatible: Should be one of: |
| 9 | 9 | - "mediatek,mt2701-audsys", "syscon" |
| 10 | 10 | - "mediatek,mt7622-audsys", "syscon" |
| 11 | + - "mediatek,mt7623-audsys", "mediatek,mt2701-audsys", "syscon" | |
| 11 | 12 | - #clock-cells: Must be 1 |
| 12 | 13 | |
| 13 | 14 | The AUDSYS controller uses the common clk binding from |
| @@ -8,6 +8,7 @@ Required Properties: · 7 unmodified lines | ||
| 8 | 8 | - compatible: Should be: |
| 9 | 9 | - "mediatek,mt2701-bdpsys", "syscon" |
| 10 | 10 | - "mediatek,mt2712-bdpsys", "syscon" |
| 11 | + - "mediatek,mt7623-bdpsys", "mediatek,mt2701-bdpsys", "syscon" | |
| 11 | 12 | - #clock-cells: Must be 1 |
| 12 | 13 | |
| 13 | 14 | The bdpsys controller uses the common clk binding from |
| @@ -8,6 +8,7 @@ Required Properties: · 7 unmodified lines | ||
| 8 | 8 | - compatible: Should be: |
| 9 | 9 | - "mediatek,mt2701-ethsys", "syscon" |
| 10 | 10 | - "mediatek,mt7622-ethsys", "syscon" |
| 11 | + - "mediatek,mt7623-ethsys", "mediatek,mt2701-ethsys", "syscon" | |
| 11 | 12 | - #clock-cells: Must be 1 |
| 12 | 13 | - #reset-cells: Must be 1 |
| 13 | 14 | |
| @@ -9,6 +9,7 @@ Required Properties: · 8 unmodified lines | ||
| 9 | 9 | - compatible: Should be: |
| 10 | 10 | - "mediatek,mt2701-hifsys", "syscon" |
| 11 | 11 | - "mediatek,mt7622-hifsys", "syscon" |
| 12 | + - "mediatek,mt7623-hifsys", "mediatek,mt2701-hifsys", "syscon" | |
| 12 | 13 | - #clock-cells: Must be 1 |
| 13 | 14 | |
| 14 | 15 | The hifsys controller uses the common clk binding from |
| @@ -9,6 +9,7 @@ Required Properties: · 8 unmodified lines | ||
| 9 | 9 | - "mediatek,mt2701-imgsys", "syscon" |
| 10 | 10 | - "mediatek,mt2712-imgsys", "syscon" |
| 11 | 11 | - "mediatek,mt6797-imgsys", "syscon" |
| 12 | + - "mediatek,mt7623-imgsys", "mediatek,mt2701-imgsys", "syscon" | |
| 12 | 13 | - "mediatek,mt8173-imgsys", "syscon" |
| 13 | 14 | - #clock-cells: Must be 1 |
| 14 | 15 | |
| @@ -11,6 +11,7 @@ Required Properties: · 10 unmodified lines | ||
| 11 | 11 | - "mediatek,mt2712-infracfg", "syscon" |
| 12 | 12 | - "mediatek,mt6797-infracfg", "syscon" |
| 13 | 13 | - "mediatek,mt7622-infracfg", "syscon" |
| 14 | + - "mediatek,mt7623-infracfg", "mediatek,mt2701-infracfg", "syscon" | |
| 14 | 15 | - "mediatek,mt8135-infracfg", "syscon" |
| 15 | 16 | - "mediatek,mt8173-infracfg", "syscon" |
| 16 | 17 | - #clock-cells: Must be 1 |
| @@ -9,6 +9,7 @@ Required Properties: · 8 unmodified lines | ||
| 9 | 9 | - "mediatek,mt2701-mmsys", "syscon" |
| 10 | 10 | - "mediatek,mt2712-mmsys", "syscon" |
| 11 | 11 | - "mediatek,mt6797-mmsys", "syscon" |
| 12 | + - "mediatek,mt7623-mmsys", "mediatek,mt2701-mmsys", "syscon" | |
| 12 | 13 | - "mediatek,mt8173-mmsys", "syscon" |
| 13 | 14 | - #clock-cells: Must be 1 |
| 14 | 15 | |
| @@ -10,6 +10,7 @@ Required Properties: · 9 unmodified lines | ||
| 10 | 10 | - "mediatek,mt2701-pericfg", "syscon" |
| 11 | 11 | - "mediatek,mt2712-pericfg", "syscon" |
| 12 | 12 | - "mediatek,mt7622-pericfg", "syscon" |
| 13 | + - "mediatek,mt7623-pericfg", "mediatek,mt2701-pericfg", "syscon" | |
| 13 | 14 | - "mediatek,mt8135-pericfg", "syscon" |
| 14 | 15 | - "mediatek,mt8173-pericfg", "syscon" |
| 15 | 16 | - #clock-cells: Must be 1 |
| @@ -10,6 +10,7 @@ Required Properties: · 9 unmodified lines | ||
| 10 | 10 | - "mediatek,mt2712-topckgen", "syscon" |
| 11 | 11 | - "mediatek,mt6797-topckgen" |
| 12 | 12 | - "mediatek,mt7622-topckgen" |
| 13 | + - "mediatek,mt7623-topckgen", "mediatek,mt2701-topckgen" | |
| 13 | 14 | - "mediatek,mt8135-topckgen" |
| 14 | 15 | - "mediatek,mt8173-topckgen" |
| 15 | 16 | - #clock-cells: Must be 1 |
| @@ -9,6 +9,7 @@ Required Properties: · 8 unmodified lines | ||
| 9 | 9 | - "mediatek,mt2701-vdecsys", "syscon" |
| 10 | 10 | - "mediatek,mt2712-vdecsys", "syscon" |
| 11 | 11 | - "mediatek,mt6797-vdecsys", "syscon" |
| 12 | + - "mediatek,mt7623-vdecsys", "mediatek,mt2701-vdecsys", "syscon" | |
| 12 | 13 | - "mediatek,mt8173-vdecsys", "syscon" |
| 13 | 14 | - #clock-cells: Must be 1 |
| 14 | 15 | |
| @@ -21,10 +21,29 @@ PROPERTIES · 20 unmodified lines | ||
| 21 | 21 | the register region. An optional second element specifies |
| 22 | 22 | the base address and size of the alias register region. |
| 23 | 23 | |
| 24 | +- clocks: | |
| 25 | + Usage: required | |
| 26 | + Value type: <prop-encoded-array> | |
| 27 | + Definition: reference to the pll parents. | |
| 28 | + | |
| 29 | +- clock-names: | |
| 30 | + Usage: required | |
| 31 | + Value type: <stringlist> | |
| 32 | + Definition: must be "pll8_vote", "pxo". | |
| 33 | + | |
| 34 | +- clock-output-names: | |
| 35 | + Usage: optional | |
| 36 | + Value type: <string> | |
| 37 | + Definition: Name of the output clock. Typically acpuX_aux where X is a | |
| 38 | + CPU number starting at 0. | |
| 39 | + | |
| 24 | 40 | Example: |
| 25 | 41 | |
| 26 | 42 | clock-controller@2088000 { |
| 27 | 43 | compatible = "qcom,kpss-acc-v2"; |
| 28 | 44 | reg = <0x02088000 0x1000>, |
| 29 | 45 | <0x02008000 0x1000>; |
| 46 | + clocks = <&gcc PLL8_VOTE>, <&gcc PXO_SRC>; | |
| 47 | + clock-names = "pll8_vote", "pxo"; | |
| 48 | + clock-output-names = "acpu0_aux"; | |
| 30 | 49 | }; |
| @@ -0,0 +1,44 @@ | ||
| 1 | +Krait Processor Sub-system (KPSS) Global Clock Controller (GCC) | |
| 2 | + | |
| 3 | +PROPERTIES | |
| 4 | + | |
| 5 | +- compatible: | |
| 6 | + Usage: required | |
| 7 | + Value type: <string> | |
| 8 | + Definition: should be one of the following. The generic compatible | |
| 9 | + "qcom,kpss-gcc" should also be included. | |
| 10 | + "qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc" | |
| 11 | + "qcom,kpss-gcc-apq8064", "qcom,kpss-gcc" | |
| 12 | + "qcom,kpss-gcc-msm8974", "qcom,kpss-gcc" | |
| 13 | + "qcom,kpss-gcc-msm8960", "qcom,kpss-gcc" | |
| 14 | + | |
| 15 | +- reg: | |
| 16 | + Usage: required | |
| 17 | + Value type: <prop-encoded-array> | |
| 18 | + Definition: base address and size of the register region | |
| 19 | + | |
| 20 | +- clocks: | |
| 21 | + Usage: required | |
| 22 | + Value type: <prop-encoded-array> | |
| 23 | + Definition: reference to the pll parents. | |
| 24 | + | |
| 25 | +- clock-names: | |
| 26 | + Usage: required | |
| 27 | + Value type: <stringlist> | |
| 28 | + Definition: must be "pll8_vote", "pxo". | |
| 29 | + | |
| 30 | +- clock-output-names: | |
| 31 | + Usage: required | |
| 32 | + Value type: <string> | |
| 33 | + Definition: Name of the output clock. Typically acpu_l2_aux indicating | |
| 34 | + an L2 cache auxiliary clock. | |
| 35 | + | |
| 36 | +Example: | |
| 37 | + | |
| 38 | + l2cc: clock-controller@2011000 { | |
| 39 | + compatible = "qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc"; | |
| 40 | + reg = <0x2011000 0x1000>; | |
| 41 | + clocks = <&gcc PLL8_VOTE>, <&gcc PXO_SRC>; | |
| 42 | + clock-names = "pll8_vote", "pxo"; | |
| 43 | + clock-output-names = "acpu_l2_aux"; | |
| 44 | + }; | |
| @@ -16,11 +16,26 @@ Properties: · 15 unmodified lines | ||
| 16 | 16 | - reg: |
| 17 | 17 | Usage: required |
| 18 | 18 | Value Type: <prop-encoded-array> |
| 19 | − Definition: Start address and the the size of the register region. | |
| 19 | + Definition: The first element specifies the llcc base start address and | |
| 20 | + the size of the register region. The second element specifies | |
| 21 | + the llcc broadcast base address and size of the register region. | |
| 22 | + | |
| 23 | +- reg-names: | |
| 24 | + Usage: required | |
| 25 | + Value Type: <stringlist> | |
| 26 | + Definition: Register region names. Must be "llcc_base", "llcc_broadcast_base". | |
| 27 | + | |
| 28 | +- interrupts: | |
| 29 | + Usage: required | |
| 30 | + Definition: The interrupt is associated with the llcc edac device. | |
| 31 | + It's used for llcc cache single and double bit error detection | |
| 32 | + and reporting. | |
| 20 | 33 | |
| 21 | 34 | Example: |
| 22 | 35 | |
| 23 | 36 | cache-controller@1100000 { |
| 24 | 37 | compatible = "qcom,sdm845-llcc"; |
| 25 | − reg = <0x1100000 0x250000>; | |
| 38 | + reg = <0x1100000 0x200000>, <0x1300000 0x50000> ; | |
| 39 | + reg-names = "llcc_base", "llcc_broadcast_base"; | |
| 40 | + interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>; | |
| 26 | 41 | }; |
| @@ -5,6 +5,10 @@ Rockchip platforms device tree bindings · 4 unmodified lines | ||
| 5 | 5 | Required root node properties: |
| 6 | 6 | - compatible = "vamrs,ficus", "rockchip,rk3399"; |
| 7 | 7 | |
| 8 | +- 96boards RK3399 Rock960 (ROCK960 Consumer Edition) | |
| 9 | + Required root node properties: | |
| 10 | + - compatible = "vamrs,rock960", "rockchip,rk3399"; | |
| 11 | + | |
| 8 | 12 | - Amarula Vyasa RK3288 board |
| 9 | 13 | Required root node properties: |
| 10 | 14 | - compatible = "amarula,vyasa-rk3288", "rockchip,rk3288"; |
| @@ -13,6 +17,10 @@ Rockchip platforms device tree bindings · 2 unmodified lines | ||
| 13 | 17 | Required root node properties: |
| 14 | 18 | - compatible = "asus,rk3288-tinker", "rockchip,rk3288"; |
| 15 | 19 | |
| 20 | +- Asus Tinker board S | |
| 21 | + Required root node properties: | |
| 22 | + - compatible = "asus,rk3288-tinker-s", "rockchip,rk3288"; | |
| 23 | + | |
| 16 | 24 | - Kylin RK3036 board: |
| 17 | 25 | Required root node properties: |
| 18 | 26 | - compatible = "rockchip,kylin-rk3036", "rockchip,rk3036"; |
| @@ -59,6 +67,10 @@ Rockchip platforms device tree bindings · 40 unmodified lines | ||
| 59 | 67 | Required root node properties: |
| 60 | 68 | - compatible = "firefly,roc-rk3328-cc", "rockchip,rk3328"; |
| 61 | 69 | |
| 70 | +- Firefly ROC-RK3399-PC board: | |
| 71 | + Required root node properties: | |
| 72 | + - compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399"; | |
| 73 | + | |
| 62 | 74 | - ChipSPARK PopMetal-RK3288 board: |
| 63 | 75 | Required root node properties: |
| 64 | 76 | - compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288"; |
| @@ -160,6 +172,10 @@ Rockchip platforms device tree bindings · 95 unmodified lines | ||
| 160 | 172 | Required root node properties: |
| 161 | 173 | - compatible = "pine64,rock64", "rockchip,rk3328"; |
| 162 | 174 | |
| 175 | +- Pine64 RockPro64 board: | |
| 176 | + Required root node properties: | |
| 177 | + - compatible = "pine64,rockpro64", "rockchip,rk3399"; | |
| 178 | + | |
| 163 | 179 | - Rockchip PX3 Evaluation board: |
| 164 | 180 | Required root node properties: |
| 165 | 181 | - compatible = "rockchip,px3-evb", "rockchip,px3", "rockchip,rk3188"; |
| @@ -168,6 +184,10 @@ Rockchip platforms device tree bindings · 2 unmodified lines | ||
| 168 | 184 | Required root node properties: |
| 169 | 185 | - compatible = "rockchip,px5-evb", "rockchip,px5", "rockchip,rk3368"; |
| 170 | 186 | |
| 187 | +- Rockchip PX30 Evaluation board: | |
| 188 | + Required root node properties: | |
| 189 | + - compatible = "rockchip,px30-evb", "rockchip,px30"; | |
| 190 | + | |
| 171 | 191 | - Rockchip RV1108 Evaluation board |
| 172 | 192 | Required root node properties: |
| 173 | 193 | - compatible = "rockchip,rv1108-evb", "rockchip,rv1108"; |
| @@ -22,7 +22,7 @@ References: · 21 unmodified lines | ||
| 22 | 22 | |
| 23 | 23 | Example: |
| 24 | 24 | |
| 25 | −scu@a04100000 { | |
| 25 | +scu@a0410000 { | |
| 26 | 26 | compatible = "arm,cortex-a9-scu"; |
| 27 | 27 | reg = <0xa0410000 0x100>; |
| 28 | 28 | }; |
| @@ -32,7 +32,8 @@ describe the view of Secure world using the standard bindings. These · 31 unmodified lines | ||
| 32 | 32 | secure- bindings only need to be used where both the Secure and Normal |
| 33 | 33 | world views need to be described in a single device tree. |
| 34 | 34 | |
| 35 | −Valid Secure world properties: | |
| 35 | +Valid Secure world properties | |
| 36 | +----------------------------- | |
| 36 | 37 | |
| 37 | 38 | - secure-status : specifies whether the device is present and usable |
| 38 | 39 | in the secure world. The combination of this with "status" allows |
| @@ -51,3 +52,19 @@ Valid Secure world properties: · 12 unmodified lines | ||
| 51 | 52 | status = "disabled"; secure-status = "okay"; /* S-only */ |
| 52 | 53 | status = "disabled"; /* disabled in both */ |
| 53 | 54 | status = "disabled"; secure-status = "disabled"; /* disabled in both */ |
| 55 | + | |
| 56 | +The secure-chosen node | |
| 57 | +---------------------- | |
| 58 | + | |
| 59 | +Similar to the /chosen node which serves as a place for passing data | |
| 60 | +between firmware and the operating system, the /secure-chosen node may | |
| 61 | +be used to pass data to the Secure OS. Only the properties defined | |
| 62 | +below may appear in the /secure-chosen node. | |
| 63 | + | |
| 64 | +- stdout-path : specifies the device to be used by the Secure OS for | |
| 65 | + its console output. The syntax is the same as for /chosen/stdout-path. | |
| 66 | + If the /secure-chosen node exists but the stdout-path property is not | |
| 67 | + present, the Secure OS should not perform any console output. If | |
| 68 | + /secure-chosen does not exist, the Secure OS should use the value of | |
| 69 | + /chosen/stdout-path instead (that is, use the same device as the | |
| 70 | + Normal world OS). | |
| @@ -7,6 +7,8 @@ SoCs: · 6 unmodified lines | ||
| 7 | 7 | compatible = "renesas,emev2" |
| 8 | 8 | - RZ/A1H (R7S72100) |
| 9 | 9 | compatible = "renesas,r7s72100" |
| 10 | + - RZ/A2 (R7S9210) | |
| 11 | + compatible = "renesas,r7s9210" | |
| 10 | 12 | - SH-Mobile AG5 (R8A73A00/SH73A0) |
| 11 | 13 | compatible = "renesas,sh73a0" |
| 12 | 14 | - R-Mobile APE6 (R8A73A40) |
| @@ -23,6 +25,10 @@ SoCs: · 10 unmodified lines | ||
| 23 | 25 | compatible = "renesas,r8a7745" |
| 24 | 26 | - RZ/G1C (R8A77470) |
| 25 | 27 | compatible = "renesas,r8a77470" |
| 28 | + - RZ/G2M (R8A774A1) | |
| 29 | + compatible = "renesas,r8a774a1" | |
| 30 | + - RZ/G2E (R8A774C0) | |
| 31 | + compatible = "renesas,r8a774c0" | |
| 26 | 32 | - R-Car M1A (R8A77781) |
| 27 | 33 | compatible = "renesas,r8a7778" |
| 28 | 34 | - R-Car H1 (R8A77790) |
| @@ -107,6 +113,8 @@ Boards: · 78 unmodified lines | ||
| 107 | 113 | compatible = "renesas,lager", "renesas,r8a7790" |
| 108 | 114 | - M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0)) |
| 109 | 115 | compatible = "renesas,m3ulcb", "renesas,r8a7796" |
| 116 | + - M3NULCB (R-Car Starter Kit Pro, RTP0RC77965SKBX010SA00 (M3-N ES1.1)) | |
| 117 | + compatible = "renesas,m3nulcb", "renesas,r8a77965" | |
| 110 | 118 | - Marzen (R0P7779A00010S) |
| 111 | 119 | compatible = "renesas,marzen", "renesas,r8a7779" |
| 112 | 120 | - Porter (M2-LCDP) |
| @@ -143,12 +151,12 @@ Boards: · 30 unmodified lines | ||
| 143 | 151 | compatible = "renesas,wheat", "renesas,r8a7792" |
| 144 | 152 | |
| 145 | 153 | |
| 146 | −Most Renesas ARM SoCs have a Product Register that allows to retrieve SoC | |
| 147 | −product and revision information. If present, a device node for this register | |
| 148 | −should be added. | |
| 154 | +Most Renesas ARM SoCs have a Product Register or Boundary Scan ID Register that | |
| 155 | +allows to retrieve SoC product and revision information. If present, a device | |
| 156 | +node for this register should be added. | |
| 149 | 157 | |
| 150 | 158 | Required properties: |
| 151 | − - compatible: Must be "renesas,prr". | |
| 159 | + - compatible: Must be "renesas,prr" or "renesas,bsid" | |
| 152 | 160 | - reg: Base address and length of the register block. |
| 153 | 161 | |
| 154 | 162 | |
| @@ -1,4 +1,9 @@ | ||
| 1 | −Marvell Berlin SoC Family Device Tree Bindings | |
| 1 | +Synaptics SoC Device Tree Bindings | |
| 2 | + | |
| 3 | +According to https://www.synaptics.com/company/news/conexant-marvell | |
| 4 | +Synaptics has acquired the Multimedia Solutions Business of Marvell, so | |
| 5 | +berlin SoCs are now Synaptics' SoCs now. | |
| 6 | + | |
| 2 | 7 | --------------------------------------------------------------- |
| 3 | 8 | |
| 4 | 9 | Work in progress statement: |
| @@ -13,6 +18,10 @@ stable binding/ABI. · 8 unmodified lines | ||
| 13 | 18 | |
| 14 | 19 | --------------------------------------------------------------- |
| 15 | 20 | |
| 21 | +Boards with the Synaptics AS370 SoC shall have the following properties: | |
| 22 | + Required root node property: | |
| 23 | + compatible: "syna,as370" | |
| 24 | + | |
| 16 | 25 | Boards with a SoC of the Marvell Berlin family, e.g. Armada 1500 |
| 17 | 26 | shall have the following properties: |
| 18 | 27 | |
| @@ -47,12 +47,17 @@ board-specific compatible values: · 46 unmodified lines | ||
| 47 | 47 | nvidia,ventana |
| 48 | 48 | toradex,apalis_t30 |
| 49 | 49 | toradex,apalis_t30-eval |
| 50 | + toradex,apalis_t30-v1.1 | |
| 51 | + toradex,apalis_t30-v1.1-eval | |
| 50 | 52 | toradex,apalis-tk1 |
| 51 | 53 | toradex,apalis-tk1-eval |
| 52 | − toradex,colibri_t20-512 | |
| 54 | + toradex,apalis-tk1-v1.2 | |
| 55 | + toradex,apalis-tk1-v1.2-eval | |
| 56 | + toradex,colibri_t20 | |
| 57 | + toradex,colibri_t20-eval-v3 | |
| 58 | + toradex,colibri_t20-iris | |
| 53 | 59 | toradex,colibri_t30 |
| 54 | 60 | toradex,colibri_t30-eval-v3 |
| 55 | − toradex,iris | |
| 56 | 61 | |
| 57 | 62 | Trusted Foundations |
| 58 | 63 | ------------------------------------------- |
| @@ -34,3 +34,96 @@ Board DTS: · 33 unmodified lines | ||
| 34 | 34 | pmc@c360000 { |
| 35 | 35 | nvidia,invert-interrupt; |
| 36 | 36 | }; |
| 37 | + | |
| 38 | +== Pad Control == | |
| 39 | + | |
| 40 | +On Tegra SoCs a pad is a set of pins which are configured as a group. | |
| 41 | +The pin grouping is a fixed attribute of the hardware. The PMC can be | |
| 42 | +used to set pad power state and signaling voltage. A pad can be either | |
| 43 | +in active or power down mode. The support for power state and signaling | |
| 44 | +voltage configuration varies depending on the pad in question. 3.3 V and | |
| 45 | +1.8 V signaling voltages are supported on pins where software | |
| 46 | +controllable signaling voltage switching is available. | |
| 47 | + | |
| 48 | +Pad configurations are described with pin configuration nodes which | |
| 49 | +are placed under the pmc node and they are referred to by the pinctrl | |
| 50 | +client properties. For more information see | |
| 51 | +Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt. | |
| 52 | + | |
| 53 | +The following pads are present on Tegra186: | |
| 54 | +csia csib dsi mipi-bias | |
| 55 | +pex-clk-bias pex-clk3 pex-clk2 pex-clk1 | |
| 56 | +usb0 usb1 usb2 usb-bias | |
| 57 | +uart audio hsic dbg | |
| 58 | +hdmi-dp0 hdmi-dp1 pex-cntrl sdmmc2-hv | |
| 59 | +sdmmc4 cam dsib dsic | |
| 60 | +dsid csic csid csie | |
| 61 | +dsif spi ufs dmic-hv | |
| 62 | +edp sdmmc1-hv sdmmc3-hv conn | |
| 63 | +audio-hv ao-hv | |
| 64 | + | |
| 65 | +Required pin configuration properties: | |
| 66 | + - pins: A list of strings, each of which contains the name of a pad | |
| 67 | + to be configured. | |
| 68 | + | |
| 69 | +Optional pin configuration properties: | |
| 70 | + - low-power-enable: Configure the pad into power down mode | |
| 71 | + - low-power-disable: Configure the pad into active mode | |
| 72 | + - power-source: Must contain either TEGRA_IO_PAD_VOLTAGE_1V8 or | |
| 73 | + TEGRA_IO_PAD_VOLTAGE_3V3 to select between signaling voltages. | |
| 74 | + The values are defined in | |
| 75 | + include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h. | |
| 76 | + | |
| 77 | +Note: The power state can be configured on all of the above pads except | |
| 78 | + for ao-hv. Following pads have software configurable signaling | |
| 79 | + voltages: sdmmc2-hv, dmic-hv, sdmmc1-hv, sdmmc3-hv, audio-hv, | |
| 80 | + ao-hv. | |
| 81 | + | |
| 82 | +Pad configuration state example: | |
| 83 | + pmc: pmc@7000e400 { | |
| 84 | + compatible = "nvidia,tegra186-pmc"; | |
| 85 | + reg = <0 0x0c360000 0 0x10000>, | |
| 86 | + <0 0x0c370000 0 0x10000>, | |
| 87 | + <0 0x0c380000 0 0x10000>, | |
| 88 | + <0 0x0c390000 0 0x10000>; | |
| 89 | + reg-names = "pmc", "wake", "aotag", "scratch"; | |
| 90 | + | |
| 91 | + ... | |
| 92 | + | |
| 93 | + sdmmc1_3v3: sdmmc1-3v3 { | |
| 94 | + pins = "sdmmc1-hv"; | |
| 95 | + power-source = <TEGRA_IO_PAD_VOLTAGE_3V3>; | |
| 96 | + }; | |
| 97 | + | |
| 98 | + sdmmc1_1v8: sdmmc1-1v8 { | |
| 99 | + pins = "sdmmc1-hv"; | |
| 100 | + power-source = <TEGRA_IO_PAD_VOLTAGE_1V8>; | |
| 101 | + }; | |
| 102 | + | |
| 103 | + hdmi_off: hdmi-off { | |
| 104 | + pins = "hdmi"; | |
| 105 | + low-power-enable; | |
| 106 | + } | |
| 107 | + | |
| 108 | + hdmi_on: hdmi-on { | |
| 109 | + pins = "hdmi"; | |
| 110 | + low-power-disable; | |
| 111 | + } | |
| 112 | + }; | |
| 113 | + | |
| 114 | +Pinctrl client example: | |
| 115 | + sdmmc1: sdhci@3400000 { | |
| 116 | + ... | |
| 117 | + pinctrl-names = "sdmmc-3v3", "sdmmc-1v8"; | |
| 118 | + pinctrl-0 = <&sdmmc1_3v3>; | |
| 119 | + pinctrl-1 = <&sdmmc1_1v8>; | |
| 120 | + }; | |
| 121 | + | |
| 122 | + ... | |
| 123 | + | |
| 124 | + sor0: sor@15540000 { | |
| 125 | + ... | |
| 126 | + pinctrl-0 = <&hdmi_off>; | |
| 127 | + pinctrl-1 = <&hdmi_on>; | |
| 128 | + pinctrl-names = "hdmi-on", "hdmi-off"; | |
| 129 | + }; | |
| @@ -195,3 +195,106 @@ Example: · 194 unmodified lines | ||
| 195 | 195 | power-domains = <&pd_audio>; |
| 196 | 196 | ... |
| 197 | 197 | }; |
| 198 | + | |
| 199 | +== Pad Control == | |
| 200 | + | |
| 201 | +On Tegra SoCs a pad is a set of pins which are configured as a group. | |
| 202 | +The pin grouping is a fixed attribute of the hardware. The PMC can be | |
| 203 | +used to set pad power state and signaling voltage. A pad can be either | |
| 204 | +in active or power down mode. The support for power state and signaling | |
| 205 | +voltage configuration varies depending on the pad in question. 3.3 V and | |
| 206 | +1.8 V signaling voltages are supported on pins where software | |
| 207 | +controllable signaling voltage switching is available. | |
| 208 | + | |
| 209 | +The pad configuration state nodes are placed under the pmc node and they | |
| 210 | +are referred to by the pinctrl client properties. For more information | |
| 211 | +see Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt. | |
| 212 | +The pad name should be used as the value of the pins property in pin | |
| 213 | +configuration nodes. | |
| 214 | + | |
| 215 | +The following pads are present on Tegra124 and Tegra132: | |
| 216 | +audio bb cam comp | |
| 217 | +csia csb cse dsi | |
| 218 | +dsib dsic dsid hdmi | |
| 219 | +hsic hv lvds mipi-bias | |
| 220 | +nand pex-bias pex-clk1 pex-clk2 | |
| 221 | +pex-cntrl sdmmc1 sdmmc3 sdmmc4 | |
| 222 | +sys_ddc uart usb0 usb1 | |
| 223 | +usb2 usb_bias | |
| 224 | + | |
| 225 | +The following pads are present on Tegra210: | |
| 226 | +audio audio-hv cam csia | |
| 227 | +csib csic csid csie | |
| 228 | +csif dbg debug-nonao dmic | |
| 229 | +dp dsi dsib dsic | |
| 230 | +dsid emmc emmc2 gpio | |
| 231 | +hdmi hsic lvds mipi-bias | |
| 232 | +pex-bias pex-clk1 pex-clk2 pex-cntrl | |
| 233 | +sdmmc1 sdmmc3 spi spi-hv | |
| 234 | +uart usb0 usb1 usb2 | |
| 235 | +usb3 usb-bias | |
| 236 | + | |
| 237 | +Required pin configuration properties: | |
| 238 | + - pins: Must contain name of the pad(s) to be configured. | |
| 239 | + | |
| 240 | +Optional pin configuration properties: | |
| 241 | + - low-power-enable: Configure the pad into power down mode | |
| 242 | + - low-power-disable: Configure the pad into active mode | |
| 243 | + - power-source: Must contain either TEGRA_IO_PAD_VOLTAGE_1V8 | |
| 244 | + or TEGRA_IO_PAD_VOLTAGE_3V3 to select between signaling voltages. | |
| 245 | + The values are defined in | |
| 246 | + include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h. | |
| 247 | + | |
| 248 | +Note: The power state can be configured on all of the Tegra124 and | |
| 249 | + Tegra132 pads. None of the Tegra124 or Tegra132 pads support | |
| 250 | + signaling voltage switching. | |
| 251 | + | |
| 252 | +Note: All of the listed Tegra210 pads except pex-cntrl support power | |
| 253 | + state configuration. Signaling voltage switching is supported on | |
| 254 | + following Tegra210 pads: audio, audio-hv, cam, dbg, dmic, gpio, | |
| 255 | + pex-cntrl, sdmmc1, sdmmc3, spi, spi-hv, and uart. | |
| 256 | + | |
| 257 | +Pad configuration state example: | |
| 258 | + pmc: pmc@7000e400 { | |
| 259 | + compatible = "nvidia,tegra210-pmc"; | |
| 260 | + reg = <0x0 0x7000e400 0x0 0x400>; | |
| 261 | + clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>; | |
| 262 | + clock-names = "pclk", "clk32k_in"; | |
| 263 | + | |
| 264 | + ... | |
| 265 | + | |
| 266 | + sdmmc1_3v3: sdmmc1-3v3 { | |
| 267 | + pins = "sdmmc1"; | |
| 268 | + power-source = <TEGRA_IO_PAD_VOLTAGE_3V3>; | |
| 269 | + }; | |
| 270 | + | |
| 271 | + sdmmc1_1v8: sdmmc1-1v8 { | |
| 272 | + pins = "sdmmc1"; | |
| 273 | + power-source = <TEGRA_IO_PAD_VOLTAGE_1V8>; | |
| 274 | + }; | |
| 275 | + | |
| 276 | + hdmi_off: hdmi-off { | |
| 277 | + pins = "hdmi"; | |
| 278 | + low-power-enable; | |
| 279 | + } | |
| 280 | + | |
| 281 | + hdmi_on: hdmi-on { | |
| 282 | + pins = "hdmi"; | |
| 283 | + low-power-disable; | |
| 284 | + } | |
| 285 | + }; | |
| 286 | + | |
| 287 | +Pinctrl client example: | |
| 288 | + sdmmc1: sdhci@700b0000 { | |
| 289 | + ... | |
| 290 | + pinctrl-names = "sdmmc-3v3", "sdmmc-1v8"; | |
| 291 | + pinctrl-0 = <&sdmmc1_3v3>; | |
| 292 | + pinctrl-1 = <&sdmmc1_1v8>; | |
| 293 | + }; | |
| 294 | + ... | |
| 295 | + sor@54540000 { | |
| 296 | + ... | |
| 297 | + pinctrl-0 = <&hdmi_off>; | |
| 298 | + pinctrl-1 = <&hdmi_on>; | |
| 299 | + pinctrl-names = "hdmi-on", "hdmi-off"; | |
| 300 | + }; | |
| @@ -60,7 +60,7 @@ Example: · 59 unmodified lines | ||
| 60 | 60 | <0xa0410100 0x100>; |
| 61 | 61 | }; |
| 62 | 62 | |
| 63 | − scu@a04100000 { | |
| 63 | + scu@a0410000 { | |
| 64 | 64 | compatible = "arm,cortex-a9-scu"; |
| 65 | 65 | reg = <0xa0410000 0x100>; |
| 66 | 66 | }; |
| @@ -0,0 +1,30 @@ | ||
| 1 | +ZTE sysctrl Registers | |
| 2 | + | |
| 3 | +Registers for 'zte,zx296702' SoC: | |
| 4 | + | |
| 5 | +System management required properties: | |
| 6 | + - compatible = "zte,sysctrl" | |
| 7 | + | |
| 8 | +Low power management required properties: | |
| 9 | + - compatible = "zte,zx296702-pcu" | |
| 10 | + | |
| 11 | +Bus matrix required properties: | |
| 12 | + - compatible = "zte,zx-bus-matrix" | |
| 13 | + | |
| 14 | + | |
| 15 | +Registers for 'zte,zx296718' SoC: | |
| 16 | + | |
| 17 | +System management required properties: | |
| 18 | + - compatible = "zte,zx296718-aon-sysctrl" | |
| 19 | + - compatible = "zte,zx296718-sysctrl" | |
| 20 | + | |
| 21 | +Example: | |
| 22 | +aon_sysctrl: aon-sysctrl@116000 { | |
| 23 | + compatible = "zte,zx296718-aon-sysctrl", "syscon"; | |
| 24 | + reg = <0x116000 0x1000>; | |
| 25 | +}; | |
| 26 | + | |
| 27 | +sysctrl: sysctrl@1463000 { | |
| 28 | + compatible = "zte,zx296718-sysctrl", "syscon"; | |
| 29 | + reg = <0x1463000 0x1000>; | |
| 30 | +}; | |
| @@ -1,20 +1,10 @@ | ||
| 1 | 1 | ZTE platforms device tree bindings |
| 2 | −--------------------------------------- | |
| 3 | 2 | |
| 3 | +--------------------------------------- | |
| 4 | 4 | - ZX296702 board: |
| 5 | 5 | Required root node properties: |
| 6 | 6 | - compatible = "zte,zx296702-ad1", "zte,zx296702" |
| 7 | 7 | |
| 8 | −System management required properties: | |
| 9 | − - compatible = "zte,sysctrl" | |
| 10 | − | |
| 11 | −Low power management required properties: | |
| 12 | − - compatible = "zte,zx296702-pcu" | |
| 13 | − | |
| 14 | −Bus matrix required properties: | |
| 15 | − - compatible = "zte,zx-bus-matrix" | |
| 16 | − | |
| 17 | − | |
| 18 | 8 | --------------------------------------- |
| 19 | 9 | - ZX296718 SoC: |
| 20 | 10 | Required root node properties: |
| @@ -22,18 +12,3 @@ Bus matrix required properties: · 1 unmodified line | ||
| 22 | 12 | |
| 23 | 13 | ZX296718 EVB board: |
| 24 | 14 | - "zte,zx296718-evb" |
| 25 | − | |
| 26 | −System management required properties: | |
| 27 | − - compatible = "zte,zx296718-aon-sysctrl" | |
| 28 | − - compatible = "zte,zx296718-sysctrl" | |
| 29 | − | |
| 30 | −Example: | |
| 31 | −aon_sysctrl: aon-sysctrl@116000 { | |
| 32 | − compatible = "zte,zx296718-aon-sysctrl", "syscon"; | |
| 33 | − reg = <0x116000 0x1000>; | |
| 34 | −}; | |
| 35 | − | |
| 36 | −sysctrl: sysctrl@1463000 { | |
| 37 | − compatible = "zte,zx296718-sysctrl", "syscon"; | |
| 38 | − reg = <0x1463000 0x1000>; | |
| 39 | −}; | |
| @@ -10,6 +10,7 @@ PHYs. · 9 unmodified lines | ||
| 10 | 10 | Required properties: |
| 11 | 11 | - compatible : compatible string, one of: |
| 12 | 12 | - "allwinner,sun4i-a10-ahci" |
| 13 | + - "allwinner,sun8i-r40-ahci" | |
| 13 | 14 | - "brcm,iproc-ahci" |
| 14 | 15 | - "hisilicon,hisi-ahci" |
| 15 | 16 | - "cavium,octeon-7130-ahci" |
| @@ -31,8 +32,10 @@ Optional properties: · 15 unmodified lines | ||
| 31 | 32 | - clocks : a list of phandle + clock specifier pairs |
| 32 | 33 | - resets : a list of phandle + reset specifier pairs |
| 33 | 34 | - target-supply : regulator for SATA target power |
| 35 | +- phy-supply : regulator for PHY power | |
| 34 | 36 | - phys : reference to the SATA PHY node |
| 35 | 37 | - phy-names : must be "sata-phy" |
| 38 | +- ahci-supply : regulator for AHCI controller | |
| 36 | 39 | - ports-implemented : Mask that indicates which ports that the HBA supports |
| 37 | 40 | are available for software to use. Useful if PORTS_IMPL |
| 38 | 41 | is not programmed by the BIOS, which is true with |
| @@ -42,12 +45,13 @@ Required properties when using sub-nodes: · 3 unmodified lines | ||
| 42 | 45 | - #address-cells : number of cells to encode an address |
| 43 | 46 | - #size-cells : number of cells representing the size of an address |
| 44 | 47 | |
| 48 | +For allwinner,sun8i-r40-ahci, the reset propertie must be present. | |
| 45 | 49 | |
| 46 | 50 | Sub-nodes required properties: |
| 47 | 51 | - reg : the port number |
| 48 | 52 | And at least one of the following properties: |
| 49 | 53 | - phys : reference to the SATA PHY node |
| 50 | −- target-supply : regulator for SATA target power | |
| 54 | +- target-supply : regulator for SATA target power | |
| 51 | 55 | |
| 52 | 56 | Examples: |
| 53 | 57 | sata@ffe08000 { |
| @@ -9,6 +9,7 @@ Required properties: · 8 unmodified lines | ||
| 9 | 9 | "brcm,bcm7445-ahci" |
| 10 | 10 | "brcm,bcm-nsp-ahci" |
| 11 | 11 | "brcm,sata3-ahci" |
| 12 | + "brcm,bcm63138-ahci" | |
| 12 | 13 | - reg : register mappings for AHCI and SATA_TOP_CTRL |
| 13 | 14 | - reg-names : "ahci" and "top-ctrl" |
| 14 | 15 | - interrupts : interrupt mapping for SATA IRQ |
| @@ -1,11 +1,14 @@ | ||
| 1 | −Device tree bindings for Allwinner A64 DE2 bus | |
| 1 | +Device tree bindings for Allwinner DE2/3 bus | |
| 2 | 2 | |
| 3 | 3 | The Allwinner A64 DE2 is on a special bus, which needs a SRAM region (SRAM C) |
| 4 | −to be claimed for enabling the access. | |
| 4 | +to be claimed for enabling the access. The DE3 on Allwinner H6 is at the same | |
| 5 | +situation, and the binding also applies. | |
| 5 | 6 | |
| 6 | 7 | Required properties: |
| 7 | 8 | |
| 8 | − - compatible: Should contain "allwinner,sun50i-a64-de2" | |
| 9 | + - compatible: Should be one of: | |
| 10 | + - "allwinner,sun50i-a64-de2" | |
| 11 | + - "allwinner,sun50i-h6-de3", "allwinner,sun50i-a64-de2" | |
| 9 | 12 | - reg: A resource specifier for the register space |
| 10 | 13 | - #address-cells: Must be set to 1 |
| 11 | 14 | - #size-cells: Must be set to 1 |
| @@ -13,6 +13,7 @@ Required Properties: · 12 unmodified lines | ||
| 13 | 13 | region. |
| 14 | 14 | - clocks: Reference to the parent clocks ("hosc", "losc") |
| 15 | 15 | - #clock-cells: should be 1. |
| 16 | +- #reset-cells: should be 1. | |
| 16 | 17 | |
| 17 | 18 | Each clock is assigned an identifier, and client nodes can use this identifier |
| 18 | 19 | to specify the clock which they consume. |
| @@ -36,6 +37,7 @@ Example: Clock Management Unit node: · 17 unmodified lines | ||
| 36 | 37 | reg = <0x0 0xe0160000 0x0 0x1000>; |
| 37 | 38 | clocks = <&hosc>, <&losc>; |
| 38 | 39 | #clock-cells = <1>; |
| 40 | + #reset-cells = <1>; | |
| 39 | 41 | }; |
| 40 | 42 | |
| 41 | 43 | Example: UART controller node that consumes clock generated by the clock |
| @@ -4,6 +4,8 @@ This binding uses the common clock binding[1]. · 3 unmodified lines | ||
| 4 | 4 | |
| 5 | 5 | [1] Documentation/devicetree/bindings/clock/clock-bindings.txt |
| 6 | 6 | |
| 7 | +Slow Clock controller: | |
| 8 | + | |
| 7 | 9 | Required properties: |
| 8 | 10 | - compatible : shall be one of the following: |
| 9 | 11 | "atmel,at91sam9x5-sckc" or |
| @@ -16,84 +18,6 @@ Required properties: · 6 unmodified lines | ||
| 16 | 18 | |
| 17 | 19 | "atmel,at91sam9x5-clk-slow-rc-osc": |
| 18 | 20 | at91 internal slow RC oscillator |
| 19 | − | |
| 20 | − "atmel,<chip>-pmc": | |
| 21 | − at91 PMC (Power Management Controller) | |
| 22 | − All at91 specific clocks (clocks defined below) must be child | |
| 23 | − node of the PMC node. | |
| 24 | − <chip> can be: at91rm9200, at91sam9260, at91sam9261, | |
| 25 | − at91sam9263, at91sam9g45, at91sam9n12, at91sam9rl, at91sam9x5, | |
| 26 | − sama5d2, sama5d3 or sama5d4. | |
| 27 | − | |
| 28 | − "atmel,at91sam9x5-clk-slow" (under sckc node) | |
| 29 | − or | |
| 30 | − "atmel,at91sam9260-clk-slow" (under pmc node): | |
| 31 | − at91 slow clk | |
| 32 | − | |
| 33 | − "atmel,at91rm9200-clk-main-osc" | |
| 34 | − "atmel,at91sam9x5-clk-main-rc-osc" | |
| 35 | − at91 main clk sources | |
| 36 | − | |
| 37 | − "atmel,at91sam9x5-clk-main" | |
| 38 | − "atmel,at91rm9200-clk-main": | |
| 39 | − at91 main clock | |
| 40 | − | |
| 41 | − "atmel,at91rm9200-clk-master" or | |
| 42 | − "atmel,at91sam9x5-clk-master": | |
| 43 | − at91 master clock | |
| 44 | − | |
| 45 | − "atmel,at91sam9x5-clk-peripheral" or | |
| 46 | − "atmel,at91rm9200-clk-peripheral": | |
| 47 | − at91 peripheral clocks | |
| 48 | − | |
| 49 | − "atmel,at91rm9200-clk-pll" or | |
| 50 | − "atmel,at91sam9g45-clk-pll" or | |
| 51 | − "atmel,at91sam9g20-clk-pllb" or | |
| 52 | − "atmel,sama5d3-clk-pll": | |
| 53 | − at91 pll clocks | |
| 54 | − | |
| 55 | − "atmel,at91sam9x5-clk-plldiv": | |
| 56 | − at91 plla divisor | |
| 57 | − | |
| 58 | − "atmel,at91rm9200-clk-programmable" or | |
| 59 | − "atmel,at91sam9g45-clk-programmable" or | |
| 60 | − "atmel,at91sam9x5-clk-programmable": | |
| 61 | − at91 programmable clocks | |
| 62 | − | |
| 63 | − "atmel,at91sam9x5-clk-smd": | |
| 64 | − at91 SMD (Soft Modem) clock | |
| 65 | − | |
| 66 | − "atmel,at91rm9200-clk-system": | |
| 67 | − at91 system clocks | |
| 68 | − | |
| 69 | − "atmel,at91rm9200-clk-usb" or | |
| 70 | − "atmel,at91sam9x5-clk-usb" or | |
| 71 | − "atmel,at91sam9n12-clk-usb": | |
| 72 | − at91 usb clock | |
| 73 | − | |
| 74 | − "atmel,at91sam9x5-clk-utmi": | |
| 75 | − at91 utmi clock | |
| 76 | − | |
| 77 | − "atmel,sama5d4-clk-h32mx": | |
| 78 | − at91 h32mx clock | |
| 79 | − | |
| 80 | − "atmel,sama5d2-clk-generated": | |
| 81 | − at91 generated clock | |
| 82 | − | |
| 83 | − "atmel,sama5d2-clk-audio-pll-frac": | |
| 84 | − at91 audio fractional pll | |
| 85 | − | |
| 86 | − "atmel,sama5d2-clk-audio-pll-pad": | |
| 87 | − at91 audio pll CLK_AUDIO output pin | |
| 88 | − | |
| 89 | − "atmel,sama5d2-clk-audio-pll-pmc" | |
| 90 | − at91 audio pll output on AUDIOPLLCLK that feeds the PMC | |
| 91 | − and can be used by peripheral clock or generic clock | |
| 92 | − | |
| 93 | − "atmel,sama5d2-clk-i2s-mux" (under pmc node): | |
| 94 | − at91 I2S clock source selection | |
| 95 | − | |
| 96 | −Required properties for SCKC node: | |
| 97 | 21 | - reg : defines the IO memory reserved for the SCKC. |
| 98 | 22 | - #size-cells : shall be 0 (reg is used to encode clk id). |
| 99 | 23 | - #address-cells : shall be 1 (reg is used to encode clk id). |
| @@ -109,428 +33,30 @@ For example: · 9 unmodified lines | ||
| 109 | 33 | /* put at91 slow clocks here */ |
| 110 | 34 | }; |
| 111 | 35 | |
| 36 | +Power Management Controller (PMC): | |
| 112 | 37 | |
| 113 | −Required properties for internal slow RC oscillator: | |
| 114 | −- #clock-cells : from common clock binding; shall be set to 0. | |
| 115 | −- clock-frequency : define the internal RC oscillator frequency. | |
| 116 | − | |
| 117 | −Optional properties: | |
| 118 | −- clock-accuracy : define the internal RC oscillator accuracy. | |
| 119 | − | |
| 120 | −For example: | |
| 121 | − slow_rc_osc: slow_rc_osc { | |
| 122 | − compatible = "atmel,at91sam9x5-clk-slow-rc-osc"; | |
| 123 | − clock-frequency = <32768>; | |
| 124 | − clock-accuracy = <50000000>; | |
| 125 | − }; | |
| 126 | − | |
| 127 | −Required properties for slow oscillator: | |
| 128 | −- #clock-cells : from common clock binding; shall be set to 0. | |
| 129 | −- clocks : shall encode the main osc source clk sources (see atmel datasheet). | |
| 38 | +Required properties: | |
| 39 | +- compatible : shall be "atmel,<chip>-pmc", "syscon": | |
| 40 | + <chip> can be: at91rm9200, at91sam9260, at91sam9261, | |
| 41 | + at91sam9263, at91sam9g45, at91sam9n12, at91sam9rl, at91sam9g15, | |
| 42 | + at91sam9g25, at91sam9g35, at91sam9x25, at91sam9x35, at91sam9x5, | |
| 43 | + sama5d2, sama5d3 or sama5d4. | |
| 44 | +- #clock-cells : from common clock binding; shall be set to 2. The first entry | |
| 45 | + is the type of the clock (core, system, peripheral or generated) and the | |
| 46 | + second entry its index as provided by the datasheet | |
| 47 | +- clocks : Must contain an entry for each entry in clock-names. | |
| 48 | +- clock-names: Must include the following entries: "slow_clk", "main_xtal" | |
| 130 | 49 | |
| 131 | 50 | Optional properties: |
| 132 | 51 | - atmel,osc-bypass : boolean property. Set this when a clock signal is directly |
| 133 | 52 | provided on XIN. |
| 134 | 53 | |
| 135 | 54 | For example: |
| 136 | − slow_osc: slow_osc { | |
| 137 | − compatible = "atmel,at91rm9200-clk-slow-osc"; | |
| 138 | − #clock-cells = <0>; | |
| 139 | − clocks = <&slow_xtal>; | |
| 140 | − }; | |
| 141 | − | |
| 142 | −Required properties for slow clock: | |
| 143 | −- #clock-cells : from common clock binding; shall be set to 0. | |
| 144 | −- clocks : shall encode the slow clk sources (see atmel datasheet). | |
| 145 | − | |
| 146 | −For example: | |
| 147 | − clk32k: slck { | |
| 148 | − compatible = "atmel,at91sam9x5-clk-slow"; | |
| 149 | − #clock-cells = <0>; | |
| 150 | − clocks = <&slow_rc_osc &slow_osc>; | |
| 151 | − }; | |
| 152 | − | |
| 153 | −Required properties for PMC node: | |
| 154 | −- reg : defines the IO memory reserved for the PMC. | |
| 155 | −- #size-cells : shall be 0 (reg is used to encode clk id). | |
| 156 | −- #address-cells : shall be 1 (reg is used to encode clk id). | |
| 157 | −- interrupts : shall be set to PMC interrupt line. | |
| 158 | −- interrupt-controller : tell that the PMC is an interrupt controller. | |
| 159 | −- #interrupt-cells : must be set to 1. The first cell encodes the interrupt id, | |
| 160 | − and reflect the bit position in the PMC_ER/DR/SR registers. | |
| 161 | − You can use the dt macros defined in dt-bindings/clock/at91.h. | |
| 162 | − 0 (AT91_PMC_MOSCS) -> main oscillator ready | |
| 163 | − 1 (AT91_PMC_LOCKA) -> PLL A ready | |
| 164 | − 2 (AT91_PMC_LOCKB) -> PLL B ready | |
| 165 | − 3 (AT91_PMC_MCKRDY) -> master clock ready | |
| 166 | − 6 (AT91_PMC_LOCKU) -> UTMI PLL clock ready | |
| 167 | − 8 .. 15 (AT91_PMC_PCKRDY(id)) -> programmable clock ready | |
| 168 | − 16 (AT91_PMC_MOSCSELS) -> main oscillator selected | |
| 169 | − 17 (AT91_PMC_MOSCRCS) -> RC main oscillator stabilized | |
| 170 | − 18 (AT91_PMC_CFDEV) -> clock failure detected | |
| 171 | − | |
| 172 | −For example: | |
| 173 | − pmc: pmc@fffffc00 { | |
| 174 | − compatible = "atmel,sama5d3-pmc"; | |
| 175 | − interrupts = <1 4 7>; | |
| 176 | − interrupt-controller; | |
| 177 | − #interrupt-cells = <2>; | |
| 178 | − #size-cells = <0>; | |
| 179 | − #address-cells = <1>; | |
| 180 | − | |
| 181 | − /* put at91 clocks here */ | |
| 182 | − }; | |
| 183 | − | |
| 184 | −Required properties for main clock internal RC oscillator: | |
| 185 | −- interrupts : shall be set to "<0>". | |
| 186 | −- clock-frequency : define the internal RC oscillator frequency. | |
| 187 | − | |
| 188 | −Optional properties: | |
| 189 | −- clock-accuracy : define the internal RC oscillator accuracy. | |
| 190 | − | |
| 191 | −For example: | |
| 192 | − main_rc_osc: main_rc_osc { | |
| 193 | − compatible = "atmel,at91sam9x5-clk-main-rc-osc"; | |
| 194 | − interrupt-parent = <&pmc>; | |
| 195 | − interrupts = <0>; | |
| 196 | − clock-frequency = <12000000>; | |
| 197 | − clock-accuracy = <50000000>; | |
| 198 | − }; | |
| 199 | − | |
| 200 | −Required properties for main clock oscillator: | |
| 201 | −- interrupts : shall be set to "<0>". | |
| 202 | −- #clock-cells : from common clock binding; shall be set to 0. | |
| 203 | −- clocks : shall encode the main osc source clk sources (see atmel datasheet). | |
| 204 | − | |
| 205 | −Optional properties: | |
| 206 | −- atmel,osc-bypass : boolean property. Specified if a clock signal is provided | |
| 207 | − on XIN. | |
| 208 | − | |
| 209 | − clock signal is directly provided on XIN pin. | |
| 210 | − | |
| 211 | −For example: | |
| 212 | − main_osc: main_osc { | |
| 213 | − compatible = "atmel,at91rm9200-clk-main-osc"; | |
| 214 | − interrupt-parent = <&pmc>; | |
| 215 | − interrupts = <0>; | |
| 216 | − #clock-cells = <0>; | |
| 217 | − clocks = <&main_xtal>; | |
| 218 | − }; | |
| 219 | − | |
| 220 | −Required properties for main clock: | |
| 221 | −- interrupts : shall be set to "<0>". | |
| 222 | −- #clock-cells : from common clock binding; shall be set to 0. | |
| 223 | −- clocks : shall encode the main clk sources (see atmel datasheet). | |
| 224 | − | |
| 225 | −For example: | |
| 226 | − main: mainck { | |
| 227 | − compatible = "atmel,at91sam9x5-clk-main"; | |
| 228 | − interrupt-parent = <&pmc>; | |
| 229 | − interrupts = <0>; | |
| 230 | − #clock-cells = <0>; | |
| 231 | − clocks = <&main_rc_osc &main_osc>; | |
| 232 | − }; | |
| 233 | − | |
| 234 | −Required properties for master clock: | |
| 235 | −- interrupts : shall be set to "<3>". | |
| 236 | −- #clock-cells : from common clock binding; shall be set to 0. | |
| 237 | −- clocks : shall be the master clock sources (see atmel datasheet) phandles. | |
| 238 | − e.g. "<&ck32k>, <&main>, <&plla>, <&pllb>". | |
| 239 | −- atmel,clk-output-range : minimum and maximum clock frequency (two u32 | |
| 240 | − fields). | |
| 241 | − e.g. output = <0 133000000>; <=> 0 to 133MHz. | |
| 242 | −- atmel,clk-divisors : master clock divisors table (four u32 fields). | |
| 243 | − 0 <=> reserved value. | |
| 244 | − e.g. divisors = <1 2 4 6>; | |
| 245 | −- atmel,master-clk-have-div3-pres : some SoC use the reserved value 7 in the | |
| 246 | − PRES field as CLOCK_DIV3 (e.g sam9x5). | |
| 247 | − | |
| 248 | −For example: | |
| 249 | − mck: mck { | |
| 250 | − compatible = "atmel,at91rm9200-clk-master"; | |
| 251 | − interrupt-parent = <&pmc>; | |
| 252 | − interrupts = <3>; | |
| 253 | − #clock-cells = <0>; | |
| 254 | − atmel,clk-output-range = <0 133000000>; | |
| 255 | − atmel,clk-divisors = <1 2 4 0>; | |
| 256 | − }; | |
| 257 | − | |
| 258 | −Required properties for peripheral clocks: | |
| 259 | −- #size-cells : shall be 0 (reg is used to encode clk id). | |
| 260 | −- #address-cells : shall be 1 (reg is used to encode clk id). | |
| 261 | −- clocks : shall be the master clock phandle. | |
| 262 | − e.g. clocks = <&mck>; | |
| 263 | −- name: device tree node describing a specific peripheral clock. | |
| 264 | − * #clock-cells : from common clock binding; shall be set to 0. | |
| 265 | − * reg: peripheral id. See Atmel's datasheets to get a full | |
| 266 | − list of peripheral ids. | |
| 267 | − * atmel,clk-output-range : minimum and maximum clock frequency | |
| 268 | − (two u32 fields). Only valid on at91sam9x5-clk-peripheral | |
| 269 | − compatible IPs. | |
| 270 | − | |
| 271 | −For example: | |
| 272 | − periph: periphck { | |
| 273 | − compatible = "atmel,at91sam9x5-clk-peripheral"; | |
| 274 | − #size-cells = <0>; | |
| 275 | − #address-cells = <1>; | |
| 276 | − clocks = <&mck>; | |
| 277 | − | |
| 278 | − ssc0_clk { | |
| 279 | − #clock-cells = <0>; | |
| 280 | − reg = <2>; | |
| 281 | − atmel,clk-output-range = <0 133000000>; | |
| 282 | − }; | |
| 283 | − | |
| 284 | − usart0_clk { | |
| 285 | − #clock-cells = <0>; | |
| 286 | − reg = <3>; | |
| 287 | − atmel,clk-output-range = <0 66000000>; | |
| 288 | − }; | |
| 289 | − }; | |
| 290 | − | |
| 291 | − | |
| 292 | −Required properties for pll clocks: | |
| 293 | −- interrupts : shall be set to "<1>". | |
| 294 | −- #clock-cells : from common clock binding; shall be set to 0. | |
| 295 | −- clocks : shall be the main clock phandle. | |
| 296 | −- reg : pll id. | |
| 297 | − 0 -> PLL A | |
| 298 | − 1 -> PLL B | |
| 299 | −- atmel,clk-input-range : minimum and maximum source clock frequency (two u32 | |
| 300 | − fields). | |
| 301 | − e.g. input = <1 32000000>; <=> 1 to 32MHz. | |
| 302 | −- #atmel,pll-clk-output-range-cells : number of cells reserved for pll output | |
| 303 | − range description. Sould be set to 2, 3 | |
| 304 | − or 4. | |
| 305 | − * 1st and 2nd cells represent the frequency range (min-max). | |
| 306 | − * 3rd cell is optional and represents the OUT field value for the given | |
| 307 | − range. | |
| 308 | − * 4th cell is optional and represents the ICPLL field (PLLICPR | |
| 309 | − register) | |
| 310 | −- atmel,pll-clk-output-ranges : pll output frequency ranges + optional parameter | |
| 311 | − depending on #atmel,pll-output-range-cells | |
| 312 | − property value. | |
| 313 | − | |
| 314 | −For example: | |
| 315 | − plla: pllack { | |
| 316 | − compatible = "atmel,at91sam9g45-clk-pll"; | |
| 317 | − interrupt-parent = <&pmc>; | |
| 318 | − interrupts = <1>; | |
| 319 | − #clock-cells = <0>; | |
| 320 | − clocks = <&main>; | |
| 321 | − reg = <0>; | |
| 322 | − atmel,clk-input-range = <2000000 32000000>; | |
| 323 | − #atmel,pll-clk-output-range-cells = <4>; | |
| 324 | − atmel,pll-clk-output-ranges = <74500000 800000000 0 0 | |
| 325 | − 69500000 750000000 1 0 | |
| 326 | − 64500000 700000000 2 0 | |
| 327 | − 59500000 650000000 3 0 | |
| 328 | − 54500000 600000000 0 1 | |
| 329 | − 49500000 550000000 1 1 | |
| 330 | − 44500000 500000000 2 1 | |
| 331 | − 40000000 450000000 3 1>; | |
| 332 | − }; | |
| 333 | − | |
| 334 | −Required properties for plldiv clocks (plldiv = pll / 2): | |
| 335 | −- #clock-cells : from common clock binding; shall be set to 0. | |
| 336 | −- clocks : shall be the plla clock phandle. | |
| 337 | − | |
| 338 | −The pll divisor is equal to 2 and cannot be changed. | |
| 339 | − | |
| 340 | −For example: | |
| 341 | − plladiv: plladivck { | |
| 342 | − compatible = "atmel,at91sam9x5-clk-plldiv"; | |
| 343 | − #clock-cells = <0>; | |
| 344 | − clocks = <&plla>; | |
| 345 | − }; | |
| 346 | − | |
| 347 | −Required properties for programmable clocks: | |
| 348 | −- #size-cells : shall be 0 (reg is used to encode clk id). | |
| 349 | −- #address-cells : shall be 1 (reg is used to encode clk id). | |
| 350 | −- clocks : shall be the programmable clock source phandles. | |
| 351 | − e.g. clocks = <&clk32k>, <&main>, <&plla>, <&pllb>; | |
| 352 | −- name: device tree node describing a specific prog clock. | |
| 353 | − * #clock-cells : from common clock binding; shall be set to 0. | |
| 354 | − * reg : programmable clock id (register offset from PCKx | |
| 355 | − register). | |
| 356 | − * interrupts : shall be set to "<(8 + id)>". | |
| 357 | − | |
| 358 | −For example: | |
| 359 | − prog: progck { | |
| 360 | − compatible = "atmel,at91sam9g45-clk-programmable"; | |
| 361 | − #size-cells = <0>; | |
| 362 | − #address-cells = <1>; | |
| 363 | − interrupt-parent = <&pmc>; | |
| 364 | − clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>; | |
| 365 | − | |
| 366 | − prog0 { | |
| 367 | − #clock-cells = <0>; | |
| 368 | − reg = <0>; | |
| 369 | − interrupts = <8>; | |
| 370 | − }; | |
| 371 | − | |
| 372 | − prog1 { | |
| 373 | − #clock-cells = <0>; | |
| 374 | − reg = <1>; | |
| 375 | − interrupts = <9>; | |
| 376 | − }; | |
| 377 | − }; | |
| 378 | − | |
| 379 | − | |
| 380 | −Required properties for smd clock: | |
| 381 | −- #clock-cells : from common clock binding; shall be set to 0. | |
| 382 | −- clocks : shall be the smd clock source phandles. | |
| 383 | − e.g. clocks = <&plladiv>, <&utmi>; | |
| 384 | − | |
| 385 | −For example: | |
| 386 | − smd: smdck { | |
| 387 | − compatible = "atmel,at91sam9x5-clk-smd"; | |
| 388 | − #clock-cells = <0>; | |
| 389 | − clocks = <&plladiv>, <&utmi>; | |
| 390 | − }; | |
| 391 | − | |
| 392 | −Required properties for system clocks: | |
| 393 | −- #size-cells : shall be 0 (reg is used to encode clk id). | |
| 394 | −- #address-cells : shall be 1 (reg is used to encode clk id). | |
| 395 | −- name: device tree node describing a specific system clock. | |
| 396 | − * #clock-cells : from common clock binding; shall be set to 0. | |
| 397 | − * reg: system clock id (bit position in SCER/SCDR/SCSR registers). | |
| 398 | − See Atmel's datasheet to get a full list of system clock ids. | |
| 399 | − | |
| 400 | −For example: | |
| 401 | − system: systemck { | |
| 402 | − compatible = "atmel,at91rm9200-clk-system"; | |
| 403 | − #address-cells = <1>; | |
| 404 | − #size-cells = <0>; | |
| 405 | − | |
| 406 | − ddrck { | |
| 407 | − #clock-cells = <0>; | |
| 408 | − reg = <2>; | |
| 409 | − clocks = <&mck>; | |
| 410 | − }; | |
| 411 | − | |
| 412 | − uhpck { | |
| 413 | − #clock-cells = <0>; | |
| 414 | − reg = <6>; | |
| 415 | − clocks = <&usb>; | |
| 416 | − }; | |
| 417 | − | |
| 418 | − udpck { | |
| 419 | − #clock-cells = <0>; | |
| 420 | − reg = <7>; | |
| 421 | − clocks = <&usb>; | |
| 422 | − }; | |
| 423 | − }; | |
| 424 | − | |
| 425 | − | |
| 426 | −Required properties for usb clock: | |
| 427 | −- #clock-cells : from common clock binding; shall be set to 0. | |
| 428 | −- clocks : shall be the smd clock source phandles. | |
| 429 | − e.g. clocks = <&pllb>; | |
| 430 | −- atmel,clk-divisors (only available for "atmel,at91rm9200-clk-usb"): | |
| 431 | − usb clock divisor table. | |
| 432 | − e.g. divisors = <1 2 4 0>; | |
| 433 | − | |
| 434 | −For example: | |
| 435 | − usb: usbck { | |
| 436 | − compatible = "atmel,at91sam9x5-clk-usb"; | |
| 437 | − #clock-cells = <0>; | |
| 438 | − clocks = <&plladiv>, <&utmi>; | |
| 439 | − }; | |
| 440 | − | |
| 441 | − usb: usbck { | |
| 442 | − compatible = "atmel,at91rm9200-clk-usb"; | |
| 443 | − #clock-cells = <0>; | |
| 444 | − clocks = <&pllb>; | |
| 445 | − atmel,clk-divisors = <1 2 4 0>; | |
| 446 | − }; | |
| 447 | − | |
| 448 | − | |
| 449 | −Required properties for utmi clock: | |
| 450 | −- interrupts : shall be set to "<AT91_PMC_LOCKU IRQ_TYPE_LEVEL_HIGH>". | |
| 451 | −- #clock-cells : from common clock binding; shall be set to 0. | |
| 452 | −- clocks : shall be the main clock source phandle. | |
| 453 | − | |
| 454 | −For example: | |
| 455 | − utmi: utmick { | |
| 456 | − compatible = "atmel,at91sam9x5-clk-utmi"; | |
| 457 | − interrupt-parent = <&pmc>; | |
| 458 | − interrupts = <AT91_PMC_LOCKU IRQ_TYPE_LEVEL_HIGH>; | |
| 459 | − #clock-cells = <0>; | |
| 460 | − clocks = <&main>; | |
| 461 | − }; | |
| 462 | − | |
| 463 | −Required properties for 32 bits bus Matrix clock (h32mx clock): | |
| 464 | −- #clock-cells : from common clock binding; shall be set to 0. | |
| 465 | −- clocks : shall be the master clock source phandle. | |
| 466 | − | |
| 467 | −For example: | |
| 468 | − h32ck: h32mxck { | |
| 469 | − #clock-cells = <0>; | |
| 470 | − compatible = "atmel,sama5d4-clk-h32mx"; | |
| 471 | − clocks = <&mck>; | |
| 472 | − }; | |
| 473 | − | |
| 474 | −Required properties for generated clocks: | |
| 475 | −- #size-cells : shall be 0 (reg is used to encode clk id). | |
| 476 | −- #address-cells : shall be 1 (reg is used to encode clk id). | |
| 477 | −- clocks : shall be the generated clock source phandles. | |
| 478 | − e.g. clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>, <&audio_pll_pmc>; | |
| 479 | −- name: device tree node describing a specific generated clock. | |
| 480 | − * #clock-cells : from common clock binding; shall be set to 0. | |
| 481 | − * reg: peripheral id. See Atmel's datasheets to get a full | |
| 482 | − list of peripheral ids. | |
| 483 | − * atmel,clk-output-range : minimum and maximum clock frequency | |
| 484 | − (two u32 fields). | |
| 485 | − | |
| 486 | −For example: | |
| 487 | − gck { | |
| 488 | − compatible = "atmel,sama5d2-clk-generated"; | |
| 489 | − #address-cells = <1>; | |
| 490 | − #size-cells = <0>; | |
| 491 | − clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>, <&audio_pll_pmc>; | |
| 492 | − | |
| 493 | − tcb0_gclk: tcb0_gclk { | |
| 494 | − #clock-cells = <0>; | |
| 495 | − reg = <35>; | |
| 496 | − atmel,clk-output-range = <0 83000000>; | |
| 497 | − }; | |
| 498 | − | |
| 499 | − pwm_gclk: pwm_gclk { | |
| 500 | − #clock-cells = <0>; | |
| 501 | − reg = <38>; | |
| 502 | − atmel,clk-output-range = <0 83000000>; | |
| 503 | − }; | |
| 504 | − }; | |
| 505 | − | |
| 506 | −Required properties for I2S mux clocks: | |
| 507 | −- #size-cells : shall be 0 (reg is used to encode I2S bus id). | |
| 508 | −- #address-cells : shall be 1 (reg is used to encode I2S bus id). | |
| 509 | −- name: device tree node describing a specific mux clock. | |
| 510 | − * #clock-cells : from common clock binding; shall be set to 0. | |
| 511 | − * clocks : shall be the mux clock parent phandles; shall be 2 phandles: | |
| 512 | − peripheral and generated clock; the first phandle shall belong to the | |
| 513 | − peripheral clock and the second one shall belong to the generated | |
| 514 | − clock; "clock-indices" property can be user to specify | |
| 515 | − the correct order. | |
| 516 | − * reg: I2S bus id of the corresponding mux clock. | |
| 517 | − e.g. reg = <0>; for i2s0, reg = <1>; for i2s1 | |
| 518 | − | |
| 519 | −For example: | |
| 520 | − i2s_clkmux { | |
| 521 | − compatible = "atmel,sama5d2-clk-i2s-mux"; | |
| 522 | − #address-cells = <1>; | |
| 523 | − #size-cells = <0>; | |
| 524 | − | |
| 525 | − i2s0muxck: i2s0_muxclk { | |
| 526 | − clocks = <&i2s0_clk>, <&i2s0_gclk>; | |
| 527 | − #clock-cells = <0>; | |
| 528 | − reg = <0>; | |
| 529 | − }; | |
| 530 | − | |
| 531 | − i2s1muxck: i2s1_muxclk { | |
| 532 | − clocks = <&i2s1_clk>, <&i2s1_gclk>; | |
| 533 | − #clock-cells = <0>; | |
| 534 | − reg = <1>; | |
| 535 | − }; | |
| 55 | + pmc: pmc@f0018000 { | |
| 56 | + compatible = "atmel,sama5d4-pmc", "syscon"; | |
| 57 | + reg = <0xf0018000 0x120>; | |
| 58 | + interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>; | |
| 59 | + #clock-cells = <2>; | |
| 60 | + clocks = <&clk32k>, <&main_xtal>; | |
| 61 | + clock-names = "slow_clk", "main_xtal"; | |
| 536 | 62 | }; |
| @@ -0,0 +1,43 @@ | ||
| 1 | +* Hisilicon Hi3670 Clock Controller | |
| 2 | + | |
| 3 | +The Hi3670 clock controller generates and supplies clock to various | |
| 4 | +controllers within the Hi3670 SoC. | |
| 5 | + | |
| 6 | +Required Properties: | |
| 7 | + | |
| 8 | +- compatible: the compatible should be one of the following strings to | |
| 9 | + indicate the clock controller functionality. | |
| 10 | + | |
| 11 | + - "hisilicon,hi3670-crgctrl" | |
| 12 | + - "hisilicon,hi3670-pctrl" | |
| 13 | + - "hisilicon,hi3670-pmuctrl" | |
| 14 | + - "hisilicon,hi3670-sctrl" | |
| 15 | + - "hisilicon,hi3670-iomcu" | |
| 16 | + - "hisilicon,hi3670-media1-crg" | |
| 17 | + - "hisilicon,hi3670-media2-crg" | |
| 18 | + | |
| 19 | +- reg: physical base address of the controller and length of memory mapped | |
| 20 | + region. | |
| 21 | + | |
| 22 | +- #clock-cells: should be 1. | |
| 23 | + | |
| 24 | +Each clock is assigned an identifier and client nodes use this identifier | |
| 25 | +to specify the clock which they consume. | |
| 26 | + | |
| 27 | +All these identifier could be found in <dt-bindings/clock/hi3670-clock.h>. | |
| 28 | + | |
| 29 | +Examples: | |
| 30 | + crg_ctrl: clock-controller@fff35000 { | |
| 31 | + compatible = "hisilicon,hi3670-crgctrl", "syscon"; | |
| 32 | + reg = <0x0 0xfff35000 0x0 0x1000>; | |
| 33 | + #clock-cells = <1>; | |
| 34 | + }; | |
| 35 | + | |
| 36 | + uart0: serial@fdf02000 { | |
| 37 | + compatible = "arm,pl011", "arm,primecell"; | |
| 38 | + reg = <0x0 0xfdf02000 0x0 0x1000>; | |
| 39 | + interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>; | |
| 40 | + clocks = <&crg_ctrl HI3670_CLK_GATE_UART0>, | |
| 41 | + <&crg_ctrl HI3670_PCLK>; | |
| 42 | + clock-names = "uartclk", "apb_pclk"; | |
| 43 | + }; | |
| @@ -6,6 +6,14 @@ Required properties: · 5 unmodified lines | ||
| 6 | 6 | - interrupts: Should contain CCM interrupt |
| 7 | 7 | - #clock-cells: Should be <1> |
| 8 | 8 | |
| 9 | +Optional properties: | |
| 10 | +- fsl,pmic-stby-poweroff: Configure CCM to assert PMIC_STBY_REQ signal | |
| 11 | + on power off. | |
| 12 | + Use this property if the SoC should be powered off by external power | |
| 13 | + management IC (PMIC) triggered via PMIC_STBY_REQ signal. | |
| 14 | + Boards that are designed to initiate poweroff on PMIC_ON_REQ signal should | |
| 15 | + be using "syscon-poweroff" driver instead. | |
| 16 | + | |
| 9 | 17 | The clock consumer should specify the desired clock by having the clock |
| 10 | 18 | ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6qdl-clock.h |
| 11 | 19 | for the full list of i.MX6 Quad and DualLite clock IDs. |
| @@ -6,8 +6,11 @@ to provide many different clock signals derived from only 2 external source · 5 unmodified lines | ||
| 6 | 6 | clocks. |
| 7 | 7 | |
| 8 | 8 | Required properties: |
| 9 | −- compatible : Should be "ingenic,<soctype>-cgu". | |
| 10 | − For example "ingenic,jz4740-cgu" or "ingenic,jz4780-cgu". | |
| 9 | +- compatible : Should be one of: | |
| 10 | + * ingenic,jz4740-cgu | |
| 11 | + * ingenic,jz4725b-cgu | |
| 12 | + * ingenic,jz4770-cgu | |
| 13 | + * ingenic,jz4780-cgu | |
| 11 | 14 | - reg : The address & length of the CGU registers. |
| 12 | 15 | - clocks : List of phandle & clock specifiers for clocks external to the CGU. |
| 13 | 16 | Two such external clocks should be specified - first the external crystal |
| @@ -0,0 +1,18 @@ | ||
| 1 | +Qualcomm Camera Clock & Reset Controller Binding | |
| 2 | +------------------------------------------------ | |
| 3 | + | |
| 4 | +Required properties : | |
| 5 | +- compatible : shall contain "qcom,sdm845-camcc". | |
| 6 | +- reg : shall contain base register location and length. | |
| 7 | +- #clock-cells : from common clock binding, shall contain 1. | |
| 8 | +- #reset-cells : from common reset binding, shall contain 1. | |
| 9 | +- #power-domain-cells : from generic power domain binding, shall contain 1. | |
| 10 | + | |
| 11 | +Example: | |
| 12 | + camcc: clock-controller@ad00000 { | |
| 13 | + compatible = "qcom,sdm845-camcc"; | |
| 14 | + reg = <0xad00000 0x10000>; | |
| 15 | + #clock-cells = <1>; | |
| 16 | + #reset-cells = <1>; | |
| 17 | + #power-domain-cells = <1>; | |
| 18 | + }; | |
| @@ -19,6 +19,9 @@ Required properties : · 18 unmodified lines | ||
| 19 | 19 | "qcom,gcc-msm8996" |
| 20 | 20 | "qcom,gcc-msm8998" |
| 21 | 21 | "qcom,gcc-mdm9615" |
| 22 | + "qcom,gcc-qcs404" | |
| 23 | + "qcom,gcc-sdm630" | |
| 24 | + "qcom,gcc-sdm660" | |
| 22 | 25 | "qcom,gcc-sdm845" |
| 23 | 26 | |
| 24 | 27 | - reg : shall contain base register location and length |
| @@ -0,0 +1,60 @@ | ||
| 1 | +High-Frequency PLL (HFPLL) | |
| 2 | + | |
| 3 | +PROPERTIES | |
| 4 | + | |
| 5 | +- compatible: | |
| 6 | + Usage: required | |
| 7 | + Value type: <string>: | |
| 8 | + shall contain only one of the following. The generic | |
| 9 | + compatible "qcom,hfpll" should be also included. | |
| 10 | + | |
| 11 | + "qcom,hfpll-ipq8064", "qcom,hfpll" | |
| 12 | + "qcom,hfpll-apq8064", "qcom,hfpll" | |
| 13 | + "qcom,hfpll-msm8974", "qcom,hfpll" | |
| 14 | + "qcom,hfpll-msm8960", "qcom,hfpll" | |
| 15 | + | |
| 16 | +- reg: | |
| 17 | + Usage: required | |
| 18 | + Value type: <prop-encoded-array> | |
| 19 | + Definition: address and size of HPLL registers. An optional second | |
| 20 | + element specifies the address and size of the alias | |
| 21 | + register region. | |
| 22 | + | |
| 23 | +- clocks: | |
| 24 | + Usage: required | |
| 25 | + Value type: <prop-encoded-array> | |
| 26 | + Definition: reference to the xo clock. | |
| 27 | + | |
| 28 | +- clock-names: | |
| 29 | + Usage: required | |
| 30 | + Value type: <stringlist> | |
| 31 | + Definition: must be "xo". | |
| 32 | + | |
| 33 | +- clock-output-names: | |
| 34 | + Usage: required | |
| 35 | + Value type: <string> | |
| 36 | + Definition: Name of the PLL. Typically hfpllX where X is a CPU number | |
| 37 | + starting at 0. Otherwise hfpll_Y where Y is more specific | |
| 38 | + such as "l2". | |
| 39 | + | |
| 40 | +Example: | |
| 41 | + | |
| 42 | +1) An HFPLL for the L2 cache. | |
| 43 | + | |
| 44 | + clock-controller@f9016000 { | |
| 45 | + compatible = "qcom,hfpll-ipq8064", "qcom,hfpll"; | |
| 46 | + reg = <0xf9016000 0x30>; | |
| 47 | + clocks = <&xo_board>; | |
| 48 | + clock-names = "xo"; | |
| 49 | + clock-output-names = "hfpll_l2"; | |
| 50 | + }; | |
| 51 | + | |
| 52 | +2) An HFPLL for CPU0. This HFPLL has the alias register region. | |
| 53 | + | |
| 54 | + clock-controller@f908a000 { | |
| 55 | + compatible = "qcom,hfpll-ipq8064", "qcom,hfpll"; | |
| 56 | + reg = <0xf908a000 0x30>, <0xf900a000 0x30>; | |
| 57 | + clocks = <&xo_board>; | |
| 58 | + clock-names = "xo"; | |
| 59 | + clock-output-names = "hfpll0"; | |
| 60 | + }; | |
| @@ -0,0 +1,34 @@ | ||
| 1 | +Krait Clock Controller | |
| 2 | + | |
| 3 | +PROPERTIES | |
| 4 | + | |
| 5 | +- compatible: | |
| 6 | + Usage: required | |
| 7 | + Value type: <string> | |
| 8 | + Definition: must be one of: | |
| 9 | + "qcom,krait-cc-v1" | |
| 10 | + "qcom,krait-cc-v2" | |
| 11 | + | |
| 12 | +- #clock-cells: | |
| 13 | + Usage: required | |
| 14 | + Value type: <u32> | |
| 15 | + Definition: must be 1 | |
| 16 | + | |
| 17 | +- clocks: | |
| 18 | + Usage: required | |
| 19 | + Value type: <prop-encoded-array> | |
| 20 | + Definition: reference to the clock parents of hfpll, secondary muxes. | |
| 21 | + | |
| 22 | +- clock-names: | |
| 23 | + Usage: required | |
| 24 | + Value type: <stringlist> | |
| 25 | + Definition: must be "hfpll0", "hfpll1", "acpu0_aux", "acpu1_aux", "qsb". | |
| 26 | + | |
| 27 | +Example: | |
| 28 | + | |
| 29 | + kraitcc: clock-controller { | |
| 30 | + compatible = "qcom,krait-cc-v1"; | |
| 31 | + clocks = <&hfpll0>, <&hfpll1>, <&acpu0_aux>, <&acpu1_aux>, <qsb>; | |
| 32 | + clock-names = "hfpll0", "hfpll1", "acpu0_aux", "acpu1_aux", "qsb"; | |
| 33 | + #clock-cells = <1>; | |
| 34 | + }; | |
| @@ -13,9 +13,13 @@ They provide the following functionalities: · 12 unmodified lines | ||
| 13 | 13 | |
| 14 | 14 | Required Properties: |
| 15 | 15 | - compatible: Must be one of: |
| 16 | + - "renesas,r7s9210-cpg-mssr" for the r7s9210 SoC (RZ/A2) | |
| 16 | 17 | - "renesas,r8a7743-cpg-mssr" for the r8a7743 SoC (RZ/G1M) |
| 18 | + - "renesas,r8a7744-cpg-mssr" for the r8a7744 SoC (RZ/G1N) | |
| 17 | 19 | - "renesas,r8a7745-cpg-mssr" for the r8a7745 SoC (RZ/G1E) |
| 18 | 20 | - "renesas,r8a77470-cpg-mssr" for the r8a77470 SoC (RZ/G1C) |
| 21 | + - "renesas,r8a774a1-cpg-mssr" for the r8a774a1 SoC (RZ/G2M) | |
| 22 | + - "renesas,r8a774c0-cpg-mssr" for the r8a774c0 SoC (RZ/G2E) | |
| 19 | 23 | - "renesas,r8a7790-cpg-mssr" for the r8a7790 SoC (R-Car H2) |
| 20 | 24 | - "renesas,r8a7791-cpg-mssr" for the r8a7791 SoC (R-Car M2-W) |
| 21 | 25 | - "renesas,r8a7792-cpg-mssr" for the r8a7792 SoC (R-Car V2H) |
| @@ -35,12 +39,13 @@ Required Properties: · 13 unmodified lines | ||
| 35 | 39 | - clocks: References to external parent clocks, one entry for each entry in |
| 36 | 40 | clock-names |
| 37 | 41 | - clock-names: List of external parent clock names. Valid names are: |
| 38 | − - "extal" (r8a7743, r8a7745, r8a77470, r8a7790, r8a7791, r8a7792, | |
| 39 | − r8a7793, r8a7794, r8a7795, r8a7796, r8a77965, r8a77970, | |
| 40 | − r8a77980, r8a77990, r8a77995) | |
| 41 | − - "extalr" (r8a7795, r8a7796, r8a77965, r8a77970, r8a77980) | |
| 42 | − - "usb_extal" (r8a7743, r8a7745, r8a77470, r8a7790, r8a7791, r8a7793, | |
| 43 | − r8a7794) | |
| 42 | + - "extal" (r7s9210, r8a7743, r8a7744, r8a7745, r8a77470, r8a774a1, | |
| 43 | + r8a774c0, r8a7790, r8a7791, r8a7792, r8a7793, r8a7794, | |
| 44 | + r8a7795, r8a7796, r8a77965, r8a77970, r8a77980, r8a77990, | |
| 45 | + r8a77995) | |
| 46 | + - "extalr" (r8a774a1, r8a7795, r8a7796, r8a77965, r8a77970, r8a77980) | |
| 47 | + - "usb_extal" (r8a7743, r8a7744, r8a7745, r8a77470, r8a7790, r8a7791, | |
| 48 | + r8a7793, r8a7794) | |
| 44 | 49 | |
| 45 | 50 | - #clock-cells: Must be 2 |
| 46 | 51 | - For CPG core clocks, the two clock specifier cells must be "CPG_CORE" |
| @@ -29,15 +29,15 @@ Required properties for usb-c-connector with power delivery support: · 28 unmodified lines | ||
| 29 | 29 | in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2 |
| 30 | 30 | Source_Capabilities Message, the order of each entry(PDO) should follow |
| 31 | 31 | the PD spec chapter 6.4.1. Required for power source and power dual role. |
| 32 | − User can specify the source PDO array via PDO_FIXED/BATT/VAR() defined in | |
| 33 | − dt-bindings/usb/pd.h. | |
| 32 | + User can specify the source PDO array via PDO_FIXED/BATT/VAR/PPS_APDO() | |
| 33 | + defined in dt-bindings/usb/pd.h. | |
| 34 | 34 | - sink-pdos: An array of u32 with each entry providing supported power |
| 35 | 35 | sink data object(PDO), the detailed bit definitions of PDO can be found |
| 36 | 36 | in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3 |
| 37 | 37 | Sink Capabilities Message, the order of each entry(PDO) should follow |
| 38 | 38 | the PD spec chapter 6.4.1. Required for power sink and power dual role. |
| 39 | − User can specify the sink PDO array via PDO_FIXED/BATT/VAR() defined in | |
| 40 | − dt-bindings/usb/pd.h. | |
| 39 | + User can specify the sink PDO array via PDO_FIXED/BATT/VAR/PPS_APDO() defined | |
| 40 | + in dt-bindings/usb/pd.h. | |
| 41 | 41 | - op-sink-microwatt: Sink required operating power in microwatt, if source |
| 42 | 42 | can't offer the power, Capability Mismatch is set. Required for power |
| 43 | 43 | sink and power dual role. |
| @@ -1,65 +0,0 @@ | ||
| 1 | −Generic ARM big LITTLE cpufreq driver's DT glue | |
| 2 | −----------------------------------------------- | |
| 3 | − | |
| 4 | −This is DT specific glue layer for generic cpufreq driver for big LITTLE | |
| 5 | −systems. | |
| 6 | − | |
| 7 | −Both required and optional properties listed below must be defined | |
| 8 | −under node /cpus/cpu@x. Where x is the first cpu inside a cluster. | |
| 9 | − | |
| 10 | −FIXME: Cpus should boot in the order specified in DT and all cpus for a cluster | |
| 11 | −must be present contiguously. Generic DT driver will check only node 'x' for | |
| 12 | −cpu:x. | |
| 13 | − | |
| 14 | −Required properties: | |
| 15 | −- operating-points: Refer to Documentation/devicetree/bindings/opp/opp.txt | |
| 16 | − for details | |
| 17 | − | |
| 18 | −Optional properties: | |
| 19 | −- clock-latency: Specify the possible maximum transition latency for clock, | |
| 20 | − in unit of nanoseconds. | |
| 21 | − | |
| 22 | −Examples: | |
| 23 | − | |
| 24 | −cpus { | |
| 25 | − #address-cells = <1>; | |
| 26 | − #size-cells = <0>; | |
| 27 | − | |
| 28 | − cpu@0 { | |
| 29 | − compatible = "arm,cortex-a15"; | |
| 30 | − reg = <0>; | |
| 31 | − next-level-cache = <&L2>; | |
| 32 | − operating-points = < | |
| 33 | − /* kHz uV */ | |
| 34 | − 792000 1100000 | |
| 35 | − 396000 950000 | |
| 36 | − 198000 850000 | |
| 37 | − >; | |
| 38 | − clock-latency = <61036>; /* two CLK32 periods */ | |
| 39 | − }; | |
| 40 | − | |
| 41 | − cpu@1 { | |
| 42 | − compatible = "arm,cortex-a15"; | |
| 43 | − reg = <1>; | |
| 44 | − next-level-cache = <&L2>; | |
| 45 | − }; | |
| 46 | − | |
| 47 | − cpu@100 { | |
| 48 | − compatible = "arm,cortex-a7"; | |
| 49 | − reg = <100>; | |
| 50 | − next-level-cache = <&L2>; | |
| 51 | − operating-points = < | |
| 52 | − /* kHz uV */ | |
| 53 | − 792000 950000 | |
| 54 | − 396000 750000 | |
| 55 | − 198000 450000 | |
| 56 | − >; | |
| 57 | − clock-latency = <61036>; /* two CLK32 periods */ | |
| 58 | − }; | |
| 59 | − | |
| 60 | − cpu@101 { | |
| 61 | − compatible = "arm,cortex-a7"; | |
| 62 | − reg = <101>; | |
| 63 | − next-level-cache = <&L2>; | |
| 64 | − }; | |
| 65 | −}; | |
| @@ -24,7 +24,7 @@ Optional properties: · 23 unmodified lines | ||
| 24 | 24 | |
| 25 | 25 | Example: |
| 26 | 26 | |
| 27 | −p1_sec_a: crypto@400,d2000000 { | |
| 27 | +p1_sec_a: crypto@400d2000000 { | |
| 28 | 28 | compatible = "hisilicon,hip07-sec"; |
| 29 | 29 | reg = <0x400 0xd0000000 0x0 0x10000 |
| 30 | 30 | 0x400 0xd2000000 0x0 0x10000 |
| @@ -0,0 +1,73 @@ | ||
| 1 | +================== | |
| 2 | +C-SKY CPU Bindings | |
| 3 | +================== | |
| 4 | + | |
| 5 | +The device tree allows to describe the layout of CPUs in a system through | |
| 6 | +the "cpus" node, which in turn contains a number of subnodes (ie "cpu") | |
| 7 | +defining properties for every cpu. | |
| 8 | + | |
| 9 | +Only SMP system need to care about the cpus node and single processor | |
| 10 | +needn't define cpus node at all. | |
| 11 | + | |
| 12 | +===================================== | |
| 13 | +cpus and cpu node bindings definition | |
| 14 | +===================================== | |
| 15 | + | |
| 16 | +- cpus node | |
| 17 | + | |
| 18 | + Description: Container of cpu nodes | |
| 19 | + | |
| 20 | + The node name must be "cpus". | |
| 21 | + | |
| 22 | + A cpus node must define the following properties: | |
| 23 | + | |
| 24 | + - #address-cells | |
| 25 | + Usage: required | |
| 26 | + Value type: <u32> | |
| 27 | + Definition: must be set to 1 | |
| 28 | + - #size-cells | |
| 29 | + Usage: required | |
| 30 | + Value type: <u32> | |
| 31 | + Definition: must be set to 0 | |
| 32 | + | |
| 33 | +- cpu node | |
| 34 | + | |
| 35 | + Description: Describes one of SMP cores | |
| 36 | + | |
| 37 | + PROPERTIES | |
| 38 | + | |
| 39 | + - device_type | |
| 40 | + Usage: required | |
| 41 | + Value type: <string> | |
| 42 | + Definition: must be "cpu" | |
| 43 | + - reg | |
| 44 | + Usage: required | |
| 45 | + Value type: <u32> | |
| 46 | + Definition: CPU index | |
| 47 | + - compatible: | |
| 48 | + Usage: required | |
| 49 | + Value type: <string> | |
| 50 | + Definition: must contain "csky", eg: | |
| 51 | + "csky,610" | |
| 52 | + "csky,807" | |
| 53 | + "csky,810" | |
| 54 | + "csky,860" | |
| 55 | + | |
| 56 | +Example: | |
| 57 | +-------- | |
| 58 | + | |
| 59 | + cpus { | |
| 60 | + #address-cells = <1>; | |
| 61 | + #size-cells = <0>; | |
| 62 | + cpu@0 { | |
| 63 | + device_type = "cpu"; | |
| 64 | + reg = <0>; | |
| 65 | + status = "ok"; | |
| 66 | + }; | |
| 67 | + | |
| 68 | + cpu@1 { | |
| 69 | + device_type = "cpu"; | |
| 70 | + reg = <1>; | |
| 71 | + status = "ok"; | |
| 72 | + }; | |
| 73 | + }; | |
| @@ -0,0 +1,26 @@ | ||
| 1 | +Himax HX8357D display panels | |
| 2 | + | |
| 3 | +This binding is for display panels using a Himax HX8357D controller in SPI | |
| 4 | +mode, such as the Adafruit 3.5" TFT for Raspberry Pi. | |
| 5 | + | |
| 6 | +Required properties: | |
| 7 | +- compatible: "adafruit,yx350hv15", "himax,hx8357d" | |
| 8 | +- dc-gpios: D/C pin | |
| 9 | +- reg: address of the panel on the SPI bus | |
| 10 | + | |
| 11 | +The node for this driver must be a child node of a SPI controller, hence | |
| 12 | +all mandatory properties described in ../spi/spi-bus.txt must be specified. | |
| 13 | + | |
| 14 | +Optional properties: | |
| 15 | +- rotation: panel rotation in degrees counter clockwise (0,90,180,270) | |
| 16 | +- backlight: phandle of the backlight device attached to the panel | |
| 17 | + | |
| 18 | +Example: | |
| 19 | + display@0{ | |
| 20 | + compatible = "adafruit,yx350hv15", "himax,hx8357d"; | |
| 21 | + reg = <0>; | |
| 22 | + spi-max-frequency = <32000000>; | |
| 23 | + dc-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>; | |
| 24 | + rotation = <90>; | |
| 25 | + backlight = <&backlight>; | |
| 26 | + }; | |
| @@ -0,0 +1,12 @@ | ||
| 1 | +Banana Pi 7" (S070WV20-CT16) TFT LCD Panel | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be "bananapi,s070wv20-ct16" | |
| 5 | +- power-supply: see ./panel-common.txt | |
| 6 | + | |
| 7 | +Optional properties: | |
| 8 | +- enable-gpios: see ./simple-panel.txt | |
| 9 | +- backlight: see ./simple-panel.txt | |
| 10 | + | |
| 11 | +This binding is compatible with the simple-panel binding, which is specified | |
| 12 | +in ./simple-panel.txt. | |
| @@ -0,0 +1,12 @@ | ||
| 1 | +CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be "cdtech,s043wq26h-ct7" | |
| 5 | +- power-supply: as specified in the base binding | |
| 6 | + | |
| 7 | +Optional properties: | |
| 8 | +- backlight: as specified in the base binding | |
| 9 | +- enable-gpios: as specified in the base binding | |
| 10 | + | |
| 11 | +This binding is compatible with the simple-panel binding, which is specified | |
| 12 | +in simple-panel.txt in this directory. | |
| @@ -0,0 +1,12 @@ | ||
| 1 | +CDTech(H.K.) Electronics Limited 7" 800x480 color TFT-LCD panel | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be "cdtech,s070wv95-ct16" | |
| 5 | +- power-supply: as specified in the base binding | |
| 6 | + | |
| 7 | +Optional properties: | |
| 8 | +- backlight: as specified in the base binding | |
| 9 | +- enable-gpios: as specified in the base binding | |
| 10 | + | |
| 11 | +This binding is compatible with the simple-panel binding, which is specified | |
| 12 | +in simple-panel.txt in this directory. | |
| @@ -0,0 +1,12 @@ | ||
| 1 | +DLC Display Co. DLC1010GIG 10.1" WXGA TFT LCD Panel | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be "dlc,dlc1010gig" | |
| 5 | +- power-supply: See simple-panel.txt | |
| 6 | + | |
| 7 | +Optional properties: | |
| 8 | +- enable-gpios: See simple-panel.txt | |
| 9 | +- backlight: See simple-panel.txt | |
| 10 | + | |
| 11 | +This binding is compatible with the simple-panel binding, which is specified | |
| 12 | +in simple-panel.txt in this directory. | |
| @@ -0,0 +1,42 @@ | ||
| 1 | +Binding for Olimex Ltd. LCD-OLinuXino bridge panel. | |
| 2 | + | |
| 3 | +This device can be used as bridge between a host controller and LCD panels. | |
| 4 | +Currently supported LCDs are: | |
| 5 | + - LCD-OLinuXino-4.3TS | |
| 6 | + - LCD-OLinuXino-5 | |
| 7 | + - LCD-OLinuXino-7 | |
| 8 | + - LCD-OLinuXino-10 | |
| 9 | + | |
| 10 | +The panel itself contains: | |
| 11 | + - AT24C16C EEPROM holding panel identification and timing requirements | |
| 12 | + - AR1021 resistive touch screen controller (optional) | |
| 13 | + - FT5x6 capacitive touch screnn controller (optional) | |
| 14 | + - GT911/GT928 capacitive touch screen controller (optional) | |
| 15 | + | |
| 16 | +The above chips share same I2C bus. The EEPROM is factory preprogrammed with | |
| 17 | +device information (id, serial, etc.) and timing requirements. | |
| 18 | + | |
| 19 | +Touchscreen bingings can be found in these files: | |
| 20 | + - input/touchscreen/goodix.txt | |
| 21 | + - input/touchscreen/edt-ft5x06.txt | |
| 22 | + - input/touchscreen/ar1021.txt | |
| 23 | + | |
| 24 | +Required properties: | |
| 25 | + - compatible: should be "olimex,lcd-olinuxino" | |
| 26 | + - reg: address of the configuration EEPROM, should be <0x50> | |
| 27 | + - power-supply: phandle of the regulator that provides the supply voltage | |
| 28 | + | |
| 29 | +Optional properties: | |
| 30 | + - enable-gpios: GPIO pin to enable or disable the panel | |
| 31 | + - backlight: phandle of the backlight device attacked to the panel | |
| 32 | + | |
| 33 | +Example: | |
| 34 | +&i2c2 { | |
| 35 | + panel@50 { | |
| 36 | + compatible = "olimex,lcd-olinuxino"; | |
| 37 | + reg = <0x50>; | |
| 38 | + power-supply = <®_vcc5v0>; | |
| 39 | + enable-gpios = <&pio 7 8 GPIO_ACTIVE_HIGH>; | |
| 40 | + backlight = <&backlight>; | |
| 41 | + }; | |
| 42 | +}; | |
| @@ -0,0 +1,30 @@ | ||
| 1 | +Samsung S6D16D0 4" 864x480 AMOLED panel | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: should be: | |
| 5 | + "samsung,s6d16d0", | |
| 6 | + - reg: the virtual channel number of a DSI peripheral | |
| 7 | + - vdd1-supply: I/O voltage supply | |
| 8 | + - reset-gpios: a GPIO spec for the reset pin (active low) | |
| 9 | + | |
| 10 | +The device node can contain one 'port' child node with one child | |
| 11 | +'endpoint' node, according to the bindings defined in | |
| 12 | +media/video-interfaces.txt. This node should describe panel's video bus. | |
| 13 | + | |
| 14 | +Example: | |
| 15 | +&dsi { | |
| 16 | + ... | |
| 17 | + | |
| 18 | + panel@0 { | |
| 19 | + compatible = "samsung,s6d16d0"; | |
| 20 | + reg = <0>; | |
| 21 | + vdd1-supply = <&foo>; | |
| 22 | + reset-gpios = <&foo_gpio 0 GPIO_ACTIVE_LOW>; | |
| 23 | + | |
| 24 | + port { | |
| 25 | + panel_in: endpoint { | |
| 26 | + remote-endpoint = <&dsi_out>; | |
| 27 | + }; | |
| 28 | + }; | |
| 29 | + }; | |
| 30 | +}; | |
| @@ -13,6 +13,7 @@ Required properties: · 12 unmodified lines | ||
| 13 | 13 | |
| 14 | 14 | - compatible: should be one of the following: |
| 15 | 15 | "rockchip,rk3288-dw-hdmi" |
| 16 | + "rockchip,rk3328-dw-hdmi" | |
| 16 | 17 | "rockchip,rk3399-dw-hdmi" |
| 17 | 18 | - reg: See dw_hdmi.txt. |
| 18 | 19 | - reg-io-width: See dw_hdmi.txt. Shall be 4. |
| @@ -34,6 +35,8 @@ Optional properties · 15 unmodified lines | ||
| 34 | 35 | - clock-names: May contain "cec" as defined in dw_hdmi.txt. |
| 35 | 36 | - clock-names: May contain "grf", power for grf io. |
| 36 | 37 | - clock-names: May contain "vpll", external clock for some hdmi phy. |
| 38 | +- phys: from general PHY binding: the phandle for the PHY device. | |
| 39 | +- phy-names: Should be "hdmi" if phys references an external phy. | |
| 37 | 40 | |
| 38 | 41 | Example: |
| 39 | 42 | |
| @@ -79,6 +79,7 @@ Required properties: · 78 unmodified lines | ||
| 79 | 79 | - compatible: value must be one of: |
| 80 | 80 | * "allwinner,sun8i-a83t-dw-hdmi" |
| 81 | 81 | * "allwinner,sun50i-a64-dw-hdmi", "allwinner,sun8i-a83t-dw-hdmi" |
| 82 | + * "allwinner,sun50i-h6-dw-hdmi" | |
| 82 | 83 | - reg: base address and size of memory-mapped region |
| 83 | 84 | - reg-io-width: See dw_hdmi.txt. Shall be 1. |
| 84 | 85 | - interrupts: HDMI interrupt number |
| @@ -86,9 +87,14 @@ Required properties: · 1 unmodified line | ||
| 86 | 87 | * iahb: the HDMI bus clock |
| 87 | 88 | * isfr: the HDMI register clock |
| 88 | 89 | * tmds: TMDS clock |
| 90 | + * cec: HDMI CEC clock (H6 only) | |
| 91 | + * hdcp: HDCP clock (H6 only) | |
| 92 | + * hdcp-bus: HDCP bus clock (H6 only) | |
| 89 | 93 | - clock-names: the clock names mentioned above |
| 90 | − - resets: phandle to the reset controller | |
| 91 | − - reset-names: must be "ctrl" | |
| 94 | + - resets: | |
| 95 | + * ctrl: HDMI controller reset | |
| 96 | + * hdcp: HDCP reset (H6 only) | |
| 97 | + - reset-names: reset names mentioned above | |
| 92 | 98 | - phys: phandle to the DWC HDMI PHY |
| 93 | 99 | - phy-names: must be "phy" |
| 94 | 100 | |
| @@ -109,6 +115,7 @@ Required properties: · 14 unmodified lines | ||
| 109 | 115 | * allwinner,sun8i-h3-hdmi-phy |
| 110 | 116 | * allwinner,sun8i-r40-hdmi-phy |
| 111 | 117 | * allwinner,sun50i-a64-hdmi-phy |
| 118 | + * allwinner,sun50i-h6-hdmi-phy | |
| 112 | 119 | - reg: base address and size of memory-mapped region |
| 113 | 120 | - clocks: phandles to the clocks feeding the HDMI PHY |
| 114 | 121 | * bus: the HDMI PHY interface clock |
| @@ -158,6 +165,7 @@ Required properties: · 43 unmodified lines | ||
| 158 | 165 | * allwinner,sun9i-a80-tcon-tv |
| 159 | 166 | * "allwinner,sun50i-a64-tcon-lcd", "allwinner,sun8i-a83t-tcon-lcd" |
| 160 | 167 | * "allwinner,sun50i-a64-tcon-tv", "allwinner,sun8i-a83t-tcon-tv" |
| 168 | + * allwinner,sun50i-h6-tcon-tv, allwinner,sun8i-r40-tcon-tv | |
| 161 | 169 | - reg: base address and size of memory-mapped region |
| 162 | 170 | - interrupts: interrupt associated to this IP |
| 163 | 171 | - clocks: phandles to the clocks feeding the TCON. |
| @@ -220,24 +228,26 @@ It allows display pipeline to be configured in very different ways: · 56 unmodified lines | ||
| 220 | 228 | \ [3] TCON-TV1 [1] - TVE1/RGB |
| 221 | 229 | |
| 222 | 230 | Note that both TCON TOP references same physical unit. Both mixers can be |
| 223 | −connected to any TCON. | |
| 231 | +connected to any TCON. Not all TCON TOP variants support all features. | |
| 224 | 232 | |
| 225 | 233 | Required properties: |
| 226 | 234 | - compatible: value must be one of: |
| 227 | 235 | * allwinner,sun8i-r40-tcon-top |
| 236 | + * allwinner,sun50i-h6-tcon-top | |
| 228 | 237 | - reg: base address and size of the memory-mapped region. |
| 229 | 238 | - clocks: phandle to the clocks feeding the TCON TOP |
| 230 | 239 | * bus: TCON TOP interface clock |
| 231 | 240 | * tcon-tv0: TCON TV0 clock |
| 232 | − * tve0: TVE0 clock | |
| 233 | − * tcon-tv1: TCON TV1 clock | |
| 234 | − * tve1: TVE0 clock | |
| 235 | − * dsi: MIPI DSI clock | |
| 241 | + * tve0: TVE0 clock (R40 only) | |
| 242 | + * tcon-tv1: TCON TV1 clock (R40 only) | |
| 243 | + * tve1: TVE0 clock (R40 only) | |
| 244 | + * dsi: MIPI DSI clock (R40 only) | |
| 236 | 245 | - clock-names: clock name mentioned above |
| 237 | 246 | - resets: phandle to the reset line driving the TCON TOP |
| 238 | 247 | - #clock-cells : must contain 1 |
| 239 | 248 | - clock-output-names: Names of clocks created for TCON TV0 channel clock, |
| 240 | − TCON TV1 channel clock and DSI channel clock, in that order. | |
| 249 | + TCON TV1 channel clock (R40 only) and DSI channel clock (R40 only), in | |
| 250 | + that order. | |
| 241 | 251 | |
| 242 | 252 | - ports: A ports node with endpoint definitions as defined in |
| 243 | 253 | Documentation/devicetree/bindings/media/video-interfaces.txt. 6 ports should |
| @@ -381,6 +391,7 @@ Required properties: · 137 unmodified lines | ||
| 381 | 391 | * allwinner,sun8i-v3s-de2-mixer |
| 382 | 392 | * allwinner,sun50i-a64-de2-mixer-0 |
| 383 | 393 | * allwinner,sun50i-a64-de2-mixer-1 |
| 394 | + * allwinner,sun50i-h6-de3-mixer-0 | |
| 384 | 395 | - reg: base address and size of the memory-mapped region. |
| 385 | 396 | - clocks: phandles to the clocks feeding the mixer |
| 386 | 397 | * bus: the mixer interface clock |
| @@ -415,9 +426,10 @@ Required properties: · 28 unmodified lines | ||
| 415 | 426 | * allwinner,sun8i-v3s-display-engine |
| 416 | 427 | * allwinner,sun9i-a80-display-engine |
| 417 | 428 | * allwinner,sun50i-a64-display-engine |
| 429 | + * allwinner,sun50i-h6-display-engine | |
| 418 | 430 | |
| 419 | 431 | - allwinner,pipelines: list of phandle to the display engine |
| 420 | − frontends (DE 1.0) or mixers (DE 2.0) available. | |
| 432 | + frontends (DE 1.0) or mixers (DE 2.0/3.0) available. | |
| 421 | 433 | |
| 422 | 434 | Example: |
| 423 | 435 | |
| @@ -0,0 +1,59 @@ | ||
| 1 | +Truly model NT35597 DSI display driver | |
| 2 | + | |
| 3 | +The Truly NT35597 is a generic display driver, currently only configured | |
| 4 | +for use in the 2K display on the Qualcomm SDM845 MTP board. | |
| 5 | + | |
| 6 | +Required properties: | |
| 7 | +- compatible: should be "truly,nt35597-2K-display" | |
| 8 | +- vdda-supply: phandle of the regulator that provides the supply voltage | |
| 9 | + Power IC supply | |
| 10 | +- vdispp-supply: phandle of the regulator that provides the supply voltage | |
| 11 | + for positive LCD bias | |
| 12 | +- vdispn-supply: phandle of the regulator that provides the supply voltage | |
| 13 | + for negative LCD bias | |
| 14 | +- reset-gpios: phandle of gpio for reset line | |
| 15 | + This should be 8mA, gpio can be configured using mux, pinctrl, pinctrl-names | |
| 16 | + (active low) | |
| 17 | +- mode-gpios: phandle of the gpio for choosing the mode of the display | |
| 18 | + for single DSI or Dual DSI | |
| 19 | + This should be low for dual DSI and high for single DSI mode | |
| 20 | +- ports: This device has two video ports driven by two DSIs. Their connections | |
| 21 | + are modeled using the OF graph bindings specified in | |
| 22 | + Documentation/devicetree/bindings/graph.txt. | |
| 23 | + - port@0: DSI input port driven by master DSI | |
| 24 | + - port@1: DSI input port driven by secondary DSI | |
| 25 | + | |
| 26 | +Example: | |
| 27 | + | |
| 28 | + dsi@ae94000 { | |
| 29 | + panel@0 { | |
| 30 | + compatible = "truly,nt35597-2K-display"; | |
| 31 | + reg = <0>; | |
| 32 | + vdda-supply = <&pm8998_l14>; | |
| 33 | + vdispp-supply = <&lab_regulator>; | |
| 34 | + vdispn-supply = <&ibb_regulator>; | |
| 35 | + pinctrl-names = "default", "suspend"; | |
| 36 | + pinctrl-0 = <&dpu_dsi_active>; | |
| 37 | + pinctrl-1 = <&dpu_dsi_suspend>; | |
| 38 | + | |
| 39 | + reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>; | |
| 40 | + mode-gpios = <&tlmm 52 GPIO_ACTIVE_HIGH>; | |
| 41 | + ports { | |
| 42 | + #address-cells = <1>; | |
| 43 | + #size-cells = <0>; | |
| 44 | + port@0 { | |
| 45 | + reg = <0>; | |
| 46 | + panel0_in: endpoint { | |
| 47 | + remote-endpoint = <&dsi0_out>; | |
| 48 | + }; | |
| 49 | + }; | |
| 50 | + | |
| 51 | + port@1 { | |
| 52 | + reg = <1>; | |
| 53 | + panel1_in: endpoint { | |
| 54 | + remote-endpoint = <&dsi1_out>; | |
| 55 | + }; | |
| 56 | + }; | |
| 57 | + }; | |
| 58 | + }; | |
| 59 | + }; | |
| @@ -2,8 +2,13 @@ · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | |
| 5 | −- compatible: Should be "ingenic,jz4780-dma" | |
| 6 | −- reg: Should contain the DMA controller registers location and length. | |
| 5 | +- compatible: Should be one of: | |
| 6 | + * ingenic,jz4740-dma | |
| 7 | + * ingenic,jz4725b-dma | |
| 8 | + * ingenic,jz4770-dma | |
| 9 | + * ingenic,jz4780-dma | |
| 10 | +- reg: Should contain the DMA channel registers location and length, followed | |
| 11 | + by the DMA controller registers location and length. | |
| 7 | 12 | - interrupts: Should contain the interrupt specifier of the DMA controller. |
| 8 | 13 | - clocks: Should contain a clock specifier for the JZ4780 PDMA clock. |
| 9 | 14 | - #dma-cells: Must be <2>. Number of integer cells in the dmas property of |
| @@ -19,9 +24,10 @@ Optional properties: · 9 unmodified lines | ||
| 19 | 24 | |
| 20 | 25 | Example: |
| 21 | 26 | |
| 22 | −dma: dma@13420000 { | |
| 27 | +dma: dma-controller@13420000 { | |
| 23 | 28 | compatible = "ingenic,jz4780-dma"; |
| 24 | − reg = <0x13420000 0x10000>; | |
| 29 | + reg = <0x13420000 0x400 | |
| 30 | + 0x13421000 0x40>; | |
| 25 | 31 | |
| 26 | 32 | interrupt-parent = <&intc>; |
| 27 | 33 | interrupts = <10>; |
| @@ -17,6 +17,7 @@ Required Properties: · 16 unmodified lines | ||
| 17 | 17 | - compatible: "renesas,dmac-<soctype>", "renesas,rcar-dmac" as fallback. |
| 18 | 18 | Examples with soctypes are: |
| 19 | 19 | - "renesas,dmac-r8a7743" (RZ/G1M) |
| 20 | + - "renesas,dmac-r8a7744" (RZ/G1N) | |
| 20 | 21 | - "renesas,dmac-r8a7745" (RZ/G1E) |
| 21 | 22 | - "renesas,dmac-r8a77470" (RZ/G1C) |
| 22 | 23 | - "renesas,dmac-r8a7790" (R-Car H2) |
| @@ -4,6 +4,7 @@ Required Properties: · 3 unmodified lines | ||
| 4 | 4 | -compatible: "renesas,<soctype>-usb-dmac", "renesas,usb-dmac" as fallback. |
| 5 | 5 | Examples with soctypes are: |
| 6 | 6 | - "renesas,r8a7743-usb-dmac" (RZ/G1M) |
| 7 | + - "renesas,r8a7744-usb-dmac" (RZ/G1N) | |
| 7 | 8 | - "renesas,r8a7745-usb-dmac" (RZ/G1E) |
| 8 | 9 | - "renesas,r8a7790-usb-dmac" (R-Car H2) |
| 9 | 10 | - "renesas,r8a7791-usb-dmac" (R-Car M2-W) |
| @@ -7,16 +7,23 @@ assorted actions. · 6 unmodified lines | ||
| 7 | 7 | |
| 8 | 8 | Required properties: |
| 9 | 9 | - compatible: must contain one of the following: |
| 10 | − * "qcom,scm-apq8064" for APQ8064 platforms | |
| 11 | − * "qcom,scm-msm8660" for MSM8660 platforms | |
| 12 | − * "qcom,scm-msm8690" for MSM8690 platforms | |
| 13 | − * "qcom,scm-msm8996" for MSM8996 platforms | |
| 14 | − * "qcom,scm-ipq4019" for IPQ4019 platforms | |
| 15 | − * "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc) | |
| 16 | −- clocks: One to three clocks may be required based on compatible. | |
| 17 | − * No clock required for "qcom,scm-msm8996", "qcom,scm-ipq4019" | |
| 18 | − * Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and "qcom,scm-msm8960" | |
| 19 | − * Core, iface, and bus clocks required for "qcom,scm" | |
| 10 | + * "qcom,scm-apq8064" | |
| 11 | + * "qcom,scm-apq8084" | |
| 12 | + * "qcom,scm-msm8660" | |
| 13 | + * "qcom,scm-msm8916" | |
| 14 | + * "qcom,scm-msm8960" | |
| 15 | + * "qcom,scm-msm8974" | |
| 16 | + * "qcom,scm-msm8996" | |
| 17 | + * "qcom,scm-msm8998" | |
| 18 | + * "qcom,scm-ipq4019" | |
| 19 | + * "qcom,scm-sdm845" | |
| 20 | + and: | |
| 21 | + * "qcom,scm" | |
| 22 | +- clocks: Specifies clocks needed by the SCM interface, if any: | |
| 23 | + * core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660" and | |
| 24 | + "qcom,scm-msm8960" | |
| 25 | + * core, iface and bus clocks required for "qcom,scm-apq8084", | |
| 26 | + "qcom,scm-msm8916" and "qcom,scm-msm8974" | |
| 20 | 27 | - clock-names: Must contain "core" for the core clock, "iface" for the interface |
| 21 | 28 | clock and "bus" for the bus clock per the requirements of the compatible. |
| 22 | 29 | - qcom,dload-mode: phandle to the TCSR hardware block and offset of the |
| @@ -26,8 +33,10 @@ Example for MSM8916: · 3 unmodified lines | ||
| 26 | 33 | |
| 27 | 34 | firmware { |
| 28 | 35 | scm { |
| 29 | − compatible = "qcom,scm"; | |
| 30 | − clocks = <&gcc GCC_CRYPTO_CLK> , <&gcc GCC_CRYPTO_AXI_CLK>, <&gcc GCC_CRYPTO_AHB_CLK>; | |
| 36 | + compatible = "qcom,msm8916", "qcom,scm"; | |
| 37 | + clocks = <&gcc GCC_CRYPTO_CLK> , | |
| 38 | + <&gcc GCC_CRYPTO_AXI_CLK>, | |
| 39 | + <&gcc GCC_CRYPTO_AHB_CLK>; | |
| 31 | 40 | clock-names = "core", "bus", "iface"; |
| 32 | 41 | }; |
| 33 | 42 | }; |
| @@ -0,0 +1,82 @@ | ||
| 1 | +----------------------------------------------------------------- | |
| 2 | +Device Tree Bindings for the Xilinx Zynq MPSoC Firmware Interface | |
| 3 | +----------------------------------------------------------------- | |
| 4 | + | |
| 5 | +The zynqmp-firmware node describes the interface to platform firmware. | |
| 6 | +ZynqMP has an interface to communicate with secure firmware. Firmware | |
| 7 | +driver provides an interface to firmware APIs. Interface APIs can be | |
| 8 | +used by any driver to communicate to PMUFW(Platform Management Unit). | |
| 9 | +These requests include clock management, pin control, device control, | |
| 10 | +power management service, FPGA service and other platform management | |
| 11 | +services. | |
| 12 | + | |
| 13 | +Required properties: | |
| 14 | + - compatible: Must contain: "xlnx,zynqmp-firmware" | |
| 15 | + - method: The method of calling the PM-API firmware layer. | |
| 16 | + Permitted values are: | |
| 17 | + - "smc" : SMC #0, following the SMCCC | |
| 18 | + - "hvc" : HVC #0, following the SMCCC | |
| 19 | + | |
| 20 | +-------------------------------------------------------------------------- | |
| 21 | +Device Tree Clock bindings for the Zynq Ultrascale+ MPSoC controlled using | |
| 22 | +Zynq MPSoC firmware interface | |
| 23 | +-------------------------------------------------------------------------- | |
| 24 | +The clock controller is a h/w block of Zynq Ultrascale+ MPSoC clock | |
| 25 | +tree. It reads required input clock frequencies from the devicetree and acts | |
| 26 | +as clock provider for all clock consumers of PS clocks. | |
| 27 | + | |
| 28 | +See clock_bindings.txt for more information on the generic clock bindings. | |
| 29 | + | |
| 30 | +Required properties: | |
| 31 | + - #clock-cells: Must be 1 | |
| 32 | + - compatible: Must contain: "xlnx,zynqmp-clk" | |
| 33 | + - clocks: List of clock specifiers which are external input | |
| 34 | + clocks to the given clock controller. Please refer | |
| 35 | + the next section to find the input clocks for a | |
| 36 | + given controller. | |
| 37 | + - clock-names: List of clock names which are exteral input clocks | |
| 38 | + to the given clock controller. Please refer to the | |
| 39 | + clock bindings for more details. | |
| 40 | + | |
| 41 | +Input clocks for zynqmp Ultrascale+ clock controller: | |
| 42 | + | |
| 43 | +The Zynq UltraScale+ MPSoC has one primary and four alternative reference clock | |
| 44 | +inputs. These required clock inputs are: | |
| 45 | + - pss_ref_clk (PS reference clock) | |
| 46 | + - video_clk (reference clock for video system ) | |
| 47 | + - pss_alt_ref_clk (alternative PS reference clock) | |
| 48 | + - aux_ref_clk | |
| 49 | + - gt_crx_ref_clk (transceiver reference clock) | |
| 50 | + | |
| 51 | +The following strings are optional parameters to the 'clock-names' property in | |
| 52 | +order to provide an optional (E)MIO clock source: | |
| 53 | + - swdt0_ext_clk | |
| 54 | + - swdt1_ext_clk | |
| 55 | + - gem0_emio_clk | |
| 56 | + - gem1_emio_clk | |
| 57 | + - gem2_emio_clk | |
| 58 | + - gem3_emio_clk | |
| 59 | + - mio_clk_XX # with XX = 00..77 | |
| 60 | + - mio_clk_50_or_51 #for the mux clock to gem tsu from 50 or 51 | |
| 61 | + | |
| 62 | + | |
| 63 | +Output clocks are registered based on clock information received | |
| 64 | +from firmware. Output clocks indexes are mentioned in | |
| 65 | +include/dt-bindings/clock/xlnx,zynqmp-clk.h. | |
| 66 | + | |
| 67 | +------- | |
| 68 | +Example | |
| 69 | +------- | |
| 70 | + | |
| 71 | +firmware { | |
| 72 | + zynqmp_firmware: zynqmp-firmware { | |
| 73 | + compatible = "xlnx,zynqmp-firmware"; | |
| 74 | + method = "smc"; | |
| 75 | + zynqmp_clk: clock-controller { | |
| 76 | + #clock-cells = <1>; | |
| 77 | + compatible = "xlnx,zynqmp-clk"; | |
| 78 | + clocks = <&pss_ref_clk>, <&video_clk>, <&pss_alt_ref_clk>, <&aux_ref_clk>, <>_crx_ref_clk>; | |
| 79 | + clock-names = "pss_ref_clk", "video_clk", "pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk"; | |
| 80 | + }; | |
| 81 | + }; | |
| 82 | +}; | |
| @@ -415,7 +415,7 @@ DT Overlay contains: · 414 unmodified lines | ||
| 415 | 415 | firmware-name = "base.rbf"; |
| 416 | 416 | |
| 417 | 417 | fpga-bridge@4400 { |
| 418 | − compatible = "altr,freeze-bridge"; | |
| 418 | + compatible = "altr,freeze-bridge-controller"; | |
| 419 | 419 | reg = <0x4400 0x10>; |
| 420 | 420 | |
| 421 | 421 | fpga_region1: fpga-region1 { |
| @@ -427,7 +427,7 @@ DT Overlay contains: · 5 unmodified lines | ||
| 427 | 427 | }; |
| 428 | 428 | |
| 429 | 429 | fpga-bridge@4420 { |
| 430 | − compatible = "altr,freeze-bridge"; | |
| 430 | + compatible = "altr,freeze-bridge-controller"; | |
| 431 | 431 | reg = <0x4420 0x10>; |
| 432 | 432 | |
| 433 | 433 | fpga_region2: fpga-region2 { |
| @@ -1,18 +1,9 @@ | ||
| 1 | 1 | Specifying GPIO information for devices |
| 2 | −============================================ | |
| 2 | +======================================= | |
| 3 | 3 | |
| 4 | 4 | 1) gpios property |
| 5 | 5 | ----------------- |
| 6 | 6 | |
| 7 | −Nodes that makes use of GPIOs should specify them using one or more | |
| 8 | −properties, each containing a 'gpio-list': | |
| 9 | − | |
| 10 | − gpio-list ::= <single-gpio> [gpio-list] | |
| 11 | − single-gpio ::= <gpio-phandle> <gpio-specifier> | |
| 12 | − gpio-phandle : phandle to gpio controller node | |
| 13 | − gpio-specifier : Array of #gpio-cells specifying specific gpio | |
| 14 | − (controller specific) | |
| 15 | − | |
| 16 | 7 | GPIO properties should be named "[<name>-]gpios", with <name> being the purpose |
| 17 | 8 | of this GPIO for the device. While a non-existent <name> is considered valid |
| 18 | 9 | for compatibility reasons (resolving to the "gpios" property), it is not allowed |
| @@ -33,33 +24,27 @@ The following example could be used to describe GPIO pins used as device enable · 14 unmodified lines | ||
| 33 | 24 | and bit-banged data signals: |
| 34 | 25 | |
| 35 | 26 | gpio1: gpio1 { |
| 36 | − gpio-controller | |
| 37 | − #gpio-cells = <2>; | |
| 38 | − }; | |
| 39 | − gpio2: gpio2 { | |
| 40 | − gpio-controller | |
| 41 | − #gpio-cells = <1>; | |
| 27 | + gpio-controller; | |
| 28 | + #gpio-cells = <2>; | |
| 42 | 29 | }; |
| 43 | 30 | [...] |
| 44 | 31 | |
| 45 | − enable-gpios = <&gpio2 2>; | |
| 46 | 32 | data-gpios = <&gpio1 12 0>, |
| 47 | 33 | <&gpio1 13 0>, |
| 48 | 34 | <&gpio1 14 0>, |
| 49 | 35 | <&gpio1 15 0>; |
| 50 | 36 | |
| 51 | −Note that gpio-specifier length is controller dependent. In the | |
| 52 | −above example, &gpio1 uses 2 cells to specify a gpio, while &gpio2 | |
| 53 | −only uses one. | |
| 37 | +In the above example, &gpio1 uses 2 cells to specify a gpio. The first cell is | |
| 38 | +a local offset to the GPIO line and the second cell represent consumer flags, | |
| 39 | +such as if the consumer desire the line to be active low (inverted) or open | |
| 40 | +drain. This is the recommended practice. | |
| 54 | 41 | |
| 55 | −gpio-specifier may encode: bank, pin position inside the bank, | |
| 56 | −whether pin is open-drain and whether pin is logically inverted. | |
| 42 | +The exact meaning of each specifier cell is controller specific, and must be | |
| 43 | +documented in the device tree binding for the device, but it is strongly | |
| 44 | +recommended to use the two-cell approach. | |
| 57 | 45 | |
| 58 | −Exact meaning of each specifier cell is controller specific, and must | |
| 59 | −be documented in the device tree binding for the device. | |
| 60 | − | |
| 61 | −Most controllers are however specifying a generic flag bitfield | |
| 62 | −in the last cell, so for these, use the macros defined in | |
| 46 | +Most controllers are specifying a generic flag bitfield in the last cell, so | |
| 47 | +for these, use the macros defined in | |
| 63 | 48 | include/dt-bindings/gpio/gpio.h whenever possible: |
| 64 | 49 | |
| 65 | 50 | Example of a node using GPIOs: |
| @@ -236,46 +221,40 @@ Example of two SOC GPIO banks defined as gpio-controller nodes: · 170 unmodified lines | ||
| 236 | 221 | |
| 237 | 222 | Some or all of the GPIOs provided by a GPIO controller may be routed to pins |
| 238 | 223 | on the package via a pin controller. This allows muxing those pins between |
| 239 | −GPIO and other functions. | |
| 224 | +GPIO and other functions. It is a fairly common practice among silicon | |
| 225 | +engineers. | |
| 226 | + | |
| 227 | +2.2) Ordinary (numerical) GPIO ranges | |
| 228 | +------------------------------------- | |
| 240 | 229 | |
| 241 | 230 | It is useful to represent which GPIOs correspond to which pins on which pin |
| 242 | −controllers. The gpio-ranges property described below represents this, and | |
| 243 | −contains information structures as follows: | |
| 244 | − | |
| 245 | − gpio-range-list ::= <single-gpio-range> [gpio-range-list] | |
| 246 | − single-gpio-range ::= <numeric-gpio-range> | <named-gpio-range> | |
| 247 | − numeric-gpio-range ::= | |
| 248 | − <pinctrl-phandle> <gpio-base> <pinctrl-base> <count> | |
| 249 | − named-gpio-range ::= <pinctrl-phandle> <gpio-base> '<0 0>' | |
| 250 | − pinctrl-phandle : phandle to pin controller node | |
| 251 | − gpio-base : Base GPIO ID in the GPIO controller | |
| 252 | − pinctrl-base : Base pinctrl pin ID in the pin controller | |
| 253 | − count : The number of GPIOs/pins in this range | |
| 254 | − | |
| 255 | −The "pin controller node" mentioned above must conform to the bindings | |
| 256 | −described in ../pinctrl/pinctrl-bindings.txt. | |
| 257 | − | |
| 258 | −In case named gpio ranges are used (ranges with both <pinctrl-base> and | |
| 259 | −<count> set to 0), the property gpio-ranges-group-names contains one string | |
| 260 | −for every single-gpio-range in gpio-ranges: | |
| 261 | − gpiorange-names-list ::= <gpiorange-name> [gpiorange-names-list] | |
| 262 | − gpiorange-name : Name of the pingroup associated to the GPIO range in | |
| 263 | − the respective pin controller. | |
| 264 | − | |
| 265 | −Elements of gpiorange-names-list corresponding to numeric ranges contain | |
| 266 | −the empty string. Elements of gpiorange-names-list corresponding to named | |
| 267 | −ranges contain the name of a pin group defined in the respective pin | |
| 268 | −controller. The number of pins/GPIOs in the range is the number of pins in | |
| 269 | −that pin group. | |
| 231 | +controllers. The gpio-ranges property described below represents this with | |
| 232 | +a discrete set of ranges mapping pins from the pin controller local number space | |
| 233 | +to pins in the GPIO controller local number space. | |
| 270 | 234 | |
| 271 | −Previous versions of this binding required all pin controller nodes that | |
| 272 | −were referenced by any gpio-ranges property to contain a property named | |
| 273 | −#gpio-range-cells with value <3>. This requirement is now deprecated. | |
| 274 | −However, that property may still exist in older device trees for | |
| 275 | −compatibility reasons, and would still be required even in new device | |
| 276 | −trees that need to be compatible with older software. | |
| 235 | +The format is: <[pin controller phandle], [GPIO controller offset], | |
| 236 | + [pin controller offset], [number of pins]>; | |
| 237 | + | |
| 238 | +The GPIO controller offset pertains to the GPIO controller node containing the | |
| 239 | +range definition. | |
| 240 | + | |
| 241 | +The pin controller node referenced by the phandle must conform to the bindings | |
| 242 | +described in pinctrl/pinctrl-bindings.txt. | |
| 243 | + | |
| 244 | +Each offset runs from 0 to N. It is perfectly fine to pile any number of | |
| 245 | +ranges with just one pin-to-GPIO line mapping if the ranges are concocted, but | |
| 246 | +in practice these ranges are often lumped in discrete sets. | |
| 247 | + | |
| 248 | +Example: | |
| 249 | + | |
| 250 | + gpio-ranges = <&foo 0 20 10>, <&bar 10 50 20>; | |
| 277 | 251 | |
| 278 | −Example 1: | |
| 252 | +This means: | |
| 253 | +- pins 20..29 on pin controller "foo" is mapped to GPIO line 0..9 and | |
| 254 | +- pins 50..69 on pin controller "bar" is mapped to GPIO line 10..29 | |
| 255 | + | |
| 256 | + | |
| 257 | +Verbose example: | |
| 279 | 258 | |
| 280 | 259 | qe_pio_e: gpio-controller@1460 { |
| 281 | 260 | #gpio-cells = <2>; |
| @@ -289,7 +268,28 @@ Here, a single GPIO controller has GPIOs 0..9 routed to pin controller · 7 unmodified lines | ||
| 289 | 268 | pinctrl1's pins 20..29, and GPIOs 10..29 routed to pin controller pinctrl2's |
| 290 | 269 | pins 50..69. |
| 291 | 270 | |
| 292 | −Example 2: | |
| 271 | + | |
| 272 | +2.3) GPIO ranges from named pin groups | |
| 273 | +-------------------------------------- | |
| 274 | + | |
| 275 | +It is also possible to use pin groups for gpio ranges when pin groups are the | |
| 276 | +easiest and most convenient mapping. | |
| 277 | + | |
| 278 | +Both both <pinctrl-base> and <count> must set to 0 when using named pin groups | |
| 279 | +names. | |
| 280 | + | |
| 281 | +The property gpio-ranges-group-names must contain exactly one string for each | |
| 282 | +range. | |
| 283 | + | |
| 284 | +Elements of gpio-ranges-group-names must contain the name of a pin group | |
| 285 | +defined in the respective pin controller. The number of pins/GPIO lines in the | |
| 286 | +range is the number of pins in that pin group. The number of pins of that | |
| 287 | +group is defined int the implementation and not in the device tree. | |
| 288 | + | |
| 289 | +If numerical and named pin groups are mixed, the string corresponding to a | |
| 290 | +numerical pin range in gpio-ranges-group-names must be empty. | |
| 291 | + | |
| 292 | +Example: | |
| 293 | 293 | |
| 294 | 294 | gpio_pio_i: gpio-controller@14b0 { |
| 295 | 295 | #gpio-cells = <2>; |
| @@ -306,6 +306,14 @@ Example 2: · 10 unmodified lines | ||
| 306 | 306 | "bar"; |
| 307 | 307 | }; |
| 308 | 308 | |
| 309 | −Here, three GPIO ranges are defined wrt. two pin controllers. pinctrl1 GPIO | |
| 310 | −ranges are defined using pin numbers whereas the GPIO ranges wrt. pinctrl2 | |
| 311 | −are named "foo" and "bar". | |
| 309 | +Here, three GPIO ranges are defined referring to two pin controllers. | |
| 310 | + | |
| 311 | +pinctrl1 GPIO ranges are defined using pin numbers whereas the GPIO ranges | |
| 312 | +in pinctrl2 are defined using the pin groups named "foo" and "bar". | |
| 313 | + | |
| 314 | +Previous versions of this binding required all pin controller nodes that | |
| 315 | +were referenced by any gpio-ranges property to contain a property named | |
| 316 | +#gpio-range-cells with value <3>. This requirement is now deprecated. | |
| 317 | +However, that property may still exist in older device trees for | |
| 318 | +compatibility reasons, and would still be required even in new device | |
| 319 | +trees that need to be compatible with older software. | |
| @@ -1,46 +0,0 @@ | ||
| 1 | −Ingenic jz47xx GPIO controller | |
| 2 | − | |
| 3 | −That the Ingenic GPIO driver node must be a sub-node of the Ingenic pinctrl | |
| 4 | −driver node. | |
| 5 | − | |
| 6 | −Required properties: | |
| 7 | −-------------------- | |
| 8 | − | |
| 9 | − - compatible: Must contain one of: | |
| 10 | − - "ingenic,jz4740-gpio" | |
| 11 | − - "ingenic,jz4770-gpio" | |
| 12 | − - "ingenic,jz4780-gpio" | |
| 13 | − - reg: The GPIO bank number. | |
| 14 | − - interrupt-controller: Marks the device node as an interrupt controller. | |
| 15 | − - interrupts: Interrupt specifier for the controllers interrupt. | |
| 16 | − - #interrupt-cells: Should be 2. Refer to | |
| 17 | − ../interrupt-controller/interrupts.txt for more details. | |
| 18 | − - gpio-controller: Marks the device node as a GPIO controller. | |
| 19 | − - #gpio-cells: Should be 2. The first cell is the GPIO number and the second | |
| 20 | − cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the | |
| 21 | − GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported. | |
| 22 | − - gpio-ranges: Range of pins managed by the GPIO controller. Refer to | |
| 23 | − 'gpio.txt' in this directory for more details. | |
| 24 | − | |
| 25 | −Example: | |
| 26 | −-------- | |
| 27 | − | |
| 28 | −&pinctrl { | |
| 29 | − #address-cells = <1>; | |
| 30 | − #size-cells = <0>; | |
| 31 | − | |
| 32 | − gpa: gpio@0 { | |
| 33 | − compatible = "ingenic,jz4740-gpio"; | |
| 34 | − reg = <0>; | |
| 35 | − | |
| 36 | − gpio-controller; | |
| 37 | − gpio-ranges = <&pinctrl 0 0 32>; | |
| 38 | − #gpio-cells = <2>; | |
| 39 | − | |
| 40 | − interrupt-controller; | |
| 41 | − #interrupt-cells = <2>; | |
| 42 | − | |
| 43 | − interrupt-parent = <&intc>; | |
| 44 | − interrupts = <28>; | |
| 45 | − }; | |
| 46 | −}; | |
| @@ -4,8 +4,10 @@ Required Properties: · 3 unmodified lines | ||
| 4 | 4 | |
| 5 | 5 | - compatible: should contain one or more of the following: |
| 6 | 6 | - "renesas,gpio-r8a7743": for R8A7743 (RZ/G1M) compatible GPIO controller. |
| 7 | + - "renesas,gpio-r8a7744": for R8A7744 (RZ/G1N) compatible GPIO controller. | |
| 7 | 8 | - "renesas,gpio-r8a7745": for R8A7745 (RZ/G1E) compatible GPIO controller. |
| 8 | 9 | - "renesas,gpio-r8a77470": for R8A77470 (RZ/G1C) compatible GPIO controller. |
| 10 | + - "renesas,gpio-r8a774a1": for R8A774A1 (RZ/G2M) compatible GPIO controller. | |
| 9 | 11 | - "renesas,gpio-r8a7778": for R8A7778 (R-Car M1) compatible GPIO controller. |
| 10 | 12 | - "renesas,gpio-r8a7779": for R8A7779 (R-Car H1) compatible GPIO controller. |
| 11 | 13 | - "renesas,gpio-r8a7790": for R8A7790 (R-Car H2) compatible GPIO controller. |
| @@ -22,7 +24,7 @@ Required Properties: · 10 unmodified lines | ||
| 22 | 24 | - "renesas,gpio-r8a77995": for R8A77995 (R-Car D3) compatible GPIO controller. |
| 23 | 25 | - "renesas,rcar-gen1-gpio": for a generic R-Car Gen1 GPIO controller. |
| 24 | 26 | - "renesas,rcar-gen2-gpio": for a generic R-Car Gen2 or RZ/G1 GPIO controller. |
| 25 | − - "renesas,rcar-gen3-gpio": for a generic R-Car Gen3 GPIO controller. | |
| 27 | + - "renesas,rcar-gen3-gpio": for a generic R-Car Gen3 or RZ/G2 GPIO controller. | |
| 26 | 28 | - "renesas,gpio-rcar": deprecated. |
| 27 | 29 | |
| 28 | 30 | When compatible with the generic version nodes must list the |
| @@ -38,7 +40,7 @@ Required Properties: · 9 unmodified lines | ||
| 38 | 40 | - #gpio-cells: Should be 2. The first cell is the GPIO number and the second |
| 39 | 41 | cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the |
| 40 | 42 | GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported. |
| 41 | − - gpio-ranges: Range of pins managed by the GPIO controller. | |
| 43 | + - gpio-ranges: See gpio.txt. | |
| 42 | 44 | |
| 43 | 45 | Optional properties: |
| 44 | 46 | |
| @@ -46,35 +48,44 @@ Optional properties: · 1 unmodified line | ||
| 46 | 48 | mandatory if the hardware implements a controllable functional clock for |
| 47 | 49 | the GPIO instance. |
| 48 | 50 | |
| 49 | −Please refer to gpio.txt in this directory for details of gpio-ranges property | |
| 50 | −and the common GPIO bindings used by client devices. | |
| 51 | + - gpio-reserved-ranges: See gpio.txt. | |
| 52 | + | |
| 53 | +Please refer to gpio.txt in this directory for the common GPIO bindings used by | |
| 54 | +client devices. | |
| 51 | 55 | |
| 52 | 56 | The GPIO controller also acts as an interrupt controller. It uses the default |
| 53 | 57 | two cells specifier as described in Documentation/devicetree/bindings/ |
| 54 | 58 | interrupt-controller/interrupts.txt. |
| 55 | 59 | |
| 56 | −Example: R8A7779 (R-Car H1) GPIO controller nodes | |
| 60 | +Example: R8A77470 (RZ/G1C) GPIO controller nodes | |
| 57 | 61 | |
| 58 | − gpio0: gpio@ffc40000 { | |
| 59 | − compatible = "renesas,gpio-r8a7779", "renesas,rcar-gen1-gpio"; | |
| 60 | − reg = <0xffc40000 0x2c>; | |
| 61 | − interrupt-parent = <&gic>; | |
| 62 | − interrupts = <0 141 0x4>; | |
| 63 | − #gpio-cells = <2>; | |
| 64 | − gpio-controller; | |
| 65 | − gpio-ranges = <&pfc 0 0 32>; | |
| 66 | − interrupt-controller; | |
| 67 | − #interrupt-cells = <2>; | |
| 68 | − }; | |
| 62 | + gpio0: gpio@e6050000 { | |
| 63 | + compatible = "renesas,gpio-r8a77470", | |
| 64 | + "renesas,rcar-gen2-gpio"; | |
| 65 | + reg = <0 0xe6050000 0 0x50>; | |
| 66 | + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>; | |
| 67 | + #gpio-cells = <2>; | |
| 68 | + gpio-controller; | |
| 69 | + gpio-ranges = <&pfc 0 0 23>; | |
| 70 | + #interrupt-cells = <2>; | |
| 71 | + interrupt-controller; | |
| 72 | + clocks = <&cpg CPG_MOD 912>; | |
| 73 | + power-domains = <&sysc R8A77470_PD_ALWAYS_ON>; | |
| 74 | + resets = <&cpg 912>; | |
| 75 | + }; | |
| 69 | 76 | ... |
| 70 | − gpio6: gpio@ffc46000 { | |
| 71 | − compatible = "renesas,gpio-r8a7779", "renesas,rcar-gen1-gpio"; | |
| 72 | − reg = <0xffc46000 0x2c>; | |
| 73 | − interrupt-parent = <&gic>; | |
| 74 | − interrupts = <0 147 0x4>; | |
| 75 | − #gpio-cells = <2>; | |
| 76 | − gpio-controller; | |
| 77 | − gpio-ranges = <&pfc 0 192 9>; | |
| 78 | − interrupt-controller; | |
| 79 | − #interrupt-cells = <2>; | |
| 80 | − }; | |
| 77 | + gpio3: gpio@e6053000 { | |
| 78 | + compatible = "renesas,gpio-r8a77470", | |
| 79 | + "renesas,rcar-gen2-gpio"; | |
| 80 | + reg = <0 0xe6053000 0 0x50>; | |
| 81 | + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; | |
| 82 | + #gpio-cells = <2>; | |
| 83 | + gpio-controller; | |
| 84 | + gpio-ranges = <&pfc 0 96 30>; | |
| 85 | + gpio-reserved-ranges = <17 10>; | |
| 86 | + #interrupt-cells = <2>; | |
| 87 | + interrupt-controller; | |
| 88 | + clocks = <&cpg CPG_MOD 909>; | |
| 89 | + power-domains = <&sysc R8A77470_PD_ALWAYS_ON>; | |
| 90 | + resets = <&cpg 909>; | |
| 91 | + }; | |
| @@ -0,0 +1,21 @@ | ||
| 1 | +Synopsys GPIO via CREG (Control REGisters) driver | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible : "snps,creg-gpio-hsdk" or "snps,creg-gpio-axs10x". | |
| 5 | +- reg : Exactly one register range with length 0x4. | |
| 6 | +- #gpio-cells : Since the generic GPIO binding is used, the | |
| 7 | + amount of cells must be specified as 2. The first cell is the | |
| 8 | + pin number, the second cell is used to specify optional parameters: | |
| 9 | + See "gpio-specifier" in .../devicetree/bindings/gpio/gpio.txt. | |
| 10 | +- gpio-controller : Marks the device node as a GPIO controller. | |
| 11 | +- ngpios: Number of GPIO pins. | |
| 12 | + | |
| 13 | +Example: | |
| 14 | + | |
| 15 | +gpio: gpio@f00014b0 { | |
| 16 | + compatible = "snps,creg-gpio-hsdk"; | |
| 17 | + reg = <0xf00014b0 0x4>; | |
| 18 | + gpio-controller; | |
| 19 | + #gpio-cells = <2>; | |
| 20 | + ngpios = <2>; | |
| 21 | +}; | |
| @@ -0,0 +1,44 @@ | ||
| 1 | +Texas Instruments INA3221 Device Tree Bindings | |
| 2 | + | |
| 3 | +1) ina3221 node | |
| 4 | + Required properties: | |
| 5 | + - compatible: Must be "ti,ina3221" | |
| 6 | + - reg: I2C address | |
| 7 | + | |
| 8 | + Optional properties: | |
| 9 | + = The node contains optional child nodes for three channels = | |
| 10 | + = Each child node describes the information of input source = | |
| 11 | + | |
| 12 | + - #address-cells: Required only if a child node is present. Must be 1. | |
| 13 | + - #size-cells: Required only if a child node is present. Must be 0. | |
| 14 | + | |
| 15 | +2) child nodes | |
| 16 | + Required properties: | |
| 17 | + - reg: Must be 0, 1 or 2, corresponding to IN1, IN2 or IN3 port of INA3221 | |
| 18 | + | |
| 19 | + Optional properties: | |
| 20 | + - label: Name of the input source | |
| 21 | + - shunt-resistor-micro-ohms: Shunt resistor value in micro-Ohm | |
| 22 | + | |
| 23 | +Example: | |
| 24 | + | |
| 25 | +ina3221@40 { | |
| 26 | + compatible = "ti,ina3221"; | |
| 27 | + reg = <0x40>; | |
| 28 | + #address-cells = <1>; | |
| 29 | + #size-cells = <0>; | |
| 30 | + | |
| 31 | + input@0 { | |
| 32 | + reg = <0x0>; | |
| 33 | + status = "disabled"; | |
| 34 | + }; | |
| 35 | + input@1 { | |
| 36 | + reg = <0x1>; | |
| 37 | + shunt-resistor-micro-ohms = <5000>; | |
| 38 | + }; | |
| 39 | + input@2 { | |
| 40 | + reg = <0x2>; | |
| 41 | + label = "VDD_5V"; | |
| 42 | + shunt-resistor-micro-ohms = <5000>; | |
| 43 | + }; | |
| 44 | +}; | |
| @@ -15,6 +15,7 @@ Required properties: · 14 unmodified lines | ||
| 15 | 15 | * "lltc,ltm2987" |
| 16 | 16 | * "lltc,ltm4675" |
| 17 | 17 | * "lltc,ltm4676" |
| 18 | + * "lltc,ltm4686" | |
| 18 | 19 | - reg: I2C slave address |
| 19 | 20 | |
| 20 | 21 | Optional properties: |
| @@ -30,6 +31,7 @@ Valid names of regulators depend on number of supplies supported per device: · 9 unmodified lines | ||
| 30 | 31 | * ltc3880, ltc3882, ltc3886 : vout0 - vout1 |
| 31 | 32 | * ltc3883 : vout0 |
| 32 | 33 | * ltm4676 : vout0 - vout1 |
| 34 | + * ltm4686 : vout0 - vout1 | |
| 33 | 35 | |
| 34 | 36 | Example: |
| 35 | 37 | ltc2978@5e { |
| @@ -3,6 +3,7 @@ · 2 unmodified lines | ||
| 3 | 3 | Required properties : |
| 4 | 4 | |
| 5 | 5 | - compatible : should be "snps,designware-i2c" |
| 6 | + or "mscc,ocelot-i2c" with "snps,designware-i2c" for fallback | |
| 6 | 7 | - reg : Offset and length of the register set for the device |
| 7 | 8 | - interrupts : <IRQ> where IRQ is the interrupt number. |
| 8 | 9 | |
| @@ -11,8 +12,12 @@ Recommended properties : · 2 unmodified lines | ||
| 11 | 12 | - clock-frequency : desired I2C bus clock frequency in Hz. |
| 12 | 13 | |
| 13 | 14 | Optional properties : |
| 15 | + - reg : for "mscc,ocelot-i2c", a second register set to configure the SDA hold | |
| 16 | + time, named ICPU_CFG:TWI_DELAY in the datasheet. | |
| 17 | + | |
| 14 | 18 | - i2c-sda-hold-time-ns : should contain the SDA hold time in nanoseconds. |
| 15 | − This option is only supported in hardware blocks version 1.11a or newer. | |
| 19 | + This option is only supported in hardware blocks version 1.11a or newer and | |
| 20 | + on Microsemi SoCs ("mscc,ocelot-i2c" compatible). | |
| 16 | 21 | |
| 17 | 22 | - i2c-scl-falling-time-ns : should contain the SCL falling time in nanoseconds. |
| 18 | 23 | This value which is by default 300ns is used to compute the tLOW period. |
| @@ -3,6 +3,7 @@ · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible : |
| 5 | 5 | - "fsl,imx7ulp-lpi2c" for LPI2C compatible with the one integrated on i.MX7ULP soc |
| 6 | + - "fsl,imx8qxp-lpi2c" for LPI2C compatible with the one integrated on i.MX8QXP soc | |
| 6 | 7 | - reg : address and length of the lpi2c master registers |
| 7 | 8 | - interrupts : lpi2c interrupt |
| 8 | 9 | - clocks : lpi2c clock specifier |
| @@ -1,8 +1,12 @@ | ||
| 1 | 1 | I2C for OMAP platforms |
| 2 | 2 | |
| 3 | 3 | Required properties : |
| 4 | −- compatible : Must be "ti,omap2420-i2c", "ti,omap2430-i2c", "ti,omap3-i2c" | |
| 5 | − or "ti,omap4-i2c" | |
| 4 | +- compatible : Must be | |
| 5 | + "ti,omap2420-i2c" for OMAP2420 SoCs | |
| 6 | + "ti,omap2430-i2c" for OMAP2430 SoCs | |
| 7 | + "ti,omap3-i2c" for OMAP3 SoCs | |
| 8 | + "ti,omap4-i2c" for OMAP4+ SoCs | |
| 9 | + "ti,am654-i2c", "ti,omap4-i2c" for AM654 SoCs | |
| 6 | 10 | - ti,hwmods : Must be "i2c<n>", n being the instance number (1-based) |
| 7 | 11 | - #address-cells = <1>; |
| 8 | 12 | - #size-cells = <0>; |
| @@ -3,7 +3,9 @@ I2C for R-Car platforms · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible: |
| 5 | 5 | "renesas,i2c-r8a7743" if the device is a part of a R8A7743 SoC. |
| 6 | + "renesas,i2c-r8a7744" if the device is a part of a R8A7744 SoC. | |
| 6 | 7 | "renesas,i2c-r8a7745" if the device is a part of a R8A7745 SoC. |
| 8 | + "renesas,i2c-r8a77470" if the device is a part of a R8A77470 SoC. | |
| 7 | 9 | "renesas,i2c-r8a774a1" if the device is a part of a R8A774A1 SoC. |
| 8 | 10 | "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC. |
| 9 | 11 | "renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC. |
| @@ -5,6 +5,7 @@ Required properties: · 4 unmodified lines | ||
| 5 | 5 | - "renesas,iic-r8a73a4" (R-Mobile APE6) |
| 6 | 6 | - "renesas,iic-r8a7740" (R-Mobile A1) |
| 7 | 7 | - "renesas,iic-r8a7743" (RZ/G1M) |
| 8 | + - "renesas,iic-r8a7744" (RZ/G1N) | |
| 8 | 9 | - "renesas,iic-r8a7745" (RZ/G1E) |
| 9 | 10 | - "renesas,iic-r8a774a1" (RZ/G2M) |
| 10 | 11 | - "renesas,iic-r8a7790" (R-Car H2) |
| @@ -84,7 +84,7 @@ Binding may contain optional "interrupts" property, describing interrupts · 83 unmodified lines | ||
| 84 | 84 | used by the device. I2C core will assign "irq" interrupt (or the very first |
| 85 | 85 | interrupt if not using interrupt names) as primary interrupt for the slave. |
| 86 | 86 | |
| 87 | −Alternatively, devices supporting SMbus Host Notify, and connected to | |
| 87 | +Alternatively, devices supporting SMBus Host Notify, and connected to | |
| 88 | 88 | adapters that support this feature, may use "host-notify" property. I2C |
| 89 | 89 | core will create a virtual interrupt for Host Notify and assign it as |
| 90 | 90 | primary interrupt for the slave. |
| @@ -0,0 +1,33 @@ | ||
| 1 | +Analog Devices ADXL372 3-Axis, +/-(200g) Digital Accelerometer | |
| 2 | + | |
| 3 | +http://www.analog.com/media/en/technical-documentation/data-sheets/adxl372.pdf | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + - compatible : should be "adi,adxl372" | |
| 7 | + - reg: the I2C address or SPI chip select number for the device | |
| 8 | + | |
| 9 | +Required properties for SPI bus usage: | |
| 10 | + - spi-max-frequency: Max SPI frequency to use | |
| 11 | + | |
| 12 | +Optional properties: | |
| 13 | + - interrupts: interrupt mapping for IRQ as documented in | |
| 14 | + Documentation/devicetree/bindings/interrupt-controller/interrupts.txt | |
| 15 | + | |
| 16 | +Example for a I2C device node: | |
| 17 | + | |
| 18 | + accelerometer@53 { | |
| 19 | + compatible = "adi,adxl372"; | |
| 20 | + reg = <0x53>; | |
| 21 | + interrupt-parent = <&gpio>; | |
| 22 | + interrupts = <25 IRQ_TYPE_EDGE_FALLING>; | |
| 23 | + }; | |
| 24 | + | |
| 25 | +Example for a SPI device node: | |
| 26 | + | |
| 27 | + accelerometer@0 { | |
| 28 | + compatible = "adi,adxl372"; | |
| 29 | + reg = <0>; | |
| 30 | + spi-max-frequency = <1000000>; | |
| 31 | + interrupt-parent = <&gpio>; | |
| 32 | + interrupts = <25 IRQ_TYPE_EDGE_FALLING>; | |
| 33 | + }; | |
| @@ -0,0 +1,30 @@ | ||
| 1 | +* Microchip MCP3911 Dual channel analog front end (ADC) | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: Should be "microchip,mcp3911" | |
| 5 | + - reg: SPI chip select number for the device | |
| 6 | + | |
| 7 | +Recommended properties: | |
| 8 | + - spi-max-frequency: Definition as per | |
| 9 | + Documentation/devicetree/bindings/spi/spi-bus.txt. | |
| 10 | + Max frequency for this chip is 20MHz. | |
| 11 | + | |
| 12 | +Optional properties: | |
| 13 | + - clocks: Phandle and clock identifier for sampling clock | |
| 14 | + - interrupt-parent: Phandle to the parent interrupt controller | |
| 15 | + - interrupts: IRQ line for the ADC | |
| 16 | + - microchip,device-addr: Device address when multiple MCP3911 chips are present on the | |
| 17 | + same SPI bus. Valid values are 0-3. Defaults to 0. | |
| 18 | + - vref-supply: Phandle to the external reference voltage supply. | |
| 19 | + | |
| 20 | +Example: | |
| 21 | +adc@0 { | |
| 22 | + compatible = "microchip,mcp3911"; | |
| 23 | + reg = <0>; | |
| 24 | + interrupt-parent = <&gpio5>; | |
| 25 | + interrupts = <15 IRQ_TYPE_EDGE_RISING>; | |
| 26 | + spi-max-frequency = <20000000>; | |
| 27 | + microchip,device-addr = <0>; | |
| 28 | + vref-supply = <&vref_reg>; | |
| 29 | + clocks = <&xtal>; | |
| 30 | +}; | |
| @@ -1,7 +1,9 @@ | ||
| 1 | −Qualcomm's SPMI PMIC voltage ADC | |
| 1 | +Qualcomm's SPMI PMIC ADC | |
| 2 | 2 | |
| 3 | −SPMI PMIC voltage ADC (VADC) provides interface to clients to read | |
| 4 | −voltage. The VADC is a 15-bit sigma-delta ADC. | |
| 3 | +- SPMI PMIC voltage ADC (VADC) provides interface to clients to read | |
| 4 | + voltage. The VADC is a 15-bit sigma-delta ADC. | |
| 5 | +- SPMI PMIC5 voltage ADC (ADC) provides interface to clients to read | |
| 6 | + voltage. The VADC is a 16-bit sigma-delta ADC. | |
| 5 | 7 | |
| 6 | 8 | VADC node: |
| 7 | 9 | |
| @@ -9,11 +11,13 @@ VADC node: · 1 unmodified line | ||
| 9 | 11 | Usage: required |
| 10 | 12 | Value type: <string> |
| 11 | 13 | Definition: Should contain "qcom,spmi-vadc". |
| 14 | + Should contain "qcom,spmi-adc5" for PMIC5 ADC driver. | |
| 15 | + Should contain "qcom,spmi-adc-rev2" for PMIC rev2 ADC driver. | |
| 12 | 16 | |
| 13 | 17 | - reg: |
| 14 | 18 | Usage: required |
| 15 | 19 | Value type: <prop-encoded-array> |
| 16 | − Definition: VADC base address and length in the SPMI PMIC register map. | |
| 20 | + Definition: VADC base address in the SPMI PMIC register map. | |
| 17 | 21 | |
| 18 | 22 | - #address-cells: |
| 19 | 23 | Usage: required |
| @@ -45,13 +49,26 @@ Channel node properties: · 25 unmodified lines | ||
| 45 | 49 | Definition: ADC channel number. |
| 46 | 50 | See include/dt-bindings/iio/qcom,spmi-vadc.h |
| 47 | 51 | |
| 52 | +- label: | |
| 53 | + Usage: required for "qcom,spmi-adc5" and "qcom,spmi-adc-rev2" | |
| 54 | + Value type: <empty> | |
| 55 | + Definition: ADC input of the platform as seen in the schematics. | |
| 56 | + For thermistor inputs connected to generic AMUX or GPIO inputs | |
| 57 | + these can vary across platform for the same pins. Hence select | |
| 58 | + the platform schematics name for this channel. | |
| 59 | + | |
| 48 | 60 | - qcom,decimation: |
| 49 | 61 | Usage: optional |
| 50 | 62 | Value type: <u32> |
| 51 | 63 | Definition: This parameter is used to decrease ADC sampling rate. |
| 52 | 64 | Quicker measurements can be made by reducing decimation ratio. |
| 53 | − Valid values are 512, 1024, 2048, 4096. | |
| 54 | − If property is not found, default value of 512 will be used. | |
| 65 | + - For compatible property "qcom,spmi-vadc", valid values are | |
| 66 | + 512, 1024, 2048, 4096. If property is not found, default value | |
| 67 | + of 512 will be used. | |
| 68 | + - For compatible property "qcom,spmi-adc5", valid values are 250, 420 | |
| 69 | + and 840. If property is not found, default value of 840 is used. | |
| 70 | + - For compatible property "qcom,spmi-adc-rev2", valid values are 256, | |
| 71 | + 512 and 1024. If property is not present, default value is 1024. | |
| 55 | 72 | |
| 56 | 73 | - qcom,pre-scaling: |
| 57 | 74 | Usage: optional |
| @@ -66,21 +83,38 @@ Channel node properties: · 8 unmodified lines | ||
| 66 | 83 | - qcom,ratiometric: |
| 67 | 84 | Usage: optional |
| 68 | 85 | Value type: <empty> |
| 69 | − Definition: Channel calibration type. If this property is specified | |
| 70 | − VADC will use the VDD reference (1.8V) and GND for channel | |
| 71 | − calibration. If property is not found, channel will be | |
| 72 | − calibrated with 0.625V and 1.25V reference channels, also | |
| 73 | − known as absolute calibration. | |
| 86 | + Definition: Channel calibration type. | |
| 87 | + - For compatible property "qcom,spmi-vadc", if this property is | |
| 88 | + specified VADC will use the VDD reference (1.8V) and GND for | |
| 89 | + channel calibration. If property is not found, channel will be | |
| 90 | + calibrated with 0.625V and 1.25V reference channels, also | |
| 91 | + known as absolute calibration. | |
| 92 | + - For compatible property "qcom,spmi-adc5" and "qcom,spmi-adc-rev2", | |
| 93 | + if this property is specified VADC will use the VDD reference | |
| 94 | + (1.875V) and GND for channel calibration. If property is not found, | |
| 95 | + channel will be calibrated with 0V and 1.25V reference channels, | |
| 96 | + also known as absolute calibration. | |
| 74 | 97 | |
| 75 | 98 | - qcom,hw-settle-time: |
| 76 | 99 | Usage: optional |
| 77 | 100 | Value type: <u32> |
| 78 | 101 | Definition: Time between AMUX getting configured and the ADC starting |
| 79 | − conversion. Delay = 100us * (value) for value < 11, and | |
| 80 | − 2ms * (value - 10) otherwise. | |
| 81 | − Valid values are: 0, 100, 200, 300, 400, 500, 600, 700, 800, | |
| 82 | − 900 us and 1, 2, 4, 6, 8, 10 ms | |
| 83 | − If property is not found, channel will use 0us. | |
| 102 | + conversion. The 'hw_settle_time' is an index used from valid values | |
| 103 | + and programmed in hardware to achieve the hardware settling delay. | |
| 104 | + - For compatible property "qcom,spmi-vadc" and "qcom,spmi-adc-rev2", | |
| 105 | + Delay = 100us * (hw_settle_time) for hw_settle_time < 11, | |
| 106 | + and 2ms * (hw_settle_time - 10) otherwise. | |
| 107 | + Valid values are: 0, 100, 200, 300, 400, 500, 600, 700, 800, | |
| 108 | + 900 us and 1, 2, 4, 6, 8, 10 ms. | |
| 109 | + If property is not found, channel will use 0us. | |
| 110 | + - For compatible property "qcom,spmi-adc5", delay = 15us for | |
| 111 | + value 0, 100us * (value) for values < 11, | |
| 112 | + and 2ms * (value - 10) otherwise. | |
| 113 | + Valid values are: 15, 100, 200, 300, 400, 500, 600, 700, 800, | |
| 114 | + 900 us and 1, 2, 4, 6, 8, 10 ms | |
| 115 | + Certain controller digital versions have valid values of | |
| 116 | + 15, 100, 200, 300, 400, 500, 600, 700, 1, 2, 4, 8, 16, 32, 64, 128 ms | |
| 117 | + If property is not found, channel will use 15us. | |
| 84 | 118 | |
| 85 | 119 | - qcom,avg-samples: |
| 86 | 120 | Usage: optional |
| @@ -89,13 +123,18 @@ Channel node properties: · 2 unmodified lines | ||
| 89 | 123 | Averaging provides the option to obtain a single measurement |
| 90 | 124 | from the ADC that is an average of multiple samples. The value |
| 91 | 125 | selected is 2^(value). |
| 92 | − Valid values are: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 | |
| 93 | − If property is not found, 1 sample will be used. | |
| 126 | + - For compatible property "qcom,spmi-vadc", valid values | |
| 127 | + are: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 | |
| 128 | + If property is not found, 1 sample will be used. | |
| 129 | + - For compatible property "qcom,spmi-adc5" and "qcom,spmi-adc-rev2", | |
| 130 | + valid values are: 1, 2, 4, 8, 16 | |
| 131 | + If property is not found, 1 sample will be used. | |
| 94 | 132 | |
| 95 | 133 | NOTE: |
| 96 | 134 | |
| 97 | −Following channels, also known as reference point channels, are used for | |
| 98 | −result calibration and their channel configuration nodes should be defined: | |
| 135 | +For compatible property "qcom,spmi-vadc" following channels, also known as | |
| 136 | +reference point channels, are used for result calibration and their channel | |
| 137 | +configuration nodes should be defined: | |
| 99 | 138 | VADC_REF_625MV and/or VADC_SPARE1(based on PMIC version) VADC_REF_1250MV, |
| 100 | 139 | VADC_GND_REF and VADC_VDD_VADC. |
| 101 | 140 | |
| @@ -104,7 +143,7 @@ Example: · 2 unmodified lines | ||
| 104 | 143 | /* VADC node */ |
| 105 | 144 | pmic_vadc: vadc@3100 { |
| 106 | 145 | compatible = "qcom,spmi-vadc"; |
| 107 | − reg = <0x3100 0x100>; | |
| 146 | + reg = <0x3100>; | |
| 108 | 147 | interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>; |
| 109 | 148 | #address-cells = <1>; |
| 110 | 149 | #size-cells = <0>; |
| @@ -12,6 +12,8 @@ Required properties: · 11 unmodified lines | ||
| 12 | 12 | - interrupts: The interrupt number for the ADC device. |
| 13 | 13 | - #io-channel-cells: Number of cells in an IIO specifier. |
| 14 | 14 | - hwlocks: Reference to a phandle of a hwlock provider node. |
| 15 | +- nvmem-cells: A phandle to the calibration cells provided by eFuse device. | |
| 16 | +- nvmem-cell-names: Should be "big_scale_calib", "small_scale_calib". | |
| 15 | 17 | |
| 16 | 18 | Example: |
| 17 | 19 | |
| @@ -32,5 +34,7 @@ Example: · 14 unmodified lines | ||
| 32 | 34 | interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; |
| 33 | 35 | #io-channel-cells = <1>; |
| 34 | 36 | hwlocks = <&hwlock 4>; |
| 37 | + nvmem-cells = <&adc_big_scale>, <&adc_small_scale>; | |
| 38 | + nvmem-cell-names = "big_scale_calib", "small_scale_calib"; | |
| 35 | 39 | }; |
| 36 | 40 | }; |
| @@ -50,6 +50,9 @@ Required properties: · 49 unmodified lines | ||
| 50 | 50 | |
| 51 | 51 | Optional properties: |
| 52 | 52 | |
| 53 | + - reset-gpios : GPIO spec for the RESET pin. If specified, it will be | |
| 54 | + asserted during driver probe. | |
| 55 | + | |
| 53 | 56 | - adi,dc-dc-ilim-microamp: The dc-to-dc converter current limit |
| 54 | 57 | The following values are currently supported [uA]: |
| 55 | 58 | * 150000 |
| @@ -71,6 +74,8 @@ AD5758 Example: · 15 unmodified lines | ||
| 71 | 74 | spi-max-frequency = <1000000>; |
| 72 | 75 | spi-cpha; |
| 73 | 76 | |
| 77 | + reset-gpios = <&gpio 22 0>; | |
| 78 | + | |
| 74 | 79 | adi,dc-dc-mode = <2>; |
| 75 | 80 | adi,range-microvolt = <0 10000000>; |
| 76 | 81 | adi,dc-dc-ilim-microamp = <200000>; |
| @@ -0,0 +1,21 @@ | ||
| 1 | +* Linear Technology Micropower octal 8-Bit and 10-Bit DACs | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: Must be one of the following: | |
| 5 | + "lltc,ltc1660" | |
| 6 | + "lltc,ltc1665" | |
| 7 | + - reg: SPI chip select number for the device | |
| 8 | + - vref-supply: Phandle to the voltage reference supply | |
| 9 | + | |
| 10 | +Recommended properties: | |
| 11 | + - spi-max-frequency: Definition as per | |
| 12 | + Documentation/devicetree/bindings/spi/spi-bus.txt. | |
| 13 | + Max frequency for this chip is 5 MHz. | |
| 14 | + | |
| 15 | +Example: | |
| 16 | +dac@0 { | |
| 17 | + compatible = "lltc,ltc1660"; | |
| 18 | + reg = <0>; | |
| 19 | + spi-max-frequency = <5000000>; | |
| 20 | + vref-supply = <&vref_reg>; | |
| 21 | +}; | |
| @@ -20,6 +20,7 @@ Required properties: · 19 unmodified lines | ||
| 20 | 20 | bindings. |
| 21 | 21 | |
| 22 | 22 | Optional properties: |
| 23 | + - vddio-supply: regulator phandle for VDDIO supply | |
| 23 | 24 | - mount-matrix: an optional 3x3 mounting rotation matrix |
| 24 | 25 | - i2c-gate node. These devices also support an auxiliary i2c bus. This is |
| 25 | 26 | simple enough to be described using the i2c-gate binding. See |
| @@ -7,6 +7,7 @@ Required properties: · 6 unmodified lines | ||
| 7 | 7 | "st,lsm6dsl" |
| 8 | 8 | "st,lsm6dsm" |
| 9 | 9 | "st,ism330dlc" |
| 10 | + "st,lsm6dso" | |
| 10 | 11 | - reg: i2c address of the sensor / spi cs line |
| 11 | 12 | |
| 12 | 13 | Optional properties: |
| @@ -0,0 +1,18 @@ | ||
| 1 | +ROHM BH1750 - ALS, Ambient light sensor | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | +- compatible: Must be one of: | |
| 6 | + "rohm,bh1710" | |
| 7 | + "rohm,bh1715" | |
| 8 | + "rohm,bh1721" | |
| 9 | + "rohm,bh1750" | |
| 10 | + "rohm,bh1751" | |
| 11 | +- reg: the I2C address of the sensor | |
| 12 | + | |
| 13 | +Example: | |
| 14 | + | |
| 15 | +light-sensor@23 { | |
| 16 | + compatible = "rohm,bh1750"; | |
| 17 | + reg = <0x23>; | |
| 18 | +}; | |
| @@ -0,0 +1,42 @@ | ||
| 1 | +* AMS/TAOS ALS and proximity sensor | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | + - compatible: Should be one of | |
| 6 | + "amstaos,tsl2571" | |
| 7 | + "amstaos,tsl2671" | |
| 8 | + "amstaos,tmd2671" | |
| 9 | + "amstaos,tsl2771" | |
| 10 | + "amstaos,tmd2771" | |
| 11 | + "amstaos,tsl2572" | |
| 12 | + "amstaos,tsl2672" | |
| 13 | + "amstaos,tmd2672" | |
| 14 | + "amstaos,tsl2772" | |
| 15 | + "amstaos,tmd2772" | |
| 16 | + "avago,apds9930" | |
| 17 | + - reg: the I2C address of the device | |
| 18 | + | |
| 19 | +Optional properties: | |
| 20 | + | |
| 21 | + - amstaos,proximity-diodes - proximity diodes to enable. <0>, <1>, or <0 1> | |
| 22 | + are the only valid values. | |
| 23 | + - led-max-microamp - current for the proximity LED. Must be 100000, 50000, | |
| 24 | + 25000, or 13000. | |
| 25 | + - vdd-supply: phandle to the regulator that provides power to the sensor. | |
| 26 | + - vddio-supply: phandle to the regulator that provides power to the bus. | |
| 27 | + - interrupts: the sole interrupt generated by the device | |
| 28 | + | |
| 29 | + Refer to interrupt-controller/interrupts.txt for generic interrupt client | |
| 30 | + node bindings. | |
| 31 | + | |
| 32 | +Example: | |
| 33 | + | |
| 34 | +tsl2772@39 { | |
| 35 | + compatible = "amstaos,tsl2772"; | |
| 36 | + reg = <0x39>; | |
| 37 | + interrupts-extended = <&msmgpio 61 IRQ_TYPE_EDGE_FALLING>; | |
| 38 | + vdd-supply = <&pm8941_l17>; | |
| 39 | + vddio-supply = <&pm8941_lvs1>; | |
| 40 | + amstaos,proximity-diodes = <0>; | |
| 41 | + led-max-microamp = <100000>; | |
| 42 | +}; | |
| @@ -0,0 +1,12 @@ | ||
| 1 | +ST VL53L0X ToF ranging sensor | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: must be "st,vl53l0x" | |
| 5 | + - reg: i2c address where to find the device | |
| 6 | + | |
| 7 | +Example: | |
| 8 | + | |
| 9 | +vl53l0x@29 { | |
| 10 | + compatible = "st,vl53l0x"; | |
| 11 | + reg = <0x29>; | |
| 12 | +}; | |
| @@ -58,8 +58,8 @@ Example from Motorola Droid 4: · 57 unmodified lines | ||
| 58 | 58 | |
| 59 | 59 | vibrator { |
| 60 | 60 | compatible = "pwm-vibrator"; |
| 61 | − pwms = <&pwm8 0 1000000000 0>, | |
| 62 | − <&pwm9 0 1000000000 0>; | |
| 61 | + pwms = <&pwm9 0 1000000000 0>, | |
| 62 | + <&pwm8 0 1000000000 0>; | |
| 63 | 63 | pwm-names = "enable", "direction"; |
| 64 | 64 | direction-duty-cycle-ns = <1000000000>; |
| 65 | 65 | }; |
| @@ -1,10 +1,12 @@ | ||
| 1 | 1 | General Touchscreen Properties: |
| 2 | 2 | |
| 3 | 3 | Optional properties for Touchscreens: |
| 4 | + - touchscreen-min-x : minimum x coordinate reported (0 if not set) | |
| 5 | + - touchscreen-min-y : minimum y coordinate reported (0 if not set) | |
| 4 | 6 | - touchscreen-size-x : horizontal resolution of touchscreen |
| 5 | − (in pixels) | |
| 7 | + (maximum x coordinate reported + 1) | |
| 6 | 8 | - touchscreen-size-y : vertical resolution of touchscreen |
| 7 | − (in pixels) | |
| 9 | + (maximum y coordinate reported + 1) | |
| 8 | 10 | - touchscreen-max-pressure : maximum reported pressure (arbitrary range |
| 9 | 11 | dependent on the controller) |
| 10 | 12 | - touchscreen-min-pressure : minimum pressure on the touchscreen to be |
| @@ -0,0 +1,62 @@ | ||
| 1 | +============================== | |
| 2 | +C-SKY APB Interrupt Controller | |
| 3 | +============================== | |
| 4 | + | |
| 5 | +C-SKY APB Interrupt Controller is a simple soc interrupt controller | |
| 6 | +on the apb bus and we only use it as root irq controller. | |
| 7 | + | |
| 8 | + - csky,apb-intc is used in a lot of csky fpgas and socs, it support 64 irq nums. | |
| 9 | + - csky,dual-apb-intc consists of 2 apb-intc and 128 irq nums supported. | |
| 10 | + - csky,gx6605s-intc is gx6605s soc internal irq interrupt controller, 64 irq nums. | |
| 11 | + | |
| 12 | +============================= | |
| 13 | +intc node bindings definition | |
| 14 | +============================= | |
| 15 | + | |
| 16 | + Description: Describes APB interrupt controller | |
| 17 | + | |
| 18 | + PROPERTIES | |
| 19 | + | |
| 20 | + - compatible | |
| 21 | + Usage: required | |
| 22 | + Value type: <string> | |
| 23 | + Definition: must be "csky,apb-intc" | |
| 24 | + "csky,dual-apb-intc" | |
| 25 | + "csky,gx6605s-intc" | |
| 26 | + - #interrupt-cells | |
| 27 | + Usage: required | |
| 28 | + Value type: <u32> | |
| 29 | + Definition: must be <1> | |
| 30 | + - reg | |
| 31 | + Usage: required | |
| 32 | + Value type: <u32 u32> | |
| 33 | + Definition: <phyaddr size> in soc from cpu view | |
| 34 | + - interrupt-controller: | |
| 35 | + Usage: required | |
| 36 | + - csky,support-pulse-signal: | |
| 37 | + Usage: select | |
| 38 | + Description: to support pulse signal flag | |
| 39 | + | |
| 40 | +Examples: | |
| 41 | +--------- | |
| 42 | + | |
| 43 | + intc: interrupt-controller@500000 { | |
| 44 | + compatible = "csky,apb-intc"; | |
| 45 | + #interrupt-cells = <1>; | |
| 46 | + reg = <0x00500000 0x400>; | |
| 47 | + interrupt-controller; | |
| 48 | + }; | |
| 49 | + | |
| 50 | + intc: interrupt-controller@500000 { | |
| 51 | + compatible = "csky,dual-apb-intc"; | |
| 52 | + #interrupt-cells = <1>; | |
| 53 | + reg = <0x00500000 0x400>; | |
| 54 | + interrupt-controller; | |
| 55 | + }; | |
| 56 | + | |
| 57 | + intc: interrupt-controller@500000 { | |
| 58 | + compatible = "csky,gx6605s-intc"; | |
| 59 | + #interrupt-cells = <1>; | |
| 60 | + reg = <0x00500000 0x400>; | |
| 61 | + interrupt-controller; | |
| 62 | + }; | |
| @@ -0,0 +1,40 @@ | ||
| 1 | +=========================================== | |
| 2 | +C-SKY Multi-processors Interrupt Controller | |
| 3 | +=========================================== | |
| 4 | + | |
| 5 | +C-SKY Multi-processors Interrupt Controller is designed for ck807/ck810/ck860 | |
| 6 | +SMP soc, and it also could be used in non-SMP system. | |
| 7 | + | |
| 8 | +Interrupt number definition: | |
| 9 | + | |
| 10 | + 0-15 : software irq, and we use 15 as our IPI_IRQ. | |
| 11 | + 16-31 : private irq, and we use 16 as the co-processor timer. | |
| 12 | + 31-1024: common irq for soc ip. | |
| 13 | + | |
| 14 | +============================= | |
| 15 | +intc node bindings definition | |
| 16 | +============================= | |
| 17 | + | |
| 18 | + Description: Describes SMP interrupt controller | |
| 19 | + | |
| 20 | + PROPERTIES | |
| 21 | + | |
| 22 | + - compatible | |
| 23 | + Usage: required | |
| 24 | + Value type: <string> | |
| 25 | + Definition: must be "csky,mpintc" | |
| 26 | + - #interrupt-cells | |
| 27 | + Usage: required | |
| 28 | + Value type: <u32> | |
| 29 | + Definition: must be <1> | |
| 30 | + - interrupt-controller: | |
| 31 | + Usage: required | |
| 32 | + | |
| 33 | +Examples: | |
| 34 | +--------- | |
| 35 | + | |
| 36 | + intc: interrupt-controller { | |
| 37 | + compatible = "csky,mpintc"; | |
| 38 | + #interrupt-cells = <1>; | |
| 39 | + interrupt-controller; | |
| 40 | + }; | |
| @@ -5,6 +5,8 @@ The Marvell ICU (Interrupt Consolidation Unit) controller is · 4 unmodified lines | ||
| 5 | 5 | responsible for collecting all wired-interrupt sources in the CP and |
| 6 | 6 | communicating them to the GIC in the AP, the unit translates interrupt |
| 7 | 7 | requests on input wires to MSG memory mapped transactions to the GIC. |
| 8 | +These messages will access a different GIC memory area depending on | |
| 9 | +their type (NSR, SR, SEI, REI, etc). | |
| 8 | 10 | |
| 9 | 11 | Required properties: |
| 10 | 12 | |
| @@ -12,20 +14,23 @@ Required properties: · 1 unmodified line | ||
| 12 | 14 | |
| 13 | 15 | - reg: Should contain ICU registers location and length. |
| 14 | 16 | |
| 15 | −- #interrupt-cells: Specifies the number of cells needed to encode an | |
| 16 | − interrupt source. The value shall be 3. | |
| 17 | +Subnodes: Each group of interrupt is declared as a subnode of the ICU, | |
| 18 | +with their own compatible. | |
| 19 | + | |
| 20 | +Required properties for the icu_nsr/icu_sei subnodes: | |
| 17 | 21 | |
| 18 | − The 1st cell is the group type of the ICU interrupt. Possible group | |
| 19 | − types are: | |
| 22 | +- compatible: Should be one of: | |
| 23 | + * "marvell,cp110-icu-nsr" | |
| 24 | + * "marvell,cp110-icu-sr" | |
| 25 | + * "marvell,cp110-icu-sei" | |
| 26 | + * "marvell,cp110-icu-rei" | |
| 20 | 27 | |
| 21 | − ICU_GRP_NSR (0x0) : Shared peripheral interrupt, non-secure | |
| 22 | − ICU_GRP_SR (0x1) : Shared peripheral interrupt, secure | |
| 23 | − ICU_GRP_SEI (0x4) : System error interrupt | |
| 24 | − ICU_GRP_REI (0x5) : RAM error interrupt | |
| 28 | +- #interrupt-cells: Specifies the number of cells needed to encode an | |
| 29 | + interrupt source. The value shall be 2. | |
| 25 | 30 | |
| 26 | − The 2nd cell is the index of the interrupt in the ICU unit. | |
| 31 | + The 1st cell is the index of the interrupt in the ICU unit. | |
| 27 | 32 | |
| 28 | − The 3rd cell is the type of the interrupt. See arm,gic.txt for | |
| 33 | + The 2nd cell is the type of the interrupt. See arm,gic.txt for | |
| 29 | 34 | details. |
| 30 | 35 | |
| 31 | 36 | - interrupt-controller: Identifies the node as an interrupt |
| @@ -35,17 +40,73 @@ Required properties: · 3 unmodified lines | ||
| 35 | 40 | that allows to trigger interrupts using MSG memory mapped |
| 36 | 41 | transactions. |
| 37 | 42 | |
| 43 | +Note: each 'interrupts' property referring to any 'icu_xxx' node shall | |
| 44 | + have a different number within [0:206]. | |
| 45 | + | |
| 38 | 46 | Example: |
| 39 | 47 | |
| 40 | 48 | icu: interrupt-controller@1e0000 { |
| 41 | 49 | compatible = "marvell,cp110-icu"; |
| 42 | − reg = <0x1e0000 0x10>; | |
| 50 | + reg = <0x1e0000 0x440>; | |
| 51 | + | |
| 52 | + CP110_LABEL(icu_nsr): interrupt-controller@10 { | |
| 53 | + compatible = "marvell,cp110-icu-nsr"; | |
| 54 | + reg = <0x10 0x20>; | |
| 55 | + #interrupt-cells = <2>; | |
| 56 | + interrupt-controller; | |
| 57 | + msi-parent = <&gicp>; | |
| 58 | + }; | |
| 59 | + | |
| 60 | + CP110_LABEL(icu_sei): interrupt-controller@50 { | |
| 61 | + compatible = "marvell,cp110-icu-sei"; | |
| 62 | + reg = <0x50 0x10>; | |
| 63 | + #interrupt-cells = <2>; | |
| 64 | + interrupt-controller; | |
| 65 | + msi-parent = <&sei>; | |
| 66 | + }; | |
| 67 | +}; | |
| 68 | + | |
| 69 | +node1 { | |
| 70 | + interrupt-parent = <&icu_nsr>; | |
| 71 | + interrupts = <106 IRQ_TYPE_LEVEL_HIGH>; | |
| 72 | +}; | |
| 73 | + | |
| 74 | +node2 { | |
| 75 | + interrupt-parent = <&icu_sei>; | |
| 76 | + interrupts = <107 IRQ_TYPE_LEVEL_HIGH>; | |
| 77 | +}; | |
| 78 | + | |
| 79 | +/* Would not work with the above nodes */ | |
| 80 | +node3 { | |
| 81 | + interrupt-parent = <&icu_nsr>; | |
| 82 | + interrupts = <107 IRQ_TYPE_LEVEL_HIGH>; | |
| 83 | +}; | |
| 84 | + | |
| 85 | +The legacy bindings were different in this way: | |
| 86 | + | |
| 87 | +- #interrupt-cells: The value was 3. | |
| 88 | + The 1st cell was the group type of the ICU interrupt. Possible | |
| 89 | + group types were: | |
| 90 | + ICU_GRP_NSR (0x0) : Shared peripheral interrupt, non-secure | |
| 91 | + ICU_GRP_SR (0x1) : Shared peripheral interrupt, secure | |
| 92 | + ICU_GRP_SEI (0x4) : System error interrupt | |
| 93 | + ICU_GRP_REI (0x5) : RAM error interrupt | |
| 94 | + The 2nd cell was the index of the interrupt in the ICU unit. | |
| 95 | + The 3rd cell was the type of the interrupt. See arm,gic.txt for | |
| 96 | + details. | |
| 97 | + | |
| 98 | +Example: | |
| 99 | + | |
| 100 | +icu: interrupt-controller@1e0000 { | |
| 101 | + compatible = "marvell,cp110-icu"; | |
| 102 | + reg = <0x1e0000 0x440>; | |
| 103 | + | |
| 43 | 104 | #interrupt-cells = <3>; |
| 44 | 105 | interrupt-controller; |
| 45 | 106 | msi-parent = <&gicp>; |
| 46 | 107 | }; |
| 47 | 108 | |
| 48 | −usb3h0: usb3@500000 { | |
| 109 | +node1 { | |
| 49 | 110 | interrupt-parent = <&icu>; |
| 50 | 111 | interrupts = <ICU_GRP_NSR 106 IRQ_TYPE_LEVEL_HIGH>; |
| 51 | 112 | }; |
| @@ -0,0 +1,36 @@ | ||
| 1 | +Marvell SEI (System Error Interrupt) Controller | |
| 2 | +----------------------------------------------- | |
| 3 | + | |
| 4 | +Marvell SEI (System Error Interrupt) controller is an interrupt | |
| 5 | +aggregator. It receives interrupts from several sources and aggregates | |
| 6 | +them to a single interrupt line (an SPI) on the parent interrupt | |
| 7 | +controller. | |
| 8 | + | |
| 9 | +This interrupt controller can handle up to 64 SEIs, a set comes from the | |
| 10 | +AP and is wired while a second set comes from the CPs by the mean of | |
| 11 | +MSIs. | |
| 12 | + | |
| 13 | +Required properties: | |
| 14 | + | |
| 15 | +- compatible: should be one of: | |
| 16 | + * "marvell,ap806-sei" | |
| 17 | +- reg: SEI registers location and length. | |
| 18 | +- interrupts: identifies the parent IRQ that will be triggered. | |
| 19 | +- #interrupt-cells: number of cells to define an SEI wired interrupt | |
| 20 | + coming from the AP, should be 1. The cell is the IRQ | |
| 21 | + number. | |
| 22 | +- interrupt-controller: identifies the node as an interrupt controller | |
| 23 | + for AP interrupts. | |
| 24 | +- msi-controller: identifies the node as an MSI controller for the CPs | |
| 25 | + interrupts. | |
| 26 | + | |
| 27 | +Example: | |
| 28 | + | |
| 29 | + sei: interrupt-controller@3f0200 { | |
| 30 | + compatible = "marvell,ap806-sei"; | |
| 31 | + reg = <0x3f0200 0x40>; | |
| 32 | + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>; | |
| 33 | + #interrupt-cells = <1>; | |
| 34 | + interrupt-controller; | |
| 35 | + msi-controller; | |
| 36 | + }; | |
| @@ -2,10 +2,12 @@ DT bindings for the R-Mobile/R-Car/RZ/G interrupt controller · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | |
| 5 | −- compatible: has to be "renesas,irqc-<soctype>", "renesas,irqc" as fallback. | |
| 5 | +- compatible: must be "renesas,irqc-<soctype>" or "renesas,intc-ex-<soctype>", | |
| 6 | + and "renesas,irqc" as fallback. | |
| 6 | 7 | Examples with soctypes are: |
| 7 | 8 | - "renesas,irqc-r8a73a4" (R-Mobile APE6) |
| 8 | 9 | - "renesas,irqc-r8a7743" (RZ/G1M) |
| 10 | + - "renesas,irqc-r8a7744" (RZ/G1N) | |
| 9 | 11 | - "renesas,irqc-r8a7745" (RZ/G1E) |
| 10 | 12 | - "renesas,irqc-r8a77470" (RZ/G1C) |
| 11 | 13 | - "renesas,irqc-r8a7790" (R-Car H2) |
| @@ -19,6 +21,7 @@ Required properties: · 7 unmodified lines | ||
| 19 | 21 | - "renesas,intc-ex-r8a77965" (R-Car M3-N) |
| 20 | 22 | - "renesas,intc-ex-r8a77970" (R-Car V3M) |
| 21 | 23 | - "renesas,intc-ex-r8a77980" (R-Car V3H) |
| 24 | + - "renesas,intc-ex-r8a77990" (R-Car E3) | |
| 22 | 25 | - "renesas,intc-ex-r8a77995" (R-Car D3) |
| 23 | 26 | - #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in |
| 24 | 27 | interrupts.txt in this directory |
| @@ -41,6 +41,8 @@ Required properties: · 40 unmodified lines | ||
| 41 | 41 | - compatible : must be one of the following string: |
| 42 | 42 | "mediatek,mt2701-m4u" for mt2701 which uses generation one m4u HW. |
| 43 | 43 | "mediatek,mt2712-m4u" for mt2712 which uses generation two m4u HW. |
| 44 | + "mediatek,mt7623-m4u", "mediatek,mt2701-m4u" for mt7623 which uses | |
| 45 | + generation one m4u HW. | |
| 44 | 46 | "mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW. |
| 45 | 47 | - reg : m4u register base and size. |
| 46 | 48 | - interrupts : the interrupt of m4u. |
| @@ -51,7 +53,7 @@ Required properties: · 4 unmodified lines | ||
| 51 | 53 | according to the local arbiter index, like larb0, larb1, larb2... |
| 52 | 54 | - iommu-cells : must be 1. This is the mtk_m4u_id according to the HW. |
| 53 | 55 | Specifies the mtk_m4u_id as defined in |
| 54 | − dt-binding/memory/mt2701-larb-port.h for mt2701, | |
| 56 | + dt-binding/memory/mt2701-larb-port.h for mt2701, mt7623 | |
| 55 | 57 | dt-binding/memory/mt2712-larb-port.h for mt2712, and |
| 56 | 58 | dt-binding/memory/mt8173-larb-port.h for mt8173. |
| 57 | 59 | |
| @@ -12,6 +12,7 @@ Required Properties: · 11 unmodified lines | ||
| 12 | 12 | |
| 13 | 13 | - "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU. |
| 14 | 14 | - "renesas,ipmmu-r8a7743" for the R8A7743 (RZ/G1M) IPMMU. |
| 15 | + - "renesas,ipmmu-r8a7744" for the R8A7744 (RZ/G1N) IPMMU. | |
| 15 | 16 | - "renesas,ipmmu-r8a7745" for the R8A7745 (RZ/G1E) IPMMU. |
| 16 | 17 | - "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU. |
| 17 | 18 | - "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU. |
| @@ -0,0 +1,43 @@ | ||
| 1 | +* Panasonic AN30259A 3-channel LED driver | |
| 2 | + | |
| 3 | +The AN30259A is a LED controller capable of driving three LEDs independently. It supports | |
| 4 | +constant current output and sloping current output modes. The chip is connected over I2C. | |
| 5 | + | |
| 6 | +Required properties: | |
| 7 | + - compatible: Must be "panasonic,an30259a". | |
| 8 | + - reg: I2C slave address. | |
| 9 | + - #address-cells: Must be 1. | |
| 10 | + - #size-cells: Must be 0. | |
| 11 | + | |
| 12 | +Each LED is represented as a sub-node of the panasonic,an30259a node. | |
| 13 | + | |
| 14 | +Required sub-node properties: | |
| 15 | + - reg: Pin that the LED is connected to. Must be 1, 2, or 3. | |
| 16 | + | |
| 17 | +Optional sub-node properties: | |
| 18 | + - label: see Documentation/devicetree/bindings/leds/common.txt | |
| 19 | + - linux,default-trigger: see Documentation/devicetree/bindings/leds/common.txt | |
| 20 | + | |
| 21 | +Example: | |
| 22 | +led-controller@30 { | |
| 23 | + compatible = "panasonic,an30259a"; | |
| 24 | + reg = <0x30>; | |
| 25 | + #address-cells = <1>; | |
| 26 | + #size-cells = <0>; | |
| 27 | + | |
| 28 | + led@1 { | |
| 29 | + reg = <1>; | |
| 30 | + linux,default-trigger = "heartbeat"; | |
| 31 | + label = "red:indicator"; | |
| 32 | + }; | |
| 33 | + | |
| 34 | + led@2 { | |
| 35 | + reg = <2>; | |
| 36 | + label = "green:indicator"; | |
| 37 | + }; | |
| 38 | + | |
| 39 | + led@3 { | |
| 40 | + reg = <3>; | |
| 41 | + label = "blue:indicator"; | |
| 42 | + }; | |
| 43 | +}; | |
| @@ -11,6 +11,7 @@ platforms. · 10 unmodified lines | ||
| 11 | 11 | "qcom,msm8916-apcs-kpss-global", |
| 12 | 12 | "qcom,msm8996-apcs-hmss-global" |
| 13 | 13 | "qcom,msm8998-apcs-hmss-global" |
| 14 | + "qcom,qcs404-apcs-apps-global" | |
| 14 | 15 | "qcom,sdm845-apss-shared" |
| 15 | 16 | |
| 16 | 17 | - reg: |
| @@ -0,0 +1,54 @@ | ||
| 1 | +Device-tree bindings for the VPU found in Allwinner SoCs, referred to as the | |
| 2 | +Video Engine (VE) in Allwinner literature. | |
| 3 | + | |
| 4 | +The VPU can only access the first 256 MiB of DRAM, that are DMA-mapped starting | |
| 5 | +from the DRAM base. This requires specific memory allocation and handling. | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible : must be one of the following compatibles: | |
| 9 | + - "allwinner,sun4i-a10-video-engine" | |
| 10 | + - "allwinner,sun5i-a13-video-engine" | |
| 11 | + - "allwinner,sun7i-a20-video-engine" | |
| 12 | + - "allwinner,sun8i-a33-video-engine" | |
| 13 | + - "allwinner,sun8i-h3-video-engine" | |
| 14 | +- reg : register base and length of VE; | |
| 15 | +- clocks : list of clock specifiers, corresponding to entries in | |
| 16 | + the clock-names property; | |
| 17 | +- clock-names : should contain "ahb", "mod" and "ram" entries; | |
| 18 | +- resets : phandle for reset; | |
| 19 | +- interrupts : VE interrupt number; | |
| 20 | +- allwinner,sram : SRAM region to use with the VE. | |
| 21 | + | |
| 22 | +Optional properties: | |
| 23 | +- memory-region : CMA pool to use for buffers allocation instead of the | |
| 24 | + default CMA pool. | |
| 25 | + | |
| 26 | +Example: | |
| 27 | + | |
| 28 | +reserved-memory { | |
| 29 | + #address-cells = <1>; | |
| 30 | + #size-cells = <1>; | |
| 31 | + ranges; | |
| 32 | + | |
| 33 | + /* Address must be kept in the lower 256 MiBs of DRAM for VE. */ | |
| 34 | + cma_pool: cma@4a000000 { | |
| 35 | + compatible = "shared-dma-pool"; | |
| 36 | + size = <0x6000000>; | |
| 37 | + alloc-ranges = <0x4a000000 0x6000000>; | |
| 38 | + reusable; | |
| 39 | + linux,cma-default; | |
| 40 | + }; | |
| 41 | +}; | |
| 42 | + | |
| 43 | +video-codec@1c0e000 { | |
| 44 | + compatible = "allwinner,sun7i-a20-video-engine"; | |
| 45 | + reg = <0x01c0e000 0x1000>; | |
| 46 | + | |
| 47 | + clocks = <&ccu CLK_AHB_VE>, <&ccu CLK_VE>, | |
| 48 | + <&ccu CLK_DRAM_VE>; | |
| 49 | + clock-names = "ahb", "mod", "ram"; | |
| 50 | + | |
| 51 | + resets = <&ccu RST_VE>; | |
| 52 | + interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>; | |
| 53 | + allwinner,sram = <&ve_sram 1>; | |
| 54 | +}; | |
| @@ -0,0 +1,26 @@ | ||
| 1 | +Freescale Pixel Pipeline | |
| 2 | +======================== | |
| 3 | + | |
| 4 | +The Pixel Pipeline (PXP) is a memory-to-memory graphics processing engine | |
| 5 | +that supports scaling, colorspace conversion, alpha blending, rotation, and | |
| 6 | +pixel conversion via lookup table. Different versions are present on various | |
| 7 | +i.MX SoCs from i.MX23 to i.MX7. | |
| 8 | + | |
| 9 | +Required properties: | |
| 10 | +- compatible: should be "fsl,<soc>-pxp", where SoC can be one of imx23, imx28, | |
| 11 | + imx6dl, imx6sl, imx6ul, imx6sx, imx6ull, or imx7d. | |
| 12 | +- reg: the register base and size for the device registers | |
| 13 | +- interrupts: the PXP interrupt, two interrupts for imx6ull and imx7d. | |
| 14 | +- clock-names: should be "axi" | |
| 15 | +- clocks: the PXP AXI clock | |
| 16 | + | |
| 17 | +Example: | |
| 18 | + | |
| 19 | +pxp@21cc000 { | |
| 20 | + compatible = "fsl,imx6ull-pxp"; | |
| 21 | + reg = <0x021cc000 0x4000>; | |
| 22 | + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, | |
| 23 | + <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>; | |
| 24 | + clock-names = "axi"; | |
| 25 | + clocks = <&clks IMX6UL_CLK_PXP>; | |
| 26 | +}; | |
| @@ -10,7 +10,11 @@ Required Properties: · 9 unmodified lines | ||
| 10 | 10 | - "adi,adv7481" for the ADV7481 |
| 11 | 11 | - "adi,adv7482" for the ADV7482 |
| 12 | 12 | |
| 13 | − - reg: I2C slave address | |
| 13 | + - reg: I2C slave addresses | |
| 14 | + The ADV748x has up to twelve 256-byte maps that can be accessed via the | |
| 15 | + main I2C ports. Each map has it own I2C address and acts as a standard | |
| 16 | + slave device on the I2C bus. The main address is mandatory, others are | |
| 17 | + optional and remain at default values if not specified. | |
| 14 | 18 | |
| 15 | 19 | Optional Properties: |
| 16 | 20 | |
| @@ -18,6 +22,11 @@ Optional Properties: · 1 unmodified line | ||
| 18 | 22 | "intrq3". All interrupts are optional. The "intrq3" interrupt |
| 19 | 23 | is only available on the adv7481 |
| 20 | 24 | - interrupts: Specify the interrupt lines for the ADV748x |
| 25 | + - reg-names : Names of maps with programmable addresses. | |
| 26 | + It shall contain all maps needing a non-default address. | |
| 27 | + Possible map names are: | |
| 28 | + "main", "dpll", "cp", "hdmi", "edid", "repeater", | |
| 29 | + "infoframe", "cbus", "cec", "sdp", "txa", "txb" | |
| 21 | 30 | |
| 22 | 31 | The device node must contain one 'port' child node per device input and output |
| 23 | 32 | port, in accordance with the video interface bindings defined in |
| @@ -47,7 +56,10 @@ Example: · 23 unmodified lines | ||
| 47 | 56 | |
| 48 | 57 | video-receiver@70 { |
| 49 | 58 | compatible = "adi,adv7482"; |
| 50 | − reg = <0x70>; | |
| 59 | + reg = <0x70 0x71 0x72 0x73 0x74 0x75 | |
| 60 | + 0x60 0x61 0x62 0x63 0x64 0x65>; | |
| 61 | + reg-names = "main", "dpll", "cp", "hdmi", "edid", "repeater", | |
| 62 | + "infoframe", "cbus", "cec", "sdp", "txa", "txb"; | |
| 51 | 63 | |
| 52 | 64 | #address-cells = <1>; |
| 53 | 65 | #size-cells = <0>; |
| @@ -73,7 +85,7 @@ Example: · 19 unmodified lines | ||
| 73 | 85 | }; |
| 74 | 86 | }; |
| 75 | 87 | |
| 76 | − port@10 { | |
| 88 | + port@a { | |
| 77 | 89 | reg = <10>; |
| 78 | 90 | |
| 79 | 91 | adv7482_txa: endpoint { |
| @@ -83,7 +95,7 @@ Example: · 3 unmodified lines | ||
| 83 | 95 | }; |
| 84 | 96 | }; |
| 85 | 97 | |
| 86 | − port@11 { | |
| 98 | + port@b { | |
| 87 | 99 | reg = <11>; |
| 88 | 100 | |
| 89 | 101 | adv7482_txb: endpoint { |
| @@ -66,7 +66,7 @@ Example: · 65 unmodified lines | ||
| 66 | 66 | * other maps will retain their default addresses. |
| 67 | 67 | */ |
| 68 | 68 | reg = <0x4c>, <0x66>; |
| 69 | − reg-names "main", "edid"; | |
| 69 | + reg-names = "main", "edid"; | |
| 70 | 70 | |
| 71 | 71 | reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>; |
| 72 | 72 | hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>; |
File renamed without changes.
| @@ -5,6 +5,7 @@ Mediatek JPEG Decoder is the JPEG decode hardware present in Mediatek SoCs · 4 unmodified lines | ||
| 5 | 5 | Required properties: |
| 6 | 6 | - compatible : must be one of the following string: |
| 7 | 7 | "mediatek,mt8173-jpgdec" |
| 8 | + "mediatek,mt7623-jpgdec", "mediatek,mt2701-jpgdec" | |
| 8 | 9 | "mediatek,mt2701-jpgdec" |
| 9 | 10 | - reg : physical base address of the jpeg decoder registers and length of |
| 10 | 11 | memory mapped region. |
| @@ -11,6 +11,7 @@ on Gen3 platforms to a CSI-2 receiver. · 10 unmodified lines | ||
| 11 | 11 | |
| 12 | 12 | - compatible: Must be one or more of the following |
| 13 | 13 | - "renesas,vin-r8a7743" for the R8A7743 device |
| 14 | + - "renesas,vin-r8a7744" for the R8A7744 device | |
| 14 | 15 | - "renesas,vin-r8a7745" for the R8A7745 device |
| 15 | 16 | - "renesas,vin-r8a7778" for the R8A7778 device |
| 16 | 17 | - "renesas,vin-r8a7779" for the R8A7779 device |
| @@ -17,15 +17,19 @@ Required properties: · 16 unmodified lines | ||
| 17 | 17 | The CEU supports a single parallel input and should contain a single 'port' |
| 18 | 18 | subnode with a single 'endpoint'. Connection to input devices are modeled |
| 19 | 19 | according to the video interfaces OF bindings specified in: |
| 20 | −Documentation/devicetree/bindings/media/video-interfaces.txt | |
| 20 | +[1] Documentation/devicetree/bindings/media/video-interfaces.txt | |
| 21 | 21 | |
| 22 | 22 | Optional endpoint properties applicable to parallel input bus described in |
| 23 | 23 | the above mentioned "video-interfaces.txt" file are supported. |
| 24 | 24 | |
| 25 | −- hsync-active: Active state of the HSYNC signal, 0/1 for LOW/HIGH respectively. | |
| 26 | − If property is not present, default is active high. | |
| 27 | −- vsync-active: Active state of the VSYNC signal, 0/1 for LOW/HIGH respectively. | |
| 28 | − If property is not present, default is active high. | |
| 25 | +- hsync-active: See [1] for description. If property is not present, | |
| 26 | + default is active high. | |
| 27 | +- vsync-active: See [1] for description. If property is not present, | |
| 28 | + default is active high. | |
| 29 | +- bus-width: See [1] for description. Accepted values are '8' and '16'. | |
| 30 | + If property is not present, default is '8'. | |
| 31 | +- field-even-active: See [1] for description. If property is not present, | |
| 32 | + an even field is identified by a logic 0 (active-low signal). | |
| 29 | 33 | |
| 30 | 34 | Example: |
| 31 | 35 | |
| @@ -0,0 +1,29 @@ | ||
| 1 | +device-tree bindings for rockchip VPU codec | |
| 2 | + | |
| 3 | +Rockchip (Video Processing Unit) present in various Rockchip platforms, | |
| 4 | +such as RK3288 and RK3399. | |
| 5 | + | |
| 6 | +Required properties: | |
| 7 | +- compatible: value should be one of the following | |
| 8 | + "rockchip,rk3288-vpu"; | |
| 9 | + "rockchip,rk3399-vpu"; | |
| 10 | +- interrupts: encoding and decoding interrupt specifiers | |
| 11 | +- interrupt-names: should be "vepu" and "vdpu" | |
| 12 | +- clocks: phandle to VPU aclk, hclk clocks | |
| 13 | +- clock-names: should be "aclk" and "hclk" | |
| 14 | +- power-domains: phandle to power domain node | |
| 15 | +- iommus: phandle to a iommu node | |
| 16 | + | |
| 17 | +Example: | |
| 18 | +SoC-specific DT entry: | |
| 19 | + vpu: video-codec@ff9a0000 { | |
| 20 | + compatible = "rockchip,rk3288-vpu"; | |
| 21 | + reg = <0x0 0xff9a0000 0x0 0x800>; | |
| 22 | + interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, | |
| 23 | + <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>; | |
| 24 | + interrupt-names = "vepu", "vdpu"; | |
| 25 | + clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>; | |
| 26 | + clock-names = "aclk", "hclk"; | |
| 27 | + power-domains = <&power RK3288_PD_VIDEO>; | |
| 28 | + iommus = <&vpu_mmu>; | |
| 29 | + }; | |
| @@ -100,10 +100,12 @@ Optional endpoint properties · 99 unmodified lines | ||
| 100 | 100 | slave device (data source) by the master device (data sink). In the master |
| 101 | 101 | mode the data source device is also the source of the synchronization signals. |
| 102 | 102 | - bus-type: data bus type. Possible values are: |
| 103 | − 0 - autodetect based on other properties (MIPI CSI-2 D-PHY, parallel or Bt656) | |
| 104 | 103 | 1 - MIPI CSI-2 C-PHY |
| 105 | 104 | 2 - MIPI CSI1 |
| 106 | 105 | 3 - CCP2 |
| 106 | + 4 - MIPI CSI-2 D-PHY | |
| 107 | + 5 - Parallel | |
| 108 | + 6 - Bt.656 | |
| 107 | 109 | - bus-width: number of data lines actively used, valid for the parallel busses. |
| 108 | 110 | - data-shift: on the parallel data busses, if bus-width is used to specify the |
| 109 | 111 | number of data lines, data-shift can be used to specify which data lines are |
| @@ -17,6 +17,7 @@ Required properties: · 16 unmodified lines | ||
| 17 | 17 | - compatible : must be one of : |
| 18 | 18 | "mediatek,mt2701-smi-common" |
| 19 | 19 | "mediatek,mt2712-smi-common" |
| 20 | + "mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common" | |
| 20 | 21 | "mediatek,mt8173-smi-common" |
| 21 | 22 | - reg : the register and size of the SMI block. |
| 22 | 23 | - power-domains : a phandle to the power domain of this local arbiter. |
| @@ -6,6 +6,7 @@ Required properties: · 5 unmodified lines | ||
| 6 | 6 | - compatible : must be one of : |
| 7 | 7 | "mediatek,mt2701-smi-larb" |
| 8 | 8 | "mediatek,mt2712-smi-larb" |
| 9 | + "mediatek,mt7623-smi-larb", "mediatek,mt2701-smi-larb" | |
| 9 | 10 | "mediatek,mt8173-smi-larb" |
| 10 | 11 | - reg : the register and size of this local arbiter. |
| 11 | 12 | - mediatek,smi : a phandle to the smi_common node. |
| @@ -16,7 +17,7 @@ Required properties: · 4 unmodified lines | ||
| 16 | 17 | the register. |
| 17 | 18 | - "smi" : It's the clock for transfer data and command. |
| 18 | 19 | |
| 19 | −Required property for mt2701 and mt2712: | |
| 20 | +Required property for mt2701, mt2712 and mt7623: | |
| 20 | 21 | - mediatek,larb-id :the hardware id of this larb. |
| 21 | 22 | |
| 22 | 23 | Example: |
| @@ -76,7 +76,7 @@ Deprecated properties: · 75 unmodified lines | ||
| 76 | 76 | Also see child specific device properties: |
| 77 | 77 | Regulator - ../regulator/arizona-regulator.txt |
| 78 | 78 | Extcon - ../extcon/extcon-arizona.txt |
| 79 | − Sound - ../sound/arizona.txt | |
| 79 | + Sound - ../sound/wlf,arizona.txt | |
| 80 | 80 | |
| 81 | 81 | Example: |
| 82 | 82 | |
| @@ -1,6 +1,6 @@ | ||
| 1 | 1 | * Atmel Universal Synchronous Asynchronous Receiver/Transmitter (USART) |
| 2 | 2 | |
| 3 | −Required properties: | |
| 3 | +Required properties for USART: | |
| 4 | 4 | - compatible: Should be "atmel,<chip>-usart" or "atmel,<chip>-dbgu" |
| 5 | 5 | The compatible <chip> indicated will be the first SoC to support an |
| 6 | 6 | additional mode or an USART new feature. |
| @@ -11,7 +11,13 @@ Required properties: · 4 unmodified lines | ||
| 11 | 11 | Required elements: "usart" |
| 12 | 12 | - clocks: phandles to input clocks. |
| 13 | 13 | |
| 14 | −Optional properties: | |
| 14 | +Required properties for USART in SPI mode: | |
| 15 | +- #size-cells : Must be <0> | |
| 16 | +- #address-cells : Must be <1> | |
| 17 | +- cs-gpios: chipselects (internal cs not supported) | |
| 18 | +- atmel,usart-mode : Must be <AT91_USART_MODE_SPI> (found in dt-bindings/mfd/at91-usart.h) | |
| 19 | + | |
| 20 | +Optional properties in serial mode: | |
| 15 | 21 | - atmel,use-dma-rx: use of PDC or DMA for receiving data |
| 16 | 22 | - atmel,use-dma-tx: use of PDC or DMA for transmitting data |
| 17 | 23 | - {rts,cts,dtr,dsr,rng,dcd}-gpios: specify a GPIO for RTS/CTS/DTR/DSR/RI/DCD line respectively. |
| @@ -62,3 +68,18 @@ Example: · 44 unmodified lines | ||
| 62 | 68 | dma-names = "tx", "rx"; |
| 63 | 69 | atmel,fifo-size = <32>; |
| 64 | 70 | }; |
| 71 | + | |
| 72 | +- SPI mode: | |
| 73 | + #include <dt-bindings/mfd/at91-usart.h> | |
| 74 | + | |
| 75 | + spi0: spi@f001c000 { | |
| 76 | + #address-cells = <1>; | |
| 77 | + #size-cells = <0>; | |
| 78 | + compatible = "atmel,at91rm9200-usart", "atmel,at91sam9260-usart"; | |
| 79 | + atmel,usart-mode = <AT91_USART_MODE_SPI>; | |
| 80 | + reg = <0xf001c000 0x100>; | |
| 81 | + interrupts = <12 IRQ_TYPE_LEVEL_HIGH 5>; | |
| 82 | + clocks = <&usart0_clk>; | |
| 83 | + clock-names = "usart"; | |
| 84 | + cs-gpios = <&pioB 3 0>; | |
| 85 | + }; | |
| @@ -1,16 +1,17 @@ | ||
| 1 | −* ROHM BD71837 Power Management Integrated Circuit bindings | |
| 1 | +* ROHM BD71837 and BD71847 Power Management Integrated Circuit bindings | |
| 2 | 2 | |
| 3 | −BD71837MWV is a programmable Power Management IC for powering single-core, | |
| 4 | −dual-core, and quad-core SoCs such as NXP-i.MX 8M. It is optimized for | |
| 5 | −low BOM cost and compact solution footprint. It integrates 8 Buck | |
| 6 | −egulators and 7 LDOs to provide all the power rails required by the SoC and | |
| 7 | −the commonly used peripherals. | |
| 3 | +BD71837MWV and BD71847MWV are programmable Power Management ICs for powering | |
| 4 | +single-core, dual-core, and quad-core SoCs such as NXP-i.MX 8M. They are | |
| 5 | +optimized for low BOM cost and compact solution footprint. BD71837MWV | |
| 6 | +integrates 8 Buck regulators and 7 LDOs. BD71847MWV contains 6 Buck regulators | |
| 7 | +and 6 LDOs. | |
| 8 | 8 | |
| 9 | −Datasheet for PMIC is available at: | |
| 9 | +Datasheet for BD71837 is available at: | |
| 10 | 10 | https://www.rohm.com/datasheet/BD71837MWV/bd71837mwv-e |
| 11 | 11 | |
| 12 | 12 | Required properties: |
| 13 | − - compatible : Should be "rohm,bd71837". | |
| 13 | + - compatible : Should be "rohm,bd71837" for bd71837 | |
| 14 | + "rohm,bd71847" for bd71847. | |
| 14 | 15 | - reg : I2C slave address. |
| 15 | 16 | - interrupt-parent : Phandle to the parent interrupt controller. |
| 16 | 17 | - interrupts : The interrupt line the device is connected to. |
| @@ -41,3 +41,19 @@ Example: · 40 unmodified lines | ||
| 41 | 41 | compatible = "mscc,ocelot-cpu-syscon", "syscon"; |
| 42 | 42 | reg = <0x70000000 0x2c>; |
| 43 | 43 | }; |
| 44 | + | |
| 45 | +o HSIO regs: | |
| 46 | + | |
| 47 | +The SoC has a few registers (HSIO) handling miscellaneous functionalities: | |
| 48 | +configuration and status of PLL5, RCOMP, SyncE, SerDes configurations and | |
| 49 | +status, SerDes muxing and a thermal sensor. | |
| 50 | + | |
| 51 | +Required properties: | |
| 52 | +- compatible: Should be "mscc,ocelot-hsio", "syscon", "simple-mfd" | |
| 53 | +- reg : Should contain registers location and length | |
| 54 | + | |
| 55 | +Example: | |
| 56 | + syscon@10d0000 { | |
| 57 | + compatible = "mscc,ocelot-hsio", "syscon", "simple-mfd"; | |
| 58 | + reg = <0x10d0000 0x10000>; | |
| 59 | + }; | |
| @@ -9,6 +9,25 @@ blocks that can be used to create functional hardware objects/devices · 8 unmodified lines | ||
| 9 | 9 | such as network interfaces, crypto accelerator instances, L2 switches, |
| 10 | 10 | etc. |
| 11 | 11 | |
| 12 | +For an overview of the DPAA2 architecture and fsl-mc bus see: | |
| 13 | +Documentation/networking/dpaa2/overview.rst | |
| 14 | + | |
| 15 | +As described in the above overview, all DPAA2 objects in a DPRC share the | |
| 16 | +same hardware "isolation context" and a 10-bit value called an ICID | |
| 17 | +(isolation context id) is expressed by the hardware to identify | |
| 18 | +the requester. | |
| 19 | + | |
| 20 | +The generic 'iommus' property is insufficient to describe the relationship | |
| 21 | +between ICIDs and IOMMUs, so an iommu-map property is used to define | |
| 22 | +the set of possible ICIDs under a root DPRC and how they map to | |
| 23 | +an IOMMU. | |
| 24 | + | |
| 25 | +For generic IOMMU bindings, see | |
| 26 | +Documentation/devicetree/bindings/iommu/iommu.txt. | |
| 27 | + | |
| 28 | +For arm-smmu binding, see: | |
| 29 | +Documentation/devicetree/bindings/iommu/arm,smmu.txt. | |
| 30 | + | |
| 12 | 31 | Required properties: |
| 13 | 32 | |
| 14 | 33 | - compatible |
| @@ -88,14 +107,34 @@ Sub-nodes: · 73 unmodified lines | ||
| 88 | 107 | Value type: <phandle> |
| 89 | 108 | Definition: Specifies the phandle to the PHY device node associated |
| 90 | 109 | with the this dpmac. |
| 110 | +Optional properties: | |
| 111 | + | |
| 112 | +- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier | |
| 113 | + data. | |
| 114 | + | |
| 115 | + The property is an arbitrary number of tuples of | |
| 116 | + (icid-base,iommu,iommu-base,length). | |
| 117 | + | |
| 118 | + Any ICID i in the interval [icid-base, icid-base + length) is | |
| 119 | + associated with the listed IOMMU, with the iommu-specifier | |
| 120 | + (i - icid-base + iommu-base). | |
| 91 | 121 | |
| 92 | 122 | Example: |
| 93 | 123 | |
| 124 | + smmu: iommu@5000000 { | |
| 125 | + compatible = "arm,mmu-500"; | |
| 126 | + #iommu-cells = <1>; | |
| 127 | + stream-match-mask = <0x7C00>; | |
| 128 | + ... | |
| 129 | + }; | |
| 130 | + | |
| 94 | 131 | fsl_mc: fsl-mc@80c000000 { |
| 95 | 132 | compatible = "fsl,qoriq-mc"; |
| 96 | 133 | reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ |
| 97 | 134 | <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ |
| 98 | 135 | msi-parent = <&its>; |
| 136 | + /* define map for ICIDs 23-64 */ | |
| 137 | + iommu-map = <23 &smmu 23 41>; | |
| 99 | 138 | #address-cells = <3>; |
| 100 | 139 | #size-cells = <1>; |
| 101 | 140 | |
| @@ -0,0 +1,26 @@ | ||
| 1 | +* Liebherr's BK4 controller external SPI | |
| 2 | + | |
| 3 | +A device which handles data acquisition from compatible industrial | |
| 4 | +peripherals. | |
| 5 | +The SPI is used for data and management purposes in both master and | |
| 6 | +slave modes. | |
| 7 | + | |
| 8 | +Required properties: | |
| 9 | + | |
| 10 | +- compatible : Should be "lwn,bk4" | |
| 11 | + | |
| 12 | +Required SPI properties: | |
| 13 | + | |
| 14 | +- reg : Should be address of the device chip select within | |
| 15 | + the controller. | |
| 16 | + | |
| 17 | +- spi-max-frequency : Maximum SPI clocking speed of device in Hz, should be | |
| 18 | + 30MHz at most for the Liebherr's BK4 external bus. | |
| 19 | + | |
| 20 | +Example: | |
| 21 | + | |
| 22 | +spidev0: spi@0 { | |
| 23 | + compatible = "lwn,bk4"; | |
| 24 | + spi-max-frequency = <30000000>; | |
| 25 | + reg = <0>; | |
| 26 | +}; | |
| @@ -15,6 +15,7 @@ Required Properties: · 14 unmodified lines | ||
| 15 | 15 | - "arasan,sdhci-5.1": generic Arasan SDHCI 5.1 PHY |
| 16 | 16 | - "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1": rk3399 eMMC PHY |
| 17 | 17 | For this device it is strongly suggested to include arasan,soc-ctl-syscon. |
| 18 | + - "ti,am654-sdhci-5.1", "arasan,sdhci-5.1": TI AM654 MMC PHY | |
| 18 | 19 | - reg: From mmc bindings: Register location and length. |
| 19 | 20 | - clocks: From clock bindings: Handles to clock inputs. |
| 20 | 21 | - clock-names: From clock bindings: Tuple including "clk_xin" and "clk_ahb" |
| @@ -7,6 +7,7 @@ described in mmc.txt. · 6 unmodified lines | ||
| 7 | 7 | Required properties: |
| 8 | 8 | - compatible: Should be one of the following: |
| 9 | 9 | - "ingenic,jz4740-mmc" for the JZ4740 |
| 10 | + - "ingenic,jz4725b-mmc" for the JZ4725B | |
| 10 | 11 | - "ingenic,jz4780-mmc" for the JZ4780 |
| 11 | 12 | - reg: Should contain the MMC controller registers location and length. |
| 12 | 13 | - interrupts: Should contain the interrupt specifier of the MMC controller. |
| @@ -15,8 +15,11 @@ Required properties: · 14 unmodified lines | ||
| 15 | 15 | Optional properties: |
| 16 | 16 | - arm,primecell-periphid : contains the PrimeCell Peripheral ID, it overrides |
| 17 | 17 | the ID provided by the HW |
| 18 | +- resets : phandle to internal reset line. | |
| 19 | + Should be defined for sdmmc variant. | |
| 18 | 20 | - vqmmc-supply : phandle to the regulator device tree node, mentioned |
| 19 | 21 | as the VCCQ/VDD_IO supply in the eMMC/SD specs. |
| 22 | +specific for ux500 variant: | |
| 20 | 23 | - st,sig-dir-dat0 : bus signal direction pin used for DAT[0]. |
| 21 | 24 | - st,sig-dir-dat2 : bus signal direction pin used for DAT[2]. |
| 22 | 25 | - st,sig-dir-dat31 : bus signal direction pin used for DAT[3] and DAT[1]. |
| @@ -24,6 +27,14 @@ Optional properties: · 1 unmodified line | ||
| 24 | 27 | - st,sig-dir-cmd : cmd signal direction pin used for CMD. |
| 25 | 28 | - st,sig-pin-fbclk : feedback clock signal pin used. |
| 26 | 29 | |
| 30 | +specific for sdmmc variant: | |
| 31 | +- st,sig-dir : signal direction polarity used for cmd, dat0 dat123. | |
| 32 | +- st,neg-edge : data & command phase relation, generated on | |
| 33 | + sd clock falling edge. | |
| 34 | +- st,use-ckin : use ckin pin from an external driver to sample | |
| 35 | + the receive data (example: with voltage | |
| 36 | + switch transceiver). | |
| 37 | + | |
| 27 | 38 | Deprecated properties: |
| 28 | 39 | - mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable. |
| 29 | 40 | - mmc-cap-sd-highspeed : indicates whether SD is high speed capable. |
| @@ -10,6 +10,7 @@ Required properties: · 9 unmodified lines | ||
| 10 | 10 | - compatible: value should be either of the following. |
| 11 | 11 | "mediatek,mt8135-mmc": for mmc host ip compatible with mt8135 |
| 12 | 12 | "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173 |
| 13 | + "mediatek,mt8183-mmc": for mmc host ip compatible with mt8183 | |
| 13 | 14 | "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701 |
| 14 | 15 | "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712 |
| 15 | 16 | "mediatek,mt7622-mmc": for MT7622 SoC |
| @@ -22,6 +23,7 @@ Required properties: · 6 unmodified lines | ||
| 22 | 23 | "source" - source clock (required) |
| 23 | 24 | "hclk" - HCLK which used for host (required) |
| 24 | 25 | "source_cg" - independent source clock gate (required for MT2712) |
| 26 | + "bus_clk" - bus clock used for internal register access (required for MT2712 MSDC0/3) | |
| 25 | 27 | - pinctrl-names: should be "default", "state_uhs" |
| 26 | 28 | - pinctrl-0: should contain default/high speed pin ctrl |
| 27 | 29 | - pinctrl-1: should contain uhs mode pin ctrl |
| @@ -38,3 +38,75 @@ sdhci@c8000200 { · 37 unmodified lines | ||
| 38 | 38 | power-gpios = <&gpio 155 0>; /* gpio PT3 */ |
| 39 | 39 | bus-width = <8>; |
| 40 | 40 | }; |
| 41 | + | |
| 42 | +Optional properties for Tegra210 and Tegra186: | |
| 43 | +- pinctrl-names, pinctrl-0, pinctrl-1 : Specify pad voltage | |
| 44 | + configurations. Valid pinctrl-names are "sdmmc-3v3" and "sdmmc-1v8" | |
| 45 | + for controllers supporting multiple voltage levels. The order of names | |
| 46 | + should correspond to the pin configuration states in pinctrl-0 and | |
| 47 | + pinctrl-1. | |
| 48 | +- nvidia,only-1-8-v : The presence of this property indicates that the | |
| 49 | + controller operates at a 1.8 V fixed I/O voltage. | |
| 50 | +- nvidia,pad-autocal-pull-up-offset-3v3, | |
| 51 | + nvidia,pad-autocal-pull-down-offset-3v3 : Specify drive strength | |
| 52 | + calibration offsets for 3.3 V signaling modes. | |
| 53 | +- nvidia,pad-autocal-pull-up-offset-1v8, | |
| 54 | + nvidia,pad-autocal-pull-down-offset-1v8 : Specify drive strength | |
| 55 | + calibration offsets for 1.8 V signaling modes. | |
| 56 | +- nvidia,pad-autocal-pull-up-offset-3v3-timeout, | |
| 57 | + nvidia,pad-autocal-pull-down-offset-3v3-timeout : Specify drive | |
| 58 | + strength used as a fallback in case the automatic calibration times | |
| 59 | + out on a 3.3 V signaling mode. | |
| 60 | +- nvidia,pad-autocal-pull-up-offset-1v8-timeout, | |
| 61 | + nvidia,pad-autocal-pull-down-offset-1v8-timeout : Specify drive | |
| 62 | + strength used as a fallback in case the automatic calibration times | |
| 63 | + out on a 1.8 V signaling mode. | |
| 64 | +- nvidia,pad-autocal-pull-up-offset-sdr104, | |
| 65 | + nvidia,pad-autocal-pull-down-offset-sdr104 : Specify drive strength | |
| 66 | + calibration offsets for SDR104 mode. | |
| 67 | +- nvidia,pad-autocal-pull-up-offset-hs400, | |
| 68 | + nvidia,pad-autocal-pull-down-offset-hs400 : Specify drive strength | |
| 69 | + calibration offsets for HS400 mode. | |
| 70 | +- nvidia,default-tap : Specify the default inbound sampling clock | |
| 71 | + trimmer value for non-tunable modes. | |
| 72 | +- nvidia,default-trim : Specify the default outbound clock trimmer | |
| 73 | + value. | |
| 74 | +- nvidia,dqs-trim : Specify DQS trim value for HS400 timing | |
| 75 | + | |
| 76 | + Notes on the pad calibration pull up and pulldown offset values: | |
| 77 | + - The property values are drive codes which are programmed into the | |
| 78 | + PD_OFFSET and PU_OFFSET sections of the | |
| 79 | + SDHCI_TEGRA_AUTO_CAL_CONFIG register. | |
| 80 | + - A higher value corresponds to higher drive strength. Please refer | |
| 81 | + to the reference manual of the SoC for correct values. | |
| 82 | + - The SDR104 and HS400 timing specific values are used in | |
| 83 | + corresponding modes if specified. | |
| 84 | + | |
| 85 | + Notes on tap and trim values: | |
| 86 | + - The values are used for compensating trace length differences | |
| 87 | + by adjusting the sampling point. | |
| 88 | + - The values are programmed to the Vendor Clock Control Register. | |
| 89 | + Please refer to the reference manual of the SoC for correct | |
| 90 | + values. | |
| 91 | + - The DQS trim values are only used on controllers which support | |
| 92 | + HS400 timing. Only SDMMC4 on Tegra210 and Tegra 186 supports | |
| 93 | + HS400. | |
| 94 | + | |
| 95 | +Example: | |
| 96 | +sdhci@700b0000 { | |
| 97 | + compatible = "nvidia,tegra210-sdhci", "nvidia,tegra124-sdhci"; | |
| 98 | + reg = <0x0 0x700b0000 0x0 0x200>; | |
| 99 | + interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>; | |
| 100 | + clocks = <&tegra_car TEGRA210_CLK_SDMMC1>; | |
| 101 | + clock-names = "sdhci"; | |
| 102 | + resets = <&tegra_car 14>; | |
| 103 | + reset-names = "sdhci"; | |
| 104 | + pinctrl-names = "sdmmc-3v3", "sdmmc-1v8"; | |
| 105 | + pinctrl-0 = <&sdmmc1_3v3>; | |
| 106 | + pinctrl-1 = <&sdmmc1_1v8>; | |
| 107 | + nvidia,pad-autocal-pull-up-offset-3v3 = <0x00>; | |
| 108 | + nvidia,pad-autocal-pull-down-offset-3v3 = <0x7d>; | |
| 109 | + nvidia,pad-autocal-pull-up-offset-1v8 = <0x7b>; | |
| 110 | + nvidia,pad-autocal-pull-down-offset-1v8 = <0x7b>; | |
| 111 | + status = "disabled"; | |
| 112 | +}; | |
| @@ -12,6 +12,7 @@ Required properties: · 11 unmodified lines | ||
| 12 | 12 | - "renesas,mmcif-r8a73a4" for the MMCIF found in r8a73a4 SoCs |
| 13 | 13 | - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs |
| 14 | 14 | - "renesas,mmcif-r8a7743" for the MMCIF found in r8a7743 SoCs |
| 15 | + - "renesas,mmcif-r8a7744" for the MMCIF found in r8a7744 SoCs | |
| 15 | 16 | - "renesas,mmcif-r8a7745" for the MMCIF found in r8a7745 SoCs |
| 16 | 17 | - "renesas,mmcif-r8a7778" for the MMCIF found in r8a7778 SoCs |
| 17 | 18 | - "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs |
| @@ -23,7 +24,8 @@ Required properties: · 5 unmodified lines | ||
| 23 | 24 | - interrupts: Some SoCs have only 1 shared interrupt, while others have either |
| 24 | 25 | 2 or 3 individual interrupts (error, int, card detect). Below is the number |
| 25 | 26 | of interrupts for each SoC: |
| 26 | − 1: r8a73a4, r8a7743, r8a7745, r8a7778, r8a7790, r8a7791, r8a7793, r8a7794 | |
| 27 | + 1: r8a73a4, r8a7743, r8a7744, r8a7745, r8a7778, r8a7790, r8a7791, r8a7793, | |
| 28 | + r8a7794 | |
| 27 | 29 | 2: r8a7740, sh73a0 |
| 28 | 30 | 3: r7s72100 |
| 29 | 31 | |
| @@ -0,0 +1,41 @@ | ||
| 1 | +* Spreadtrum SDHCI controller (sdhci-sprd) | |
| 2 | + | |
| 3 | +The Secure Digital (SD) Host controller on Spreadtrum SoCs provides an interface | |
| 4 | +for MMC, SD and SDIO types of cards. | |
| 5 | + | |
| 6 | +This file documents differences between the core properties in mmc.txt | |
| 7 | +and the properties used by the sdhci-sprd driver. | |
| 8 | + | |
| 9 | +Required properties: | |
| 10 | +- compatible: Should contain "sprd,sdhci-r11". | |
| 11 | +- reg: physical base address of the controller and length. | |
| 12 | +- interrupts: Interrupts used by the SDHCI controller. | |
| 13 | +- clocks: Should contain phandle for the clock feeding the SDHCI controller | |
| 14 | +- clock-names: Should contain the following: | |
| 15 | + "sdio" - SDIO source clock (required) | |
| 16 | + "enable" - gate clock which used for enabling/disabling the device (required) | |
| 17 | + | |
| 18 | +Optional properties: | |
| 19 | +- assigned-clocks: the same with "sdio" clock | |
| 20 | +- assigned-clock-parents: the default parent of "sdio" clock | |
| 21 | + | |
| 22 | +Examples: | |
| 23 | + | |
| 24 | +sdio0: sdio@20600000 { | |
| 25 | + compatible = "sprd,sdhci-r11"; | |
| 26 | + reg = <0 0x20600000 0 0x1000>; | |
| 27 | + interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>; | |
| 28 | + | |
| 29 | + clock-names = "sdio", "enable"; | |
| 30 | + clocks = <&ap_clk CLK_EMMC_2X>, | |
| 31 | + <&apahb_gate CLK_EMMC_EB>; | |
| 32 | + assigned-clocks = <&ap_clk CLK_EMMC_2X>; | |
| 33 | + assigned-clock-parents = <&rpll CLK_RPLL_390M>; | |
| 34 | + | |
| 35 | + bus-width = <8>; | |
| 36 | + non-removable; | |
| 37 | + no-sdio; | |
| 38 | + no-sd; | |
| 39 | + cap-mmc-hw-reset; | |
| 40 | + status = "okay"; | |
| 41 | +}; | |
| @@ -16,7 +16,11 @@ Required properties: · 15 unmodified lines | ||
| 16 | 16 | "renesas,sdhi-r8a73a4" - SDHI IP on R8A73A4 SoC |
| 17 | 17 | "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC |
| 18 | 18 | "renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC |
| 19 | + "renesas,sdhi-r8a7744" - SDHI IP on R8A7744 SoC | |
| 19 | 20 | "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC |
| 21 | + "renesas,sdhi-r8a774a1" - SDHI IP on R8A774A1 SoC | |
| 22 | + "renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC | |
| 23 | + "renesas,sdhi-mmc-r8a77470" - SDHI/MMC IP on R8A77470 SoC | |
| 20 | 24 | "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC |
| 21 | 25 | "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC |
| 22 | 26 | "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC |
| @@ -27,14 +31,16 @@ Required properties: · 4 unmodified lines | ||
| 27 | 31 | "renesas,sdhi-r8a7795" - SDHI IP on R8A7795 SoC |
| 28 | 32 | "renesas,sdhi-r8a7796" - SDHI IP on R8A7796 SoC |
| 29 | 33 | "renesas,sdhi-r8a77965" - SDHI IP on R8A77965 SoC |
| 34 | + "renesas,sdhi-r8a77970" - SDHI IP on R8A77970 SoC | |
| 30 | 35 | "renesas,sdhi-r8a77980" - SDHI IP on R8A77980 SoC |
| 31 | 36 | "renesas,sdhi-r8a77990" - SDHI IP on R8A77990 SoC |
| 32 | 37 | "renesas,sdhi-r8a77995" - SDHI IP on R8A77995 SoC |
| 33 | 38 | "renesas,sdhi-shmobile" - a generic sh-mobile SDHI controller |
| 34 | 39 | "renesas,rcar-gen1-sdhi" - a generic R-Car Gen1 SDHI controller |
| 35 | − "renesas,rcar-gen2-sdhi" - a generic R-Car Gen2 or RZ/G1 | |
| 40 | + "renesas,rcar-gen2-sdhi" - a generic R-Car Gen2 and RZ/G1 SDHI | |
| 41 | + (not SDHI/MMC) controller | |
| 42 | + "renesas,rcar-gen3-sdhi" - a generic R-Car Gen3 or RZ/G2 | |
| 36 | 43 | SDHI controller |
| 37 | − "renesas,rcar-gen3-sdhi" - a generic R-Car Gen3 SDHI controller | |
| 38 | 44 | |
| 39 | 45 | |
| 40 | 46 | When compatible with the generic version, nodes must list |
| @@ -0,0 +1,55 @@ | ||
| 1 | +UniPhier SD/eMMC controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be one of the following: | |
| 5 | + "socionext,uniphier-sd-v2.91" - IP version 2.91 | |
| 6 | + "socionext,uniphier-sd-v3.1" - IP version 3.1 | |
| 7 | + "socionext,uniphier-sd-v3.1.1" - IP version 3.1.1 | |
| 8 | +- reg: offset and length of the register set for the device. | |
| 9 | +- interrupts: a single interrupt specifier. | |
| 10 | +- clocks: a single clock specifier of the controller clock. | |
| 11 | +- reset-names: should contain the following: | |
| 12 | + "host" - mandatory for all versions | |
| 13 | + "bridge" - should exist only for "socionext,uniphier-sd-v2.91" | |
| 14 | + "hw" - should exist if eMMC hw reset line is available | |
| 15 | +- resets: a list of reset specifiers, corresponding to the reset-names | |
| 16 | + | |
| 17 | +Optional properties: | |
| 18 | +- pinctrl-names: if present, should contain the following: | |
| 19 | + "default" - should exist for all instances | |
| 20 | + "uhs" - should exist for SD instance with UHS support | |
| 21 | +- pinctrl-0: pin control state for the default mode | |
| 22 | +- pinctrl-1: pin control state for the UHS mode | |
| 23 | +- dma-names: should be "rx-tx" if present. | |
| 24 | + This property can exist only for "socionext,uniphier-sd-v2.91". | |
| 25 | +- dmas: a single DMA channel specifier | |
| 26 | + This property can exist only for "socionext,uniphier-sd-v2.91". | |
| 27 | +- bus-width: see mmc.txt | |
| 28 | +- cap-sd-highspeed: see mmc.txt | |
| 29 | +- cap-mmc-highspeed: see mmc.txt | |
| 30 | +- sd-uhs-sdr12: see mmc.txt | |
| 31 | +- sd-uhs-sdr25: see mmc.txt | |
| 32 | +- sd-uhs-sdr50: see mmc.txt | |
| 33 | +- cap-mmc-hw-reset: should exist if reset-names contains "hw". see mmc.txt | |
| 34 | +- non-removable: see mmc.txt | |
| 35 | + | |
| 36 | +Example: | |
| 37 | + | |
| 38 | + sd: sdhc@5a400000 { | |
| 39 | + compatible = "socionext,uniphier-sd-v2.91"; | |
| 40 | + reg = <0x5a400000 0x200>; | |
| 41 | + interrupts = <0 76 4>; | |
| 42 | + pinctrl-names = "default", "uhs"; | |
| 43 | + pinctrl-0 = <&pinctrl_sd>; | |
| 44 | + pinctrl-1 = <&pinctrl_sd_uhs>; | |
| 45 | + clocks = <&mio_clk 0>; | |
| 46 | + reset-names = "host", "bridge"; | |
| 47 | + resets = <&mio_rst 0>, <&mio_rst 3>; | |
| 48 | + dma-names = "rx-tx"; | |
| 49 | + dmas = <&dmac 4>; | |
| 50 | + bus-width = <4>; | |
| 51 | + cap-sd-highspeed; | |
| 52 | + sd-uhs-sdr12; | |
| 53 | + sd-uhs-sdr25; | |
| 54 | + sd-uhs-sdr50; | |
| 55 | + }; | |
| @@ -19,6 +19,9 @@ Optional properties: · 18 unmodified lines | ||
| 19 | 19 | - interrupt-names: must be "mdio_done_error" when there is a share interrupt fed |
| 20 | 20 | to this hardware block, or must be "mdio_done" for the first interrupt and |
| 21 | 21 | "mdio_error" for the second when there are separate interrupts |
| 22 | +- clocks: A reference to the clock supplying the MDIO bus controller | |
| 23 | +- clock-frequency: the MDIO bus clock that must be output by the MDIO bus | |
| 24 | + hardware, if absent, the default hardware values are used | |
| 22 | 25 | |
| 23 | 26 | Child nodes of this MDIO bus controller node are standard Ethernet PHY device |
| 24 | 27 | nodes as described in Documentation/devicetree/bindings/net/phy.txt |
| @@ -3,6 +3,7 @@ Renesas R-Car CAN controller Device Tree Bindings · 2 unmodified lines | ||
| 3 | 3 | |
| 4 | 4 | Required properties: |
| 5 | 5 | - compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC. |
| 6 | + "renesas,can-r8a7744" if CAN controller is a part of R8A7744 SoC. | |
| 6 | 7 | "renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC. |
| 7 | 8 | "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC. |
| 8 | 9 | "renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC. |
| @@ -46,6 +46,42 @@ Required properties: · 45 unmodified lines | ||
| 46 | 46 | "brcm,bcm6328-switch" |
| 47 | 47 | "brcm,bcm6368-switch" and the mandatory "brcm,bcm63xx-switch" |
| 48 | 48 | |
| 49 | +Required properties for BCM585xx/586xx/88312 SoCs: | |
| 50 | + | |
| 51 | + - reg: a total of 3 register base addresses, the first one must be the | |
| 52 | + Switch Register Access block base, the second is the port 5/4 mux | |
| 53 | + configuration register and the third one is the SGMII configuration | |
| 54 | + and status register base address. | |
| 55 | + | |
| 56 | + - interrupts: a total of 13 interrupts must be specified, in the following | |
| 57 | + order: port 0-5, 7-8 link status change, then the integrated PHY interrupt, | |
| 58 | + then the timestamping interrupt and the sleep timer interrupts for ports | |
| 59 | + 5,7,8. | |
| 60 | + | |
| 61 | +Optional properties for BCM585xx/586xx/88312 SoCs: | |
| 62 | + | |
| 63 | + - reg-names: a total of 3 names matching the 3 base register address, must | |
| 64 | + be in the following order: | |
| 65 | + "srab" | |
| 66 | + "mux_config" | |
| 67 | + "sgmii_config" | |
| 68 | + | |
| 69 | + - interrupt-names: a total of 13 names matching the 13 interrupts specified | |
| 70 | + must be in the following order: | |
| 71 | + "link_state_p0" | |
| 72 | + "link_state_p1" | |
| 73 | + "link_state_p2" | |
| 74 | + "link_state_p3" | |
| 75 | + "link_state_p4" | |
| 76 | + "link_state_p5" | |
| 77 | + "link_state_p7" | |
| 78 | + "link_state_p8" | |
| 79 | + "phy" | |
| 80 | + "ts" | |
| 81 | + "imp_sleep_timer_p5" | |
| 82 | + "imp_sleep_timer_p7" | |
| 83 | + "imp_sleep_timer_p8" | |
| 84 | + | |
| 49 | 85 | See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional |
| 50 | 86 | required and optional properties. |
| 51 | 87 | |
| @@ -0,0 +1,143 @@ | ||
| 1 | +Lantiq GSWIP Ethernet switches | |
| 2 | +================================== | |
| 3 | + | |
| 4 | +Required properties for GSWIP core: | |
| 5 | + | |
| 6 | +- compatible : "lantiq,xrx200-gswip" for the embedded GSWIP in the | |
| 7 | + xRX200 SoC | |
| 8 | +- reg : memory range of the GSWIP core registers | |
| 9 | + : memory range of the GSWIP MDIO registers | |
| 10 | + : memory range of the GSWIP MII registers | |
| 11 | + | |
| 12 | +See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of | |
| 13 | +additional required and optional properties. | |
| 14 | + | |
| 15 | + | |
| 16 | +Required properties for MDIO bus: | |
| 17 | +- compatible : "lantiq,xrx200-mdio" for the MDIO bus inside the GSWIP | |
| 18 | + core of the xRX200 SoC and the PHYs connected to it. | |
| 19 | + | |
| 20 | +See Documentation/devicetree/bindings/net/mdio.txt for a list of additional | |
| 21 | +required and optional properties. | |
| 22 | + | |
| 23 | + | |
| 24 | +Required properties for GPHY firmware loading: | |
| 25 | +- compatible : "lantiq,xrx200-gphy-fw", "lantiq,gphy-fw" | |
| 26 | + "lantiq,xrx300-gphy-fw", "lantiq,gphy-fw" | |
| 27 | + "lantiq,xrx330-gphy-fw", "lantiq,gphy-fw" | |
| 28 | + for the loading of the firmware into the embedded | |
| 29 | + GPHY core of the SoC. | |
| 30 | +- lantiq,rcu : reference to the rcu syscon | |
| 31 | + | |
| 32 | +The GPHY firmware loader has a list of GPHY entries, one for each | |
| 33 | +embedded GPHY | |
| 34 | + | |
| 35 | +- reg : Offset of the GPHY firmware register in the RCU | |
| 36 | + register range | |
| 37 | +- resets : list of resets of the embedded GPHY | |
| 38 | +- reset-names : list of names of the resets | |
| 39 | + | |
| 40 | +Example: | |
| 41 | + | |
| 42 | +Ethernet switch on the VRX200 SoC: | |
| 43 | + | |
| 44 | +switch@e108000 { | |
| 45 | + #address-cells = <1>; | |
| 46 | + #size-cells = <0>; | |
| 47 | + compatible = "lantiq,xrx200-gswip"; | |
| 48 | + reg = < 0xe108000 0x3100 /* switch */ | |
| 49 | + 0xe10b100 0xd8 /* mdio */ | |
| 50 | + 0xe10b1d8 0x130 /* mii */ | |
| 51 | + >; | |
| 52 | + dsa,member = <0 0>; | |
| 53 | + | |
| 54 | + ports { | |
| 55 | + #address-cells = <1>; | |
| 56 | + #size-cells = <0>; | |
| 57 | + | |
| 58 | + port@0 { | |
| 59 | + reg = <0>; | |
| 60 | + label = "lan3"; | |
| 61 | + phy-mode = "rgmii"; | |
| 62 | + phy-handle = <&phy0>; | |
| 63 | + }; | |
| 64 | + | |
| 65 | + port@1 { | |
| 66 | + reg = <1>; | |
| 67 | + label = "lan4"; | |
| 68 | + phy-mode = "rgmii"; | |
| 69 | + phy-handle = <&phy1>; | |
| 70 | + }; | |
| 71 | + | |
| 72 | + port@2 { | |
| 73 | + reg = <2>; | |
| 74 | + label = "lan2"; | |
| 75 | + phy-mode = "internal"; | |
| 76 | + phy-handle = <&phy11>; | |
| 77 | + }; | |
| 78 | + | |
| 79 | + port@4 { | |
| 80 | + reg = <4>; | |
| 81 | + label = "lan1"; | |
| 82 | + phy-mode = "internal"; | |
| 83 | + phy-handle = <&phy13>; | |
| 84 | + }; | |
| 85 | + | |
| 86 | + port@5 { | |
| 87 | + reg = <5>; | |
| 88 | + label = "wan"; | |
| 89 | + phy-mode = "rgmii"; | |
| 90 | + phy-handle = <&phy5>; | |
| 91 | + }; | |
| 92 | + | |
| 93 | + port@6 { | |
| 94 | + reg = <0x6>; | |
| 95 | + label = "cpu"; | |
| 96 | + ethernet = <ð0>; | |
| 97 | + }; | |
| 98 | + }; | |
| 99 | + | |
| 100 | + mdio { | |
| 101 | + #address-cells = <1>; | |
| 102 | + #size-cells = <0>; | |
| 103 | + compatible = "lantiq,xrx200-mdio"; | |
| 104 | + reg = <0>; | |
| 105 | + | |
| 106 | + phy0: ethernet-phy@0 { | |
| 107 | + reg = <0x0>; | |
| 108 | + }; | |
| 109 | + phy1: ethernet-phy@1 { | |
| 110 | + reg = <0x1>; | |
| 111 | + }; | |
| 112 | + phy5: ethernet-phy@5 { | |
| 113 | + reg = <0x5>; | |
| 114 | + }; | |
| 115 | + phy11: ethernet-phy@11 { | |
| 116 | + reg = <0x11>; | |
| 117 | + }; | |
| 118 | + phy13: ethernet-phy@13 { | |
| 119 | + reg = <0x13>; | |
| 120 | + }; | |
| 121 | + }; | |
| 122 | + | |
| 123 | + gphy-fw { | |
| 124 | + compatible = "lantiq,xrx200-gphy-fw", "lantiq,gphy-fw"; | |
| 125 | + lantiq,rcu = <&rcu0>; | |
| 126 | + #address-cells = <1>; | |
| 127 | + #size-cells = <0>; | |
| 128 | + | |
| 129 | + gphy@20 { | |
| 130 | + reg = <0x20>; | |
| 131 | + | |
| 132 | + resets = <&reset0 31 30>; | |
| 133 | + reset-names = "gphy"; | |
| 134 | + }; | |
| 135 | + | |
| 136 | + gphy@68 { | |
| 137 | + reg = <0x68>; | |
| 138 | + | |
| 139 | + resets = <&reset0 29 28>; | |
| 140 | + reset-names = "gphy"; | |
| 141 | + }; | |
| 142 | + }; | |
| 143 | +}; | |
| @@ -0,0 +1,21 @@ | ||
| 1 | +Lantiq xRX200 GSWIP PMAC Ethernet driver | |
| 2 | +================================== | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | + | |
| 6 | +- compatible : "lantiq,xrx200-net" for the PMAC of the embedded | |
| 7 | + : GSWIP in the xXR200 | |
| 8 | +- reg : memory range of the PMAC core inside of the GSWIP core | |
| 9 | +- interrupts : TX and RX DMA interrupts. Use interrupt-names "tx" for | |
| 10 | + : the TX interrupt and "rx" for the RX interrupt. | |
| 11 | + | |
| 12 | +Example: | |
| 13 | + | |
| 14 | +ethernet@e10b308 { | |
| 15 | + #address-cells = <1>; | |
| 16 | + #size-cells = <0>; | |
| 17 | + compatible = "lantiq,xrx200-net"; | |
| 18 | + reg = <0xe10b308 0xcf8>; | |
| 19 | + interrupts = <73>, <72>; | |
| 20 | + interrupt-names = "tx", "rx"; | |
| 21 | +}; | |
| @@ -2,7 +2,7 @@ Marvell Prestera Switch Chip bindings · 1 unmodified line | ||
| 2 | 2 | ------------------------------------- |
| 3 | 3 | |
| 4 | 4 | Required properties: |
| 5 | −- compatible: one of the following | |
| 5 | +- compatible: must be "marvell,prestera" and one of the following | |
| 6 | 6 | "marvell,prestera-98dx3236", |
| 7 | 7 | "marvell,prestera-98dx3336", |
| 8 | 8 | "marvell,prestera-98dx4251", |
| @@ -21,7 +21,7 @@ switch { · 12 unmodified lines | ||
| 21 | 21 | ranges = <0 MBUS_ID(0x03, 0x00) 0 0x100000>; |
| 22 | 22 | |
| 23 | 23 | packet-processor@0 { |
| 24 | − compatible = "marvell,prestera-98dx3236"; | |
| 24 | + compatible = "marvell,prestera-98dx3236", "marvell,prestera"; | |
| 25 | 25 | reg = <0 0x4000000>; |
| 26 | 26 | interrupts = <33>, <34>, <35>; |
| 27 | 27 | dfx = <&dfx>; |
| @@ -31,7 +31,7 @@ required. · 30 unmodified lines | ||
| 31 | 31 | |
| 32 | 32 | Required properties (port): |
| 33 | 33 | |
| 34 | −- interrupts: interrupt for the port | |
| 34 | +- interrupts: interrupt(s) for the port | |
| 35 | 35 | - port-id: ID of the port from the MAC point of view |
| 36 | 36 | - gop-port-id: only for marvell,armada-7k-pp2, ID of the port from the |
| 37 | 37 | GOP (Group Of Ports) point of view. This ID is used to index the |
| @@ -43,10 +43,12 @@ Optional properties (port): · 5 unmodified lines | ||
| 43 | 43 | - marvell,loopback: port is loopback mode |
| 44 | 44 | - phy: a phandle to a phy node defining the PHY address (as the reg |
| 45 | 45 | property, a single integer). |
| 46 | −- interrupt-names: if more than a single interrupt for rx is given, must | |
| 47 | − be the name associated to the interrupts listed. Valid | |
| 48 | − names are: "tx-cpu0", "tx-cpu1", "tx-cpu2", "tx-cpu3", | |
| 49 | − "rx-shared", "link". | |
| 46 | +- interrupt-names: if more than a single interrupt for is given, must be the | |
| 47 | + name associated to the interrupts listed. Valid names are: | |
| 48 | + "hifX", with X in [0..8], and "link". The names "tx-cpu0", | |
| 49 | + "tx-cpu1", "tx-cpu2", "tx-cpu3" and "rx-shared" are supported | |
| 50 | + for backward compatibility but shouldn't be used for new | |
| 51 | + additions. | |
| 50 | 52 | - marvell,system-controller: a phandle to the system controller. |
| 51 | 53 | |
| 52 | 54 | Example for marvell,armada-375-pp2: |
| @@ -89,9 +91,14 @@ cpm_ethernet: ethernet@0 { · 36 unmodified lines | ||
| 89 | 91 | <ICU_GRP_NSR 43 IRQ_TYPE_LEVEL_HIGH>, |
| 90 | 92 | <ICU_GRP_NSR 47 IRQ_TYPE_LEVEL_HIGH>, |
| 91 | 93 | <ICU_GRP_NSR 51 IRQ_TYPE_LEVEL_HIGH>, |
| 92 | − <ICU_GRP_NSR 55 IRQ_TYPE_LEVEL_HIGH>; | |
| 93 | − interrupt-names = "tx-cpu0", "tx-cpu1", "tx-cpu2", | |
| 94 | − "tx-cpu3", "rx-shared"; | |
| 94 | + <ICU_GRP_NSR 55 IRQ_TYPE_LEVEL_HIGH>, | |
| 95 | + <ICU_GRP_NSR 59 IRQ_TYPE_LEVEL_HIGH>, | |
| 96 | + <ICU_GRP_NSR 63 IRQ_TYPE_LEVEL_HIGH>, | |
| 97 | + <ICU_GRP_NSR 67 IRQ_TYPE_LEVEL_HIGH>, | |
| 98 | + <ICU_GRP_NSR 71 IRQ_TYPE_LEVEL_HIGH>, | |
| 99 | + <ICU_GRP_NSR 129 IRQ_TYPE_LEVEL_HIGH>; | |
| 100 | + interrupt-names = "hif0", "hif1", "hif2", "hif3", "hif4", | |
| 101 | + "hif5", "hif6", "hif7", "hif8", "link"; | |
| 95 | 102 | port-id = <0>; |
| 96 | 103 | gop-port-id = <0>; |
| 97 | 104 | }; |
| @@ -101,9 +108,14 @@ cpm_ethernet: ethernet@0 { · 3 unmodified lines | ||
| 101 | 108 | <ICU_GRP_NSR 44 IRQ_TYPE_LEVEL_HIGH>, |
| 102 | 109 | <ICU_GRP_NSR 48 IRQ_TYPE_LEVEL_HIGH>, |
| 103 | 110 | <ICU_GRP_NSR 52 IRQ_TYPE_LEVEL_HIGH>, |
| 104 | − <ICU_GRP_NSR 56 IRQ_TYPE_LEVEL_HIGH>; | |
| 105 | − interrupt-names = "tx-cpu0", "tx-cpu1", "tx-cpu2", | |
| 106 | − "tx-cpu3", "rx-shared"; | |
| 111 | + <ICU_GRP_NSR 56 IRQ_TYPE_LEVEL_HIGH>, | |
| 112 | + <ICU_GRP_NSR 60 IRQ_TYPE_LEVEL_HIGH>, | |
| 113 | + <ICU_GRP_NSR 64 IRQ_TYPE_LEVEL_HIGH>, | |
| 114 | + <ICU_GRP_NSR 68 IRQ_TYPE_LEVEL_HIGH>, | |
| 115 | + <ICU_GRP_NSR 72 IRQ_TYPE_LEVEL_HIGH>, | |
| 116 | + <ICU_GRP_NSR 128 IRQ_TYPE_LEVEL_HIGH>; | |
| 117 | + interrupt-names = "hif0", "hif1", "hif2", "hif3", "hif4", | |
| 118 | + "hif5", "hif6", "hif7", "hif8", "link"; | |
| 107 | 119 | port-id = <1>; |
| 108 | 120 | gop-port-id = <2>; |
| 109 | 121 | }; |
| @@ -113,9 +125,14 @@ cpm_ethernet: ethernet@0 { · 3 unmodified lines | ||
| 113 | 125 | <ICU_GRP_NSR 45 IRQ_TYPE_LEVEL_HIGH>, |
| 114 | 126 | <ICU_GRP_NSR 49 IRQ_TYPE_LEVEL_HIGH>, |
| 115 | 127 | <ICU_GRP_NSR 53 IRQ_TYPE_LEVEL_HIGH>, |
| 116 | − <ICU_GRP_NSR 57 IRQ_TYPE_LEVEL_HIGH>; | |
| 117 | − interrupt-names = "tx-cpu0", "tx-cpu1", "tx-cpu2", | |
| 118 | − "tx-cpu3", "rx-shared"; | |
| 128 | + <ICU_GRP_NSR 57 IRQ_TYPE_LEVEL_HIGH>, | |
| 129 | + <ICU_GRP_NSR 61 IRQ_TYPE_LEVEL_HIGH>, | |
| 130 | + <ICU_GRP_NSR 65 IRQ_TYPE_LEVEL_HIGH>, | |
| 131 | + <ICU_GRP_NSR 69 IRQ_TYPE_LEVEL_HIGH>, | |
| 132 | + <ICU_GRP_NSR 73 IRQ_TYPE_LEVEL_HIGH>, | |
| 133 | + <ICU_GRP_NSR 127 IRQ_TYPE_LEVEL_HIGH>; | |
| 134 | + interrupt-names = "hif0", "hif1", "hif2", "hif3", "hif4", | |
| 135 | + "hif5", "hif6", "hif7", "hif8", "link"; | |
| 119 | 136 | port-id = <2>; |
| 120 | 137 | gop-port-id = <3>; |
| 121 | 138 | }; |
| @@ -1,4 +1,4 @@ | ||
| 1 | −Micrel KSZ9021/KSZ9031 Gigabit Ethernet PHY | |
| 1 | +Micrel KSZ9021/KSZ9031/KSZ9131 Gigabit Ethernet PHY | |
| 2 | 2 | |
| 3 | 3 | Some boards require special tuning values, particularly when it comes |
| 4 | 4 | to clock delays. You can specify clock delay values in the PHY OF |
| @@ -64,6 +64,32 @@ KSZ9031: · 59 unmodified lines | ||
| 64 | 64 | Attention: The link partner must be configurable as slave otherwise |
| 65 | 65 | no link will be established. |
| 66 | 66 | |
| 67 | +KSZ9131: | |
| 68 | + | |
| 69 | + All skew control options are specified in picoseconds. The increment | |
| 70 | + step is 100ps. Unlike KSZ9031, the values represent picoseccond delays. | |
| 71 | + A negative value can be assigned as rxc-skew-psec = <(-100)>;. | |
| 72 | + | |
| 73 | + Optional properties: | |
| 74 | + | |
| 75 | + Range of the value -700 to 2400, default value 0: | |
| 76 | + | |
| 77 | + - rxc-skew-psec : Skew control of RX clock pad | |
| 78 | + - txc-skew-psec : Skew control of TX clock pad | |
| 79 | + | |
| 80 | + Range of the value -700 to 800, default value 0: | |
| 81 | + | |
| 82 | + - rxdv-skew-psec : Skew control of RX CTL pad | |
| 83 | + - txen-skew-psec : Skew control of TX CTL pad | |
| 84 | + - rxd0-skew-psec : Skew control of RX data 0 pad | |
| 85 | + - rxd1-skew-psec : Skew control of RX data 1 pad | |
| 86 | + - rxd2-skew-psec : Skew control of RX data 2 pad | |
| 87 | + - rxd3-skew-psec : Skew control of RX data 3 pad | |
| 88 | + - txd0-skew-psec : Skew control of TX data 0 pad | |
| 89 | + - txd1-skew-psec : Skew control of TX data 1 pad | |
| 90 | + - txd2-skew-psec : Skew control of TX data 2 pad | |
| 91 | + - txd3-skew-psec : Skew control of TX data 3 pad | |
| 92 | + | |
| 67 | 93 | Examples: |
| 68 | 94 | |
| 69 | 95 | mdio { |
| @@ -12,7 +12,6 @@ Required properties: · 11 unmodified lines | ||
| 12 | 12 | - "sys" |
| 13 | 13 | - "rew" |
| 14 | 14 | - "qs" |
| 15 | − - "hsio" | |
| 16 | 15 | - "qsys" |
| 17 | 16 | - "ana" |
| 18 | 17 | - "portX" with X from 0 to the number of last port index available on that |
| @@ -45,7 +44,6 @@ Example: · 26 unmodified lines | ||
| 45 | 44 | reg = <0x1010000 0x10000>, |
| 46 | 45 | <0x1030000 0x10000>, |
| 47 | 46 | <0x1080000 0x100>, |
| 48 | − <0x10d0000 0x10000>, | |
| 49 | 47 | <0x11e0000 0x100>, |
| 50 | 48 | <0x11f0000 0x100>, |
| 51 | 49 | <0x1200000 0x100>, |
| @@ -59,10 +57,9 @@ Example: · 7 unmodified lines | ||
| 59 | 57 | <0x1280000 0x100>, |
| 60 | 58 | <0x1800000 0x80000>, |
| 61 | 59 | <0x1880000 0x10000>; |
| 62 | − reg-names = "sys", "rew", "qs", "hsio", "port0", | |
| 63 | − "port1", "port2", "port3", "port4", "port5", | |
| 64 | − "port6", "port7", "port8", "port9", "port10", | |
| 65 | − "qsys", "ana"; | |
| 60 | + reg-names = "sys", "rew", "qs", "port0", "port1", "port2", | |
| 61 | + "port3", "port4", "port5", "port6", "port7", | |
| 62 | + "port8", "port9", "port10", "qsys", "ana"; | |
| 66 | 63 | interrupts = <21 22>; |
| 67 | 64 | interrupt-names = "xtr", "inj"; |
| 68 | 65 | |
| @@ -1,10 +1,5 @@ | ||
| 1 | 1 | * Microsemi - vsc8531 Giga bit ethernet phy |
| 2 | 2 | |
| 3 | −Required properties: | |
| 4 | −- compatible : Should contain phy id as "ethernet-phy-idAAAA.BBBB" | |
| 5 | − The PHY device uses the binding described in | |
| 6 | − Documentation/devicetree/bindings/net/phy.txt | |
| 7 | − | |
| 8 | 3 | Optional properties: |
| 9 | 4 | - vsc8531,vddmac : The vddmac in mV. Allowed values is listed |
| 10 | 5 | in the first row of Table 1 (below). |
| @@ -27,14 +22,16 @@ Optional properties: · 16 unmodified lines | ||
| 27 | 22 | 'vddmac'. |
| 28 | 23 | Default value is 0%. |
| 29 | 24 | Ref: Table:1 - Edge rate change (below). |
| 30 | −- vsc8531,led-0-mode : LED mode. Specify how the LED[0] should behave. | |
| 31 | − Allowed values are define in | |
| 32 | − "include/dt-bindings/net/mscc-phy-vsc8531.h". | |
| 33 | − Default value is VSC8531_LINK_1000_ACTIVITY (1). | |
| 34 | −- vsc8531,led-1-mode : LED mode. Specify how the LED[1] should behave. | |
| 35 | − Allowed values are define in | |
| 25 | +- vsc8531,led-[N]-mode : LED mode. Specify how the LED[N] should behave. | |
| 26 | + N depends on the number of LEDs supported by a | |
| 27 | + PHY. | |
| 28 | + Allowed values are defined in | |
| 36 | 29 | "include/dt-bindings/net/mscc-phy-vsc8531.h". |
| 37 | − Default value is VSC8531_LINK_100_ACTIVITY (2). | |
| 30 | + Default values are VSC8531_LINK_1000_ACTIVITY (1), | |
| 31 | + VSC8531_LINK_100_ACTIVITY (2), | |
| 32 | + VSC8531_LINK_ACTIVITY (0) and | |
| 33 | + VSC8531_DUPLEX_COLLISION (8). | |
| 34 | + | |
| 38 | 35 | |
| 39 | 36 | Table: 1 - Edge rate change |
| 40 | 37 | ----------------------------------------------------------------| |
| @@ -6,6 +6,7 @@ interface contains. · 5 unmodified lines | ||
| 6 | 6 | Required properties: |
| 7 | 7 | - compatible: Must contain one or more of the following: |
| 8 | 8 | - "renesas,etheravb-r8a7743" for the R8A7743 SoC. |
| 9 | + - "renesas,etheravb-r8a7744" for the R8A7744 SoC. | |
| 9 | 10 | - "renesas,etheravb-r8a7745" for the R8A7745 SoC. |
| 10 | 11 | - "renesas,etheravb-r8a77470" for the R8A77470 SoC. |
| 11 | 12 | - "renesas,etheravb-r8a7790" for the R8A7790 SoC. |
| @@ -56,6 +56,11 @@ Optional properties: · 55 unmodified lines | ||
| 56 | 56 | the length can vary between hw versions. |
| 57 | 57 | - <supply-name>-supply: handle to the regulator device tree node |
| 58 | 58 | optional "supply-name" is "vdd-0.8-cx-mx". |
| 59 | +- memory-region: | |
| 60 | + Usage: optional | |
| 61 | + Value type: <phandle> | |
| 62 | + Definition: reference to the reserved-memory for the msa region | |
| 63 | + used by the wifi firmware running in Q6. | |
| 59 | 64 | |
| 60 | 65 | Example (to supply the calibration data alone): |
| 61 | 66 | |
| @@ -149,4 +154,5 @@ wifi@18000000 { · 87 unmodified lines | ||
| 149 | 154 | <0 140 0 /* CE10 */ >, |
| 150 | 155 | <0 141 0 /* CE11 */ >; |
| 151 | 156 | vdd-0.8-cx-mx-supply = <&pm8998_l5>; |
| 157 | + memory-region = <&wifi_msa_mem>; | |
| 152 | 158 | }; |
| @@ -7,6 +7,7 @@ Required properties: · 6 unmodified lines | ||
| 7 | 7 | "allwinner,sun8i-a83t-sid" |
| 8 | 8 | "allwinner,sun8i-h3-sid" |
| 9 | 9 | "allwinner,sun50i-a64-sid" |
| 10 | + "allwinner,sun50i-h5-sid" | |
| 10 | 11 | |
| 11 | 12 | - reg: Should contain registers location and length |
| 12 | 13 | |
| @@ -50,6 +50,7 @@ Additional required properties for imx7d-pcie: · 49 unmodified lines | ||
| 50 | 50 | - reset-names: Must contain the following entires: |
| 51 | 51 | - "pciephy" |
| 52 | 52 | - "apps" |
| 53 | + - "turnoff" | |
| 53 | 54 | |
| 54 | 55 | Example: |
| 55 | 56 | |
| @@ -19,6 +19,9 @@ pcie_msi_intc : Interrupt controller device node for MSI IRQ chip · 18 unmodified lines | ||
| 19 | 19 | interrupt-cells: should be set to 1 |
| 20 | 20 | interrupts: GIC interrupt lines connected to PCI MSI interrupt lines |
| 21 | 21 | |
| 22 | +ti,syscon-pcie-id : phandle to the device control module required to set device | |
| 23 | + id and vendor id. | |
| 24 | + | |
| 22 | 25 | Example: |
| 23 | 26 | pcie_msi_intc: msi-interrupt-controller { |
| 24 | 27 | interrupt-controller; |
| @@ -7,6 +7,7 @@ OHCI and EHCI controllers. · 6 unmodified lines | ||
| 7 | 7 | |
| 8 | 8 | Required properties: |
| 9 | 9 | - compatible: "renesas,pci-r8a7743" for the R8A7743 SoC; |
| 10 | + "renesas,pci-r8a7744" for the R8A7744 SoC; | |
| 10 | 11 | "renesas,pci-r8a7745" for the R8A7745 SoC; |
| 11 | 12 | "renesas,pci-r8a7790" for the R8A7790 SoC; |
| 12 | 13 | "renesas,pci-r8a7791" for the R8A7791 SoC; |
| @@ -2,6 +2,7 @@ · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | compatible: "renesas,pcie-r8a7743" for the R8A7743 SoC; |
| 5 | + "renesas,pcie-r8a7744" for the R8A7744 SoC; | |
| 5 | 6 | "renesas,pcie-r8a7779" for the R8A7779 SoC; |
| 6 | 7 | "renesas,pcie-r8a7790" for the R8A7790 SoC; |
| 7 | 8 | "renesas,pcie-r8a7791" for the R8A7791 SoC; |
| @@ -9,6 +10,7 @@ compatible: "renesas,pcie-r8a7743" for the R8A7743 SoC; · 1 unmodified line | ||
| 9 | 10 | "renesas,pcie-r8a7795" for the R8A7795 SoC; |
| 10 | 11 | "renesas,pcie-r8a7796" for the R8A7796 SoC; |
| 11 | 12 | "renesas,pcie-r8a77980" for the R8A77980 SoC; |
| 13 | + "renesas,pcie-r8a77990" for the R8A77990 SoC; | |
| 12 | 14 | "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 or |
| 13 | 15 | RZ/G1 compatible device. |
| 14 | 16 | "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 compatible device. |
| @@ -26,6 +26,11 @@ HOST MODE · 25 unmodified lines | ||
| 26 | 26 | ranges, |
| 27 | 27 | interrupt-map-mask, |
| 28 | 28 | interrupt-map : as specified in ../designware-pcie.txt |
| 29 | + - ti,syscon-unaligned-access: phandle to the syscon DT node. The 1st argument | |
| 30 | + should contain the register offset within syscon | |
| 31 | + and the 2nd argument should contain the bit field | |
| 32 | + for setting the bit to enable unaligned | |
| 33 | + access. | |
| 29 | 34 | |
| 30 | 35 | DEVICE MODE |
| 31 | 36 | =========== |
| @@ -8,6 +8,7 @@ Required properties: · 7 unmodified lines | ||
| 8 | 8 | "brcm,iproc-nsp-sata-phy" |
| 9 | 9 | "brcm,phy-sata3" |
| 10 | 10 | "brcm,iproc-sr-sata-phy" |
| 11 | + "brcm,bcm63138-sata-phy" | |
| 11 | 12 | - address-cells: should be 1 |
| 12 | 13 | - size-cells: should be 0 |
| 13 | 14 | - reg: register ranges for the PHY PCB interface |
| @@ -0,0 +1,30 @@ | ||
| 1 | +Cadence MHDP DisplayPort SD0801 PHY binding | |
| 2 | +=========================================== | |
| 3 | + | |
| 4 | +This binding describes the Cadence SD0801 PHY hardware included with | |
| 5 | +the Cadence MHDP DisplayPort controller. | |
| 6 | + | |
| 7 | +------------------------------------------------------------------------------- | |
| 8 | +Required properties (controller (parent) node): | |
| 9 | +- compatible : Should be "cdns,dp-phy" | |
| 10 | +- reg : Defines the following sets of registers in the parent | |
| 11 | + mhdp device: | |
| 12 | + - Offset of the DPTX PHY configuration registers | |
| 13 | + - Offset of the SD0801 PHY configuration registers | |
| 14 | +- #phy-cells : from the generic PHY bindings, must be 0. | |
| 15 | + | |
| 16 | +Optional properties: | |
| 17 | +- num_lanes : Number of DisplayPort lanes to use (1, 2 or 4) | |
| 18 | +- max_bit_rate : Maximum DisplayPort link bit rate to use, in Mbps (2160, | |
| 19 | + 2430, 2700, 3240, 4320, 5400 or 8100) | |
| 20 | +------------------------------------------------------------------------------- | |
| 21 | + | |
| 22 | +Example: | |
| 23 | + dp_phy: phy@f0fb030a00 { | |
| 24 | + compatible = "cdns,dp-phy"; | |
| 25 | + reg = <0xf0 0xfb030a00 0x0 0x00000040>, | |
| 26 | + <0xf0 0xfb500000 0x0 0x00100000>; | |
| 27 | + num_lanes = <4>; | |
| 28 | + max_bit_rate = <8100>; | |
| 29 | + #phy-cells = <0>; | |
| 30 | + }; | |
| @@ -0,0 +1,43 @@ | ||
| 1 | +Microsemi Ocelot SerDes muxing driver | |
| 2 | +------------------------------------- | |
| 3 | + | |
| 4 | +On Microsemi Ocelot, there is a handful of registers in HSIO address | |
| 5 | +space for setting up the SerDes to switch port muxing. | |
| 6 | + | |
| 7 | +A SerDes X can be "muxed" to work with switch port Y or Z for example. | |
| 8 | +One specific SerDes can also be used as a PCIe interface. | |
| 9 | + | |
| 10 | +Hence, a SerDes represents an interface, be it an Ethernet or a PCIe one. | |
| 11 | + | |
| 12 | +There are two kinds of SerDes: SERDES1G supports 10/100Mbps in | |
| 13 | +half/full-duplex and 1000Mbps in full-duplex mode while SERDES6G supports | |
| 14 | +10/100Mbps in half/full-duplex and 1000/2500Mbps in full-duplex mode. | |
| 15 | + | |
| 16 | +Also, SERDES6G number (aka "macro") 0 is the only interface supporting | |
| 17 | +QSGMII. | |
| 18 | + | |
| 19 | +This is a child of the HSIO syscon ("mscc,ocelot-hsio", see | |
| 20 | +Documentation/devicetree/bindings/mips/mscc.txt) on the Microsemi Ocelot. | |
| 21 | + | |
| 22 | +Required properties: | |
| 23 | + | |
| 24 | +- compatible: should be "mscc,vsc7514-serdes" | |
| 25 | +- #phy-cells : from the generic phy bindings, must be 2. | |
| 26 | + The first number defines the input port to use for a given | |
| 27 | + SerDes macro. The second defines the macro to use. They are | |
| 28 | + defined in dt-bindings/phy/phy-ocelot-serdes.h | |
| 29 | + | |
| 30 | +Example: | |
| 31 | + | |
| 32 | + serdes: serdes { | |
| 33 | + compatible = "mscc,vsc7514-serdes"; | |
| 34 | + #phy-cells = <2>; | |
| 35 | + }; | |
| 36 | + | |
| 37 | + ethernet { | |
| 38 | + port1 { | |
| 39 | + phy-handle = <&phy_foo>; | |
| 40 | + /* Link SERDES1G_5 to port1 */ | |
| 41 | + phys = <&serdes 1 SERDES1G_5>; | |
| 42 | + }; | |
| 43 | + }; | |
| @@ -0,0 +1,43 @@ | ||
| 1 | +ROCKCHIP HDMI PHY WITH INNO IP BLOCK | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible : should be one of the listed compatibles: | |
| 5 | + * "rockchip,rk3228-hdmi-phy", | |
| 6 | + * "rockchip,rk3328-hdmi-phy"; | |
| 7 | + - reg : Address and length of the hdmi phy control register set | |
| 8 | + - clocks : phandle + clock specifier for the phy clocks | |
| 9 | + - clock-names : string, clock name, must contain "sysclk" for system | |
| 10 | + control and register configuration, "refoclk" for crystal- | |
| 11 | + oscillator reference PLL clock input and "refpclk" for pclk- | |
| 12 | + based refeference PLL clock input. | |
| 13 | + - #clock-cells: should be 0. | |
| 14 | + - clock-output-names : shall be the name for the output clock. | |
| 15 | + - interrupts : phandle + interrupt specified for the hdmiphy interrupt | |
| 16 | + - #phy-cells : must be 0. See ./phy-bindings.txt for details. | |
| 17 | + | |
| 18 | +Optional properties for rk3328-hdmi-phy: | |
| 19 | + - nvmem-cells = phandle + nvmem specifier for the cpu-version efuse | |
| 20 | + - nvmem-cell-names : "cpu-version" to read the chip version, required | |
| 21 | + for adjustment to some frequency settings | |
| 22 | + | |
| 23 | +Example: | |
| 24 | + hdmi_phy: hdmi-phy@12030000 { | |
| 25 | + compatible = "rockchip,rk3228-hdmi-phy"; | |
| 26 | + reg = <0x12030000 0x10000>; | |
| 27 | + #phy-cells = <0>; | |
| 28 | + clocks = <&cru PCLK_HDMI_PHY>, <&xin24m>, <&cru DCLK_HDMIPHY>; | |
| 29 | + clock-names = "sysclk", "refoclk", "refpclk"; | |
| 30 | + #clock-cells = <0>; | |
| 31 | + clock-output-names = "hdmi_phy"; | |
| 32 | + status = "disabled"; | |
| 33 | + }; | |
| 34 | + | |
| 35 | +Then the PHY can be used in other nodes such as: | |
| 36 | + | |
| 37 | + hdmi: hdmi@200a0000 { | |
| 38 | + compatible = "rockchip,rk3228-dw-hdmi"; | |
| 39 | + ... | |
| 40 | + phys = <&hdmi_phy>; | |
| 41 | + phy-names = "hdmi"; | |
| 42 | + ... | |
| 43 | + }; | |
| @@ -10,16 +10,20 @@ Required properties: · 9 unmodified lines | ||
| 10 | 10 | "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996, |
| 11 | 11 | "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996, |
| 12 | 12 | "qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845, |
| 13 | − "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845. | |
| 13 | + "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845, | |
| 14 | + "qcom,sdm845-qmp-ufs-phy" for UFS QMP phy on sdm845. | |
| 14 | 15 | |
| 15 | − - reg: | |
| 16 | − - For "qcom,sdm845-qmp-usb3-phy": | |
| 17 | − - index 0: address and length of register set for PHY's common serdes | |
| 18 | − block. | |
| 19 | − - named register "dp_com" (using reg-names): address and length of the | |
| 20 | − DP_COM control block. | |
| 21 | − - For all others: | |
| 22 | − - offset and length of register set for PHY's common serdes block. | |
| 16 | +- reg: | |
| 17 | + - index 0: address and length of register set for PHY's common | |
| 18 | + serdes block. | |
| 19 | + - index 1: address and length of the DP_COM control block (for | |
| 20 | + "qcom,sdm845-qmp-usb3-phy" only). | |
| 21 | + | |
| 22 | +- reg-names: | |
| 23 | + - For "qcom,sdm845-qmp-usb3-phy": | |
| 24 | + - Should be: "reg-base", "dp_com" | |
| 25 | + - For all others: | |
| 26 | + - The reg-names property shouldn't be defined. | |
| 23 | 27 | |
| 24 | 28 | - #clock-cells: must be 1 |
| 25 | 29 | - Phy pll outputs a bunch of clocks for Tx, Rx and Pipe |
| @@ -35,6 +39,7 @@ Required properties: · 9 unmodified lines | ||
| 35 | 39 | "aux" for phy aux clock, |
| 36 | 40 | "ref" for 19.2 MHz ref clk, |
| 37 | 41 | "com_aux" for phy common block aux clock, |
| 42 | + "ref_aux" for phy reference aux clock, | |
| 38 | 43 | For "qcom,msm8996-qmp-pcie-phy" must contain: |
| 39 | 44 | "aux", "cfg_ahb", "ref". |
| 40 | 45 | For "qcom,msm8996-qmp-usb3-phy" must contain: |
| @@ -5,6 +5,7 @@ This file provides information on what the device node for the R-Car generation · 4 unmodified lines | ||
| 5 | 5 | |
| 6 | 6 | Required properties: |
| 7 | 7 | - compatible: "renesas,usb-phy-r8a7743" if the device is a part of R8A7743 SoC. |
| 8 | + "renesas,usb-phy-r8a7744" if the device is a part of R8A7744 SoC. | |
| 8 | 9 | "renesas,usb-phy-r8a7745" if the device is a part of R8A7745 SoC. |
| 9 | 10 | "renesas,usb-phy-r8a7790" if the device is a part of R8A7790 SoC. |
| 10 | 11 | "renesas,usb-phy-r8a7791" if the device is a part of R8A7791 SoC. |
| @@ -1,10 +1,12 @@ | ||
| 1 | 1 | * Renesas R-Car generation 3 USB 2.0 PHY |
| 2 | 2 | |
| 3 | 3 | This file provides information on what the device node for the R-Car generation |
| 4 | −3 USB 2.0 PHY contains. | |
| 4 | +3 and RZ/G2 USB 2.0 PHY contain. | |
| 5 | 5 | |
| 6 | 6 | Required properties: |
| 7 | −- compatible: "renesas,usb2-phy-r8a7795" if the device is a part of an R8A7795 | |
| 7 | +- compatible: "renesas,usb2-phy-r8a774a1" if the device is a part of an R8A774A1 | |
| 8 | + SoC. | |
| 9 | + "renesas,usb2-phy-r8a7795" if the device is a part of an R8A7795 | |
| 8 | 10 | SoC. |
| 9 | 11 | "renesas,usb2-phy-r8a7796" if the device is a part of an R8A7796 |
| 10 | 12 | SoC. |
| @@ -14,7 +16,8 @@ Required properties: · 3 unmodified lines | ||
| 14 | 16 | R8A77990 SoC. |
| 15 | 17 | "renesas,usb2-phy-r8a77995" if the device is a part of an |
| 16 | 18 | R8A77995 SoC. |
| 17 | − "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 compatible device. | |
| 19 | + "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 or RZ/G2 | |
| 20 | + compatible device. | |
| 18 | 21 | |
| 19 | 22 | When compatible with the generic version, nodes must list the |
| 20 | 23 | SoC-specific version corresponding to the platform first |
| @@ -31,6 +34,8 @@ channel as USB OTG: · 10 unmodified lines | ||
| 31 | 34 | - interrupts: interrupt specifier for the PHY. |
| 32 | 35 | - vbus-supply: Phandle to a regulator that provides power to the VBUS. This |
| 33 | 36 | regulator will be managed during the PHY power on/off sequence. |
| 37 | +- renesas,no-otg-pins: boolean, specify when a board does not provide proper | |
| 38 | + otg pins. | |
| 34 | 39 | |
| 35 | 40 | Example (R-Car H3): |
| 36 | 41 | |
| @@ -1,20 +1,22 @@ | ||
| 1 | 1 | * Renesas R-Car generation 3 USB 3.0 PHY |
| 2 | 2 | |
| 3 | 3 | This file provides information on what the device node for the R-Car generation |
| 4 | −3 USB 3.0 PHY contains. | |
| 4 | +3 and RZ/G2 USB 3.0 PHY contain. | |
| 5 | 5 | If you want to enable spread spectrum clock (ssc), you should use USB_EXTAL |
| 6 | 6 | instead of USB3_CLK. However, if you don't want to these features, you don't |
| 7 | 7 | need this driver. |
| 8 | 8 | |
| 9 | 9 | Required properties: |
| 10 | −- compatible: "renesas,r8a7795-usb3-phy" if the device is a part of an R8A7795 | |
| 10 | +- compatible: "renesas,r8a774a1-usb3-phy" if the device is a part of an R8A774A1 | |
| 11 | + SoC. | |
| 12 | + "renesas,r8a7795-usb3-phy" if the device is a part of an R8A7795 | |
| 11 | 13 | SoC. |
| 12 | 14 | "renesas,r8a7796-usb3-phy" if the device is a part of an R8A7796 |
| 13 | 15 | SoC. |
| 14 | 16 | "renesas,r8a77965-usb3-phy" if the device is a part of an |
| 15 | 17 | R8A77965 SoC. |
| 16 | − "renesas,rcar-gen3-usb3-phy" for a generic R-Car Gen3 compatible | |
| 17 | − device. | |
| 18 | + "renesas,rcar-gen3-usb3-phy" for a generic R-Car Gen3 or RZ/G2 | |
| 19 | + compatible device. | |
| 18 | 20 | |
| 19 | 21 | When compatible with the generic version, nodes must list the |
| 20 | 22 | SoC-specific version corresponding to the platform first |
| @@ -0,0 +1,31 @@ | ||
| 1 | +Socionext UniPhier PCIe PHY bindings | |
| 2 | + | |
| 3 | +This describes the devicetree bindings for PHY interface built into | |
| 4 | +PCIe controller implemented on Socionext UniPhier SoCs. | |
| 5 | + | |
| 6 | +Required properties: | |
| 7 | +- compatible: Should contain one of the following: | |
| 8 | + "socionext,uniphier-ld20-pcie-phy" - for LD20 PHY | |
| 9 | + "socionext,uniphier-pxs3-pcie-phy" - for PXs3 PHY | |
| 10 | +- reg: Specifies offset and length of the register set for the device. | |
| 11 | +- #phy-cells: Must be zero. | |
| 12 | +- clocks: A phandle to the clock gate for PCIe glue layer including | |
| 13 | + this phy. | |
| 14 | +- resets: A phandle to the reset line for PCIe glue layer including | |
| 15 | + this phy. | |
| 16 | + | |
| 17 | +Optional properties: | |
| 18 | +- socionext,syscon: A phandle to system control to set configurations | |
| 19 | + for phy. | |
| 20 | + | |
| 21 | +Refer to phy/phy-bindings.txt for the generic PHY binding properties. | |
| 22 | + | |
| 23 | +Example: | |
| 24 | + pcie_phy: phy@66038000 { | |
| 25 | + compatible = "socionext,uniphier-ld20-pcie-phy"; | |
| 26 | + reg = <0x66038000 0x4000>; | |
| 27 | + #phy-cells = <0>; | |
| 28 | + clocks = <&sys_clk 24>; | |
| 29 | + resets = <&sys_rst 24>; | |
| 30 | + socionext,syscon = <&soc_glue>; | |
| 31 | + }; | |
| @@ -0,0 +1,45 @@ | ||
| 1 | +Socionext UniPhier USB2 PHY | |
| 2 | + | |
| 3 | +This describes the devicetree bindings for PHY interface built into | |
| 4 | +USB2 controller implemented on Socionext UniPhier SoCs. | |
| 5 | + | |
| 6 | +Pro4 SoC has both USB2 and USB3 host controllers, however, this USB3 | |
| 7 | +controller doesn't include its own High-Speed PHY. This needs to specify | |
| 8 | +USB2 PHY instead of USB3 HS-PHY. | |
| 9 | + | |
| 10 | +Required properties: | |
| 11 | +- compatible: Should contain one of the following: | |
| 12 | + "socionext,uniphier-pro4-usb2-phy" - for Pro4 SoC | |
| 13 | + "socionext,uniphier-ld11-usb2-phy" - for LD11 SoC | |
| 14 | + | |
| 15 | +Sub-nodes: | |
| 16 | +Each PHY should be represented as a sub-node. | |
| 17 | + | |
| 18 | +Sub-nodes required properties: | |
| 19 | +- #phy-cells: Should be 0. | |
| 20 | +- reg: The number of the PHY. | |
| 21 | + | |
| 22 | +Sub-nodes optional properties: | |
| 23 | +- vbus-supply: A phandle to the regulator for USB VBUS. | |
| 24 | + | |
| 25 | +Refer to phy/phy-bindings.txt for the generic PHY binding properties. | |
| 26 | + | |
| 27 | +Example: | |
| 28 | + soc-glue@5f800000 { | |
| 29 | + ... | |
| 30 | + usb-phy { | |
| 31 | + compatible = "socionext,uniphier-ld11-usb2-phy"; | |
| 32 | + usb_phy0: phy@0 { | |
| 33 | + reg = <0>; | |
| 34 | + #phy-cells = <0>; | |
| 35 | + }; | |
| 36 | + ... | |
| 37 | + }; | |
| 38 | + }; | |
| 39 | + | |
| 40 | + usb@5a800100 { | |
| 41 | + compatible = "socionext,uniphier-ehci", "generic-ehci"; | |
| 42 | + ... | |
| 43 | + phy-names = "usb"; | |
| 44 | + phys = <&usb_phy0>; | |
| 45 | + }; | |
| @@ -0,0 +1,69 @@ | ||
| 1 | +Socionext UniPhier USB3 High-Speed (HS) PHY | |
| 2 | + | |
| 3 | +This describes the devicetree bindings for PHY interfaces built into | |
| 4 | +USB3 controller implemented on Socionext UniPhier SoCs. | |
| 5 | +Although the controller includes High-Speed PHY and Super-Speed PHY, | |
| 6 | +this describes about High-Speed PHY. | |
| 7 | + | |
| 8 | +Required properties: | |
| 9 | +- compatible: Should contain one of the following: | |
| 10 | + "socionext,uniphier-pro4-usb3-hsphy" - for Pro4 SoC | |
| 11 | + "socionext,uniphier-pxs2-usb3-hsphy" - for PXs2 SoC | |
| 12 | + "socionext,uniphier-ld20-usb3-hsphy" - for LD20 SoC | |
| 13 | + "socionext,uniphier-pxs3-usb3-hsphy" - for PXs3 SoC | |
| 14 | +- reg: Specifies offset and length of the register set for the device. | |
| 15 | +- #phy-cells: Should be 0. | |
| 16 | +- clocks: A list of phandles to the clock gate for USB3 glue layer. | |
| 17 | + According to the clock-names, appropriate clocks are required. | |
| 18 | +- clock-names: Should contain the following: | |
| 19 | + "gio", "link" - for Pro4 SoC | |
| 20 | + "phy", "phy-ext", "link" - for PXs3 SoC, "phy-ext" is optional. | |
| 21 | + "phy", "link" - for others | |
| 22 | +- resets: A list of phandles to the reset control for USB3 glue layer. | |
| 23 | + According to the reset-names, appropriate resets are required. | |
| 24 | +- reset-names: Should contain the following: | |
| 25 | + "gio", "link" - for Pro4 SoC | |
| 26 | + "phy", "link" - for others | |
| 27 | + | |
| 28 | +Optional properties: | |
| 29 | +- vbus-supply: A phandle to the regulator for USB VBUS. | |
| 30 | +- nvmem-cells: Phandles to nvmem cell that contains the trimming data. | |
| 31 | + Available only for HS-PHY implemented on LD20 and PXs3, and | |
| 32 | + if unspecified, default value is used. | |
| 33 | +- nvmem-cell-names: Should be the following names, which correspond to | |
| 34 | + each nvmem-cells. | |
| 35 | + All of the 3 parameters associated with the following names are | |
| 36 | + required for each port, if any one is omitted, the trimming data | |
| 37 | + of the port will not be set at all. | |
| 38 | + "rterm", "sel_t", "hs_i" - Each cell name for phy parameters | |
| 39 | + | |
| 40 | +Refer to phy/phy-bindings.txt for the generic PHY binding properties. | |
| 41 | + | |
| 42 | +Example: | |
| 43 | + | |
| 44 | + usb-glue@65b00000 { | |
| 45 | + compatible = "socionext,uniphier-ld20-dwc3-glue", | |
| 46 | + "simple-mfd"; | |
| 47 | + #address-cells = <1>; | |
| 48 | + #size-cells = <1>; | |
| 49 | + ranges = <0 0x65b00000 0x400>; | |
| 50 | + | |
| 51 | + usb_vbus0: regulator { | |
| 52 | + ... | |
| 53 | + }; | |
| 54 | + | |
| 55 | + usb_hsphy0: hs-phy@200 { | |
| 56 | + compatible = "socionext,uniphier-ld20-usb3-hsphy"; | |
| 57 | + reg = <0x200 0x10>; | |
| 58 | + #phy-cells = <0>; | |
| 59 | + clock-names = "link", "phy"; | |
| 60 | + clocks = <&sys_clk 14>, <&sys_clk 16>; | |
| 61 | + reset-names = "link", "phy"; | |
| 62 | + resets = <&sys_rst 14>, <&sys_rst 16>; | |
| 63 | + vbus-supply = <&usb_vbus0>; | |
| 64 | + nvmem-cell-names = "rterm", "sel_t", "hs_i"; | |
| 65 | + nvmem-cells = <&usb_rterm0>, <&usb_sel_t0>, | |
| 66 | + <&usb_hs_i0>; | |
| 67 | + }; | |
| 68 | + ... | |
| 69 | + }; | |
| @@ -0,0 +1,57 @@ | ||
| 1 | +Socionext UniPhier USB3 Super-Speed (SS) PHY | |
| 2 | + | |
| 3 | +This describes the devicetree bindings for PHY interfaces built into | |
| 4 | +USB3 controller implemented on Socionext UniPhier SoCs. | |
| 5 | +Although the controller includes High-Speed PHY and Super-Speed PHY, | |
| 6 | +this describes about Super-Speed PHY. | |
| 7 | + | |
| 8 | +Required properties: | |
| 9 | +- compatible: Should contain one of the following: | |
| 10 | + "socionext,uniphier-pro4-usb3-ssphy" - for Pro4 SoC | |
| 11 | + "socionext,uniphier-pxs2-usb3-ssphy" - for PXs2 SoC | |
| 12 | + "socionext,uniphier-ld20-usb3-ssphy" - for LD20 SoC | |
| 13 | + "socionext,uniphier-pxs3-usb3-ssphy" - for PXs3 SoC | |
| 14 | +- reg: Specifies offset and length of the register set for the device. | |
| 15 | +- #phy-cells: Should be 0. | |
| 16 | +- clocks: A list of phandles to the clock gate for USB3 glue layer. | |
| 17 | + According to the clock-names, appropriate clocks are required. | |
| 18 | +- clock-names: | |
| 19 | + "gio", "link" - for Pro4 SoC | |
| 20 | + "phy", "phy-ext", "link" - for PXs3 SoC, "phy-ext" is optional. | |
| 21 | + "phy", "link" - for others | |
| 22 | +- resets: A list of phandles to the reset control for USB3 glue layer. | |
| 23 | + According to the reset-names, appropriate resets are required. | |
| 24 | +- reset-names: | |
| 25 | + "gio", "link" - for Pro4 SoC | |
| 26 | + "phy", "link" - for others | |
| 27 | + | |
| 28 | +Optional properties: | |
| 29 | +- vbus-supply: A phandle to the regulator for USB VBUS. | |
| 30 | + | |
| 31 | +Refer to phy/phy-bindings.txt for the generic PHY binding properties. | |
| 32 | + | |
| 33 | +Example: | |
| 34 | + | |
| 35 | + usb-glue@65b00000 { | |
| 36 | + compatible = "socionext,uniphier-ld20-dwc3-glue", | |
| 37 | + "simple-mfd"; | |
| 38 | + #address-cells = <1>; | |
| 39 | + #size-cells = <1>; | |
| 40 | + ranges = <0 0x65b00000 0x400>; | |
| 41 | + | |
| 42 | + usb_vbus0: regulator { | |
| 43 | + ... | |
| 44 | + }; | |
| 45 | + | |
| 46 | + usb_ssphy0: ss-phy@300 { | |
| 47 | + compatible = "socionext,uniphier-ld20-usb3-ssphy"; | |
| 48 | + reg = <0x300 0x10>; | |
| 49 | + #phy-cells = <0>; | |
| 50 | + clock-names = "link", "phy"; | |
| 51 | + clocks = <&sys_clk 14>, <&sys_clk 16>; | |
| 52 | + reset-names = "link", "phy"; | |
| 53 | + resets = <&sys_rst 14>, <&sys_rst 16>; | |
| 54 | + vbus-supply = <&usb_vbus0>; | |
| 55 | + }; | |
| 56 | + ... | |
| 57 | + }; | |
| @@ -0,0 +1,57 @@ | ||
| 1 | +Broadcom Northstar pins mux controller | |
| 2 | + | |
| 3 | +Some of Northstar SoCs's pins can be used for various purposes thanks to the mux | |
| 4 | +controller. This binding allows describing mux controller and listing available | |
| 5 | +functions. They can be referenced later by other bindings to let system | |
| 6 | +configure controller correctly. | |
| 7 | + | |
| 8 | +A list of pins varies across chipsets so few bindings are available. | |
| 9 | + | |
| 10 | +Required properties: | |
| 11 | +- compatible: must be one of: | |
| 12 | + "brcm,bcm4708-pinmux" | |
| 13 | + "brcm,bcm4709-pinmux" | |
| 14 | + "brcm,bcm53012-pinmux" | |
| 15 | +- reg: iomem address range of CRU (Central Resource Unit) pin registers | |
| 16 | +- reg-names: "cru_gpio_control" - the only needed & supported reg right now | |
| 17 | + | |
| 18 | +Functions and their groups available for all chipsets: | |
| 19 | +- "spi": "spi_grp" | |
| 20 | +- "i2c": "i2c_grp" | |
| 21 | +- "pwm": "pwm0_grp", "pwm1_grp", "pwm2_grp", "pwm3_grp" | |
| 22 | +- "uart1": "uart1_grp" | |
| 23 | + | |
| 24 | +Additionally available on BCM4709 and BCM53012: | |
| 25 | +- "mdio": "mdio_grp" | |
| 26 | +- "uart2": "uart2_grp" | |
| 27 | +- "sdio": "sdio_pwr_grp", "sdio_1p8v_grp" | |
| 28 | + | |
| 29 | +For documentation of subnodes see: | |
| 30 | +Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt | |
| 31 | + | |
| 32 | +Example: | |
| 33 | + dmu@1800c000 { | |
| 34 | + compatible = "simple-bus"; | |
| 35 | + ranges = <0 0x1800c000 0x1000>; | |
| 36 | + #address-cells = <1>; | |
| 37 | + #size-cells = <1>; | |
| 38 | + | |
| 39 | + cru@100 { | |
| 40 | + compatible = "simple-bus"; | |
| 41 | + reg = <0x100 0x1a4>; | |
| 42 | + ranges; | |
| 43 | + #address-cells = <1>; | |
| 44 | + #size-cells = <1>; | |
| 45 | + | |
| 46 | + pin-controller@1c0 { | |
| 47 | + compatible = "brcm,bcm4708-pinmux"; | |
| 48 | + reg = <0x1c0 0x24>; | |
| 49 | + reg-names = "cru_gpio_control"; | |
| 50 | + | |
| 51 | + spi-pins { | |
| 52 | + function = "spi"; | |
| 53 | + groups = "spi_grp"; | |
| 54 | + }; | |
| 55 | + }; | |
| 56 | + }; | |
| 57 | + }; | |
| @@ -20,16 +20,30 @@ Required properties: · 19 unmodified lines | ||
| 20 | 20 | |
| 21 | 21 | - compatible: One of: |
| 22 | 22 | - "ingenic,jz4740-pinctrl" |
| 23 | + - "ingenic,jz4725b-pinctrl" | |
| 23 | 24 | - "ingenic,jz4770-pinctrl" |
| 24 | 25 | - "ingenic,jz4780-pinctrl" |
| 25 | 26 | - reg: Address range of the pinctrl registers. |
| 26 | 27 | |
| 27 | 28 | |
| 28 | −GPIO sub-nodes | |
| 29 | −-------------- | |
| 29 | +Required properties for sub-nodes (GPIO chips): | |
| 30 | +----------------------------------------------- | |
| 30 | 31 | |
| 31 | −The pinctrl node can have optional sub-nodes for the Ingenic GPIO driver; | |
| 32 | −please refer to ../gpio/ingenic,gpio.txt. | |
| 32 | + - compatible: Must contain one of: | |
| 33 | + - "ingenic,jz4740-gpio" | |
| 34 | + - "ingenic,jz4770-gpio" | |
| 35 | + - "ingenic,jz4780-gpio" | |
| 36 | + - reg: The GPIO bank number. | |
| 37 | + - interrupt-controller: Marks the device node as an interrupt controller. | |
| 38 | + - interrupts: Interrupt specifier for the controllers interrupt. | |
| 39 | + - #interrupt-cells: Should be 2. Refer to | |
| 40 | + ../interrupt-controller/interrupts.txt for more details. | |
| 41 | + - gpio-controller: Marks the device node as a GPIO controller. | |
| 42 | + - #gpio-cells: Should be 2. The first cell is the GPIO number and the second | |
| 43 | + cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the | |
| 44 | + GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported. | |
| 45 | + - gpio-ranges: Range of pins managed by the GPIO controller. Refer to | |
| 46 | + ../gpio/gpio.txt for more details. | |
| 33 | 47 | |
| 34 | 48 | |
| 35 | 49 | Example: |
| @@ -38,4 +52,21 @@ Example: · 2 unmodified lines | ||
| 38 | 52 | pinctrl: pin-controller@10010000 { |
| 39 | 53 | compatible = "ingenic,jz4740-pinctrl"; |
| 40 | 54 | reg = <0x10010000 0x400>; |
| 55 | + #address-cells = <1>; | |
| 56 | + #size-cells = <0>; | |
| 57 | + | |
| 58 | + gpa: gpio@0 { | |
| 59 | + compatible = "ingenic,jz4740-gpio"; | |
| 60 | + reg = <0>; | |
| 61 | + | |
| 62 | + gpio-controller; | |
| 63 | + gpio-ranges = <&pinctrl 0 0 32>; | |
| 64 | + #gpio-cells = <2>; | |
| 65 | + | |
| 66 | + interrupt-controller; | |
| 67 | + #interrupt-cells = <2>; | |
| 68 | + | |
| 69 | + interrupt-parent = <&intc>; | |
| 70 | + interrupts = <28>; | |
| 71 | + }; | |
| 41 | 72 | }; |
| @@ -13,6 +13,8 @@ Required properties for the root node: · 12 unmodified lines | ||
| 13 | 13 | "amlogic,meson-gxl-aobus-pinctrl" |
| 14 | 14 | "amlogic,meson-axg-periphs-pinctrl" |
| 15 | 15 | "amlogic,meson-axg-aobus-pinctrl" |
| 16 | + "amlogic,meson-g12a-periphs-pinctrl" | |
| 17 | + "amlogic,meson-g12a-aobus-pinctrl" | |
| 16 | 18 | - reg: address and size of registers controlling irq functionality |
| 17 | 19 | |
| 18 | 20 | === GPIO sub-nodes === |
| @@ -0,0 +1,216 @@ | ||
| 1 | +Nuvoton NPCM7XX Pin Controllers | |
| 2 | + | |
| 3 | +The Nuvoton BMC NPCM7XX Pin Controller multi-function routed through | |
| 4 | +the multiplexing block, Each pin supports GPIO functionality (GPIOx) | |
| 5 | +and multiple functions that directly connect the pin to different | |
| 6 | +hardware blocks. | |
| 7 | + | |
| 8 | +Required properties: | |
| 9 | +- #address-cells : should be 1. | |
| 10 | +- #size-cells : should be 1. | |
| 11 | +- compatible : "nuvoton,npcm750-pinctrl" for Poleg NPCM7XX. | |
| 12 | +- ranges : defines mapping ranges between pin controller node (parent) | |
| 13 | + to GPIO bank node (children). | |
| 14 | + | |
| 15 | +=== GPIO Bank Subnode === | |
| 16 | + | |
| 17 | +The NPCM7XX has 8 GPIO Banks each GPIO bank supports 32 GPIO. | |
| 18 | + | |
| 19 | +Required GPIO Bank subnode-properties: | |
| 20 | +- reg : specifies physical base address and size of the GPIO | |
| 21 | + bank registers. | |
| 22 | +- gpio-controller : Marks the device node as a GPIO controller. | |
| 23 | +- #gpio-cells : Must be <2>. The first cell is the gpio pin number | |
| 24 | + and the second cell is used for optional parameters. | |
| 25 | +- interrupts : contain the GPIO bank interrupt with flags for falling edge. | |
| 26 | +- gpio-ranges : defines the range of pins managed by the GPIO bank controller. | |
| 27 | + | |
| 28 | +For example, GPIO bank subnodes like the following: | |
| 29 | + gpio0: gpio@f0010000 { | |
| 30 | + gpio-controller; | |
| 31 | + #gpio-cells = <2>; | |
| 32 | + reg = <0x0 0x80>; | |
| 33 | + interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>; | |
| 34 | + gpio-ranges = <&pinctrl 0 0 32>; | |
| 35 | + }; | |
| 36 | + | |
| 37 | +=== Pin Mux Subnode === | |
| 38 | + | |
| 39 | +- pin: A string containing the name of the pin | |
| 40 | + An array of strings, each string containing the name of a pin. | |
| 41 | + These pin are used for selecting pin configuration. | |
| 42 | + | |
| 43 | +The following are the list of pins available: | |
| 44 | + "GPIO0/IOX1DI", "GPIO1/IOX1LD", "GPIO2/IOX1CK", "GPIO3/IOX1D0", | |
| 45 | + "GPIO4/IOX2DI/SMB1DSDA", "GPIO5/IOX2LD/SMB1DSCL", "GPIO6/IOX2CK/SMB2DSDA", | |
| 46 | + "GPIO7/IOX2D0/SMB2DSCL", "GPIO8/LKGPO1", "GPIO9/LKGPO2", "GPIO10/IOXHLD", | |
| 47 | + "GPIO11/IOXHCK", "GPIO12/GSPICK/SMB5BSCL", "GPIO13/GSPIDO/SMB5BSDA", | |
| 48 | + "GPIO14/GSPIDI/SMB5CSCL", "GPIO15/GSPICS/SMB5CSDA", "GPIO16/LKGPO0", | |
| 49 | + "GPIO17/PSPI2DI/SMB4DEN","GPIO18/PSPI2D0/SMB4BSDA", "GPIO19/PSPI2CK/SMB4BSCL", | |
| 50 | + "GPIO20/SMB4CSDA/SMB15SDA", "GPIO21/SMB4CSCL/SMB15SCL", "GPIO22/SMB4DSDA/SMB14SDA", | |
| 51 | + "GPIO23/SMB4DSCL/SMB14SCL", "GPIO24/IOXHDO", "GPIO25/IOXHDI", "GPIO26/SMB5SDA", | |
| 52 | + "GPIO27/SMB5SCL", "GPIO28/SMB4SDA", "GPIO29/SMB4SCL", "GPIO30/SMB3SDA", | |
| 53 | + "GPIO31/SMB3SCL", "GPIO32/nSPI0CS1","SPI0D2", "SPI0D3", "GPIO37/SMB3CSDA", | |
| 54 | + "GPIO38/SMB3CSCL", "GPIO39/SMB3BSDA", "GPIO40/SMB3BSCL", "GPIO41/BSPRXD", | |
| 55 | + "GPO42/BSPTXD/STRAP11", "GPIO43/RXD1/JTMS2/BU1RXD", "GPIO44/nCTS1/JTDI2/BU1CTS", | |
| 56 | + "GPIO45/nDCD1/JTDO2", "GPIO46/nDSR1/JTCK2", "GPIO47/nRI1/JCP_RDY2", | |
| 57 | + "GPIO48/TXD2/BSPTXD", "GPIO49/RXD2/BSPRXD", "GPIO50/nCTS2", "GPO51/nRTS2/STRAP2", | |
| 58 | + "GPIO52/nDCD2", "GPO53/nDTR2_BOUT2/STRAP1", "GPIO54/nDSR2", "GPIO55/nRI2", | |
| 59 | + "GPIO56/R1RXERR", "GPIO57/R1MDC", "GPIO58/R1MDIO", "GPIO59/SMB3DSDA", | |
| 60 | + "GPIO60/SMB3DSCL", "GPO61/nDTR1_BOUT1/STRAP6", "GPO62/nRTST1/STRAP5", | |
| 61 | + "GPO63/TXD1/STRAP4", "GPIO64/FANIN0", "GPIO65/FANIN1", "GPIO66/FANIN2", | |
| 62 | + "GPIO67/FANIN3", "GPIO68/FANIN4", "GPIO69/FANIN5", "GPIO70/FANIN6", "GPIO71/FANIN7", | |
| 63 | + "GPIO72/FANIN8", "GPIO73/FANIN9", "GPIO74/FANIN10", "GPIO75/FANIN11", | |
| 64 | + "GPIO76/FANIN12", "GPIO77/FANIN13","GPIO78/FANIN14", "GPIO79/FANIN15", | |
| 65 | + "GPIO80/PWM0", "GPIO81/PWM1", "GPIO82/PWM2", "GPIO83/PWM3", "GPIO84/R2TXD0", | |
| 66 | + "GPIO85/R2TXD1", "GPIO86/R2TXEN", "GPIO87/R2RXD0", "GPIO88/R2RXD1", "GPIO89/R2CRSDV", | |
| 67 | + "GPIO90/R2RXERR", "GPIO91/R2MDC", "GPIO92/R2MDIO", "GPIO93/GA20/SMB5DSCL", | |
| 68 | + "GPIO94/nKBRST/SMB5DSDA", "GPIO95/nLRESET/nESPIRST", "GPIO96/RG1TXD0", | |
| 69 | + "GPIO97/RG1TXD1", "GPIO98/RG1TXD2", "GPIO99/RG1TXD3","GPIO100/RG1TXC", | |
| 70 | + "GPIO101/RG1TXCTL", "GPIO102/RG1RXD0", "GPIO103/RG1RXD1", "GPIO104/RG1RXD2", | |
| 71 | + "GPIO105/RG1RXD3", "GPIO106/RG1RXC", "GPIO107/RG1RXCTL", "GPIO108/RG1MDC", | |
| 72 | + "GPIO109/RG1MDIO", "GPIO110/RG2TXD0/DDRV0", "GPIO111/RG2TXD1/DDRV1", | |
| 73 | + "GPIO112/RG2TXD2/DDRV2", "GPIO113/RG2TXD3/DDRV3", "GPIO114/SMB0SCL", | |
| 74 | + "GPIO115/SMB0SDA", "GPIO116/SMB1SCL", "GPIO117/SMB1SDA", "GPIO118/SMB2SCL", | |
| 75 | + "GPIO119/SMB2SDA", "GPIO120/SMB2CSDA", "GPIO121/SMB2CSCL", "GPIO122/SMB2BSDA", | |
| 76 | + "GPIO123/SMB2BSCL", "GPIO124/SMB1CSDA", "GPIO125/SMB1CSCL","GPIO126/SMB1BSDA", | |
| 77 | + "GPIO127/SMB1BSCL", "GPIO128/SMB8SCL", "GPIO129/SMB8SDA", "GPIO130/SMB9SCL", | |
| 78 | + "GPIO131/SMB9SDA", "GPIO132/SMB10SCL", "GPIO133/SMB10SDA","GPIO134/SMB11SCL", | |
| 79 | + "GPIO135/SMB11SDA", "GPIO136/SD1DT0", "GPIO137/SD1DT1", "GPIO138/SD1DT2", | |
| 80 | + "GPIO139/SD1DT3", "GPIO140/SD1CLK", "GPIO141/SD1WP", "GPIO142/SD1CMD", | |
| 81 | + "GPIO143/SD1CD/SD1PWR", "GPIO144/PWM4", "GPIO145/PWM5", "GPIO146/PWM6", | |
| 82 | + "GPIO147/PWM7", "GPIO148/MMCDT4", "GPIO149/MMCDT5", "GPIO150/MMCDT6", | |
| 83 | + "GPIO151/MMCDT7", "GPIO152/MMCCLK", "GPIO153/MMCWP", "GPIO154/MMCCMD", | |
| 84 | + "GPIO155/nMMCCD/nMMCRST", "GPIO156/MMCDT0", "GPIO157/MMCDT1", "GPIO158/MMCDT2", | |
| 85 | + "GPIO159/MMCDT3", "GPIO160/CLKOUT/RNGOSCOUT", "GPIO161/nLFRAME/nESPICS", | |
| 86 | + "GPIO162/SERIRQ", "GPIO163/LCLK/ESPICLK", "GPIO164/LAD0/ESPI_IO0", | |
| 87 | + "GPIO165/LAD1/ESPI_IO1", "GPIO166/LAD2/ESPI_IO2", "GPIO167/LAD3/ESPI_IO3", | |
| 88 | + "GPIO168/nCLKRUN/nESPIALERT", "GPIO169/nSCIPME", "GPIO170/nSMI", "GPIO171/SMB6SCL", | |
| 89 | + "GPIO172/SMB6SDA", "GPIO173/SMB7SCL", "GPIO174/SMB7SDA", "GPIO175/PSPI1CK/FANIN19", | |
| 90 | + "GPIO176/PSPI1DO/FANIN18", "GPIO177/PSPI1DI/FANIN17", "GPIO178/R1TXD0", | |
| 91 | + "GPIO179/R1TXD1", "GPIO180/R1TXEN", "GPIO181/R1RXD0", "GPIO182/R1RXD1", | |
| 92 | + "GPIO183/SPI3CK", "GPO184/SPI3D0/STRAP9", "GPO185/SPI3D1/STRAP10", | |
| 93 | + "GPIO186/nSPI3CS0", "GPIO187/nSPI3CS1", "GPIO188/SPI3D2/nSPI3CS2", | |
| 94 | + "GPIO189/SPI3D3/nSPI3CS3", "GPIO190/nPRD_SMI", "GPIO191", "GPIO192", "GPIO193/R1CRSDV", | |
| 95 | + "GPIO194/SMB0BSCL", "GPIO195/SMB0BSDA", "GPIO196/SMB0CSCL", "GPIO197/SMB0DEN", | |
| 96 | + "GPIO198/SMB0DSDA", "GPIO199/SMB0DSCL", "GPIO200/R2CK", "GPIO201/R1CK", | |
| 97 | + "GPIO202/SMB0CSDA", "GPIO203/FANIN16", "GPIO204/DDC2SCL", "GPIO205/DDC2SDA", | |
| 98 | + "GPIO206/HSYNC2", "GPIO207/VSYNC2", "GPIO208/RG2TXC/DVCK", "GPIO209/RG2TXCTL/DDRV4", | |
| 99 | + "GPIO210/RG2RXD0/DDRV5", "GPIO211/RG2RXD1/DDRV6", "GPIO212/RG2RXD2/DDRV7", | |
| 100 | + "GPIO213/RG2RXD3/DDRV8", "GPIO214/RG2RXC/DDRV9", "GPIO215/RG2RXCTL/DDRV10", | |
| 101 | + "GPIO216/RG2MDC/DDRV11", "GPIO217/RG2MDIO/DVHSYNC", "GPIO218/nWDO1", | |
| 102 | + "GPIO219/nWDO2", "GPIO220/SMB12SCL", "GPIO221/SMB12SDA", "GPIO222/SMB13SCL", | |
| 103 | + "GPIO223/SMB13SDA", "GPIO224/SPIXCK", "GPO225/SPIXD0/STRAP12", "GPO226/SPIXD1/STRAP13", | |
| 104 | + "GPIO227/nSPIXCS0", "GPIO228/nSPIXCS1", "GPO229/SPIXD2/STRAP3", "GPIO230/SPIXD3", | |
| 105 | + "GPIO231/nCLKREQ", "GPI255/DACOSEL" | |
| 106 | + | |
| 107 | +Optional Properties: | |
| 108 | + bias-disable, bias-pull-down, bias-pull-up, input-enable, | |
| 109 | + input-disable, output-high, output-low, drive-push-pull, | |
| 110 | + drive-open-drain, input-debounce, slew-rate, drive-strength | |
| 111 | + | |
| 112 | + slew-rate valid arguments are: | |
| 113 | + <0> - slow | |
| 114 | + <1> - fast | |
| 115 | + drive-strength valid arguments are: | |
| 116 | + <2> - 2mA | |
| 117 | + <4> - 4mA | |
| 118 | + <8> - 8mA | |
| 119 | + <12> - 12mA | |
| 120 | + <16> - 16mA | |
| 121 | + <24> - 24mA | |
| 122 | + | |
| 123 | +For example, pinctrl might have pinmux subnodes like the following: | |
| 124 | + | |
| 125 | + gpio0_iox1d1_pin: gpio0-iox1d1-pin { | |
| 126 | + pins = "GPIO0/IOX1DI"; | |
| 127 | + output-high; | |
| 128 | + }; | |
| 129 | + gpio0_iox1ck_pin: gpio0-iox1ck-pin { | |
| 130 | + pins = "GPIO2/IOX1CK"; | |
| 131 | + output_high; | |
| 132 | + }; | |
| 133 | + | |
| 134 | +=== Pin Group Subnode === | |
| 135 | + | |
| 136 | +Required pin group subnode-properties: | |
| 137 | +- groups : A string containing the name of the group to mux. | |
| 138 | +- function: A string containing the name of the function to mux to the | |
| 139 | + group. | |
| 140 | + | |
| 141 | +The following are the list of the available groups and functions : | |
| 142 | + smb0, smb0b, smb0c, smb0d, smb0den, smb1, smb1b, smb1c, smb1d, | |
| 143 | + smb2, smb2b, smb2c, smb2d, smb3, smb3b, smb3c, smb3d, smb4, smb4b, | |
| 144 | + smb4c, smb4d, smb4den, smb5, smb5b, smb5c, smb5d, ga20kbc, smb6, | |
| 145 | + smb7, smb8, smb9, smb10, smb11, smb12, smb13, smb14, smb15, fanin0, | |
| 146 | + fanin1, fanin2, fanin3, fanin4, fanin5, fanin6, fanin7, fanin8, | |
| 147 | + fanin9, fanin10, fanin11 fanin12 fanin13, fanin14, fanin15, faninx, | |
| 148 | + pwm0, pwm1, pwm2, pwm3, pwm4, pwm5, pwm6, pwm7, rg1, rg1mdio, rg2, | |
| 149 | + rg2mdio, ddr, uart1, uart2, bmcuart0a, bmcuart0b, bmcuart1, iox1, | |
| 150 | + iox2, ioxh, gspi, mmc, mmcwp, mmccd, mmcrst, mmc8, r1, r1err, r1md, | |
| 151 | + r2, r2err, r2md, sd1, sd1pwr, wdog1, wdog2, scipme, sci, serirq, | |
| 152 | + jtag2, spix, spixcs1, pspi1, pspi2, ddc, clkreq, clkout, spi3, spi3cs1, | |
| 153 | + spi3quad, spi3cs2, spi3cs3, spi0cs1, lpc, lpcclk, espi, lkgpo0, lkgpo1, | |
| 154 | + lkgpo2, nprd_smi | |
| 155 | + | |
| 156 | +For example, pinctrl might have group subnodes like the following: | |
| 157 | + r1err_pins: r1err-pins { | |
| 158 | + groups = "r1err"; | |
| 159 | + function = "r1err"; | |
| 160 | + }; | |
| 161 | + r1md_pins: r1md-pins { | |
| 162 | + groups = "r1md"; | |
| 163 | + function = "r1md"; | |
| 164 | + }; | |
| 165 | + r1_pins: r1-pins { | |
| 166 | + groups = "r1"; | |
| 167 | + function = "r1"; | |
| 168 | + }; | |
| 169 | + | |
| 170 | +Examples | |
| 171 | +======== | |
| 172 | +pinctrl: pinctrl@f0800000 { | |
| 173 | + #address-cells = <1>; | |
| 174 | + #size-cells = <1>; | |
| 175 | + compatible = "nuvoton,npcm750-pinctrl"; | |
| 176 | + ranges = <0 0xf0010000 0x8000>; | |
| 177 | + | |
| 178 | + gpio0: gpio@f0010000 { | |
| 179 | + gpio-controller; | |
| 180 | + #gpio-cells = <2>; | |
| 181 | + reg = <0x0 0x80>; | |
| 182 | + interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>; | |
| 183 | + gpio-ranges = <&pinctrl 0 0 32>; | |
| 184 | + }; | |
| 185 | + | |
| 186 | + .... | |
| 187 | + | |
| 188 | + gpio7: gpio@f0017000 { | |
| 189 | + gpio-controller; | |
| 190 | + #gpio-cells = <2>; | |
| 191 | + reg = <0x7000 0x80>; | |
| 192 | + interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>; | |
| 193 | + gpio-ranges = <&pinctrl 0 224 32>; | |
| 194 | + }; | |
| 195 | + | |
| 196 | + gpio0_iox1d1_pin: gpio0-iox1d1-pin { | |
| 197 | + pins = "GPIO0/IOX1DI"; | |
| 198 | + output-high; | |
| 199 | + }; | |
| 200 | + | |
| 201 | + iox1_pins: iox1-pins { | |
| 202 | + groups = "iox1"; | |
| 203 | + function = "iox1"; | |
| 204 | + }; | |
| 205 | + iox2_pins: iox2-pins { | |
| 206 | + groups = "iox2"; | |
| 207 | + function = "iox2"; | |
| 208 | + }; | |
| 209 | + | |
| 210 | + .... | |
| 211 | + | |
| 212 | + clkreq_pins: clkreq-pins { | |
| 213 | + groups = "clkreq"; | |
| 214 | + function = "clkreq"; | |
| 215 | + }; | |
| 216 | +}; | |
| @@ -19,6 +19,7 @@ PMIC's from Qualcomm. · 18 unmodified lines | ||
| 19 | 19 | "qcom,pm8998-gpio" |
| 20 | 20 | "qcom,pma8084-gpio" |
| 21 | 21 | "qcom,pmi8994-gpio" |
| 22 | + "qcom,pms405-gpio" | |
| 22 | 23 | |
| 23 | 24 | And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio" |
| 24 | 25 | if the device is on an spmi bus or an ssbi bus respectively |
| @@ -91,6 +92,7 @@ to specify in a pin configuration subnode: · 66 unmodified lines | ||
| 91 | 92 | gpio1-gpio26 for pm8998 |
| 92 | 93 | gpio1-gpio22 for pma8084 |
| 93 | 94 | gpio1-gpio10 for pmi8994 |
| 95 | + gpio1-gpio11 for pms405 | |
| 94 | 96 | |
| 95 | 97 | - function: |
| 96 | 98 | Usage: required |
| @@ -0,0 +1,199 @@ | ||
| 1 | +Qualcomm QCS404 TLMM block | |
| 2 | + | |
| 3 | +This binding describes the Top Level Mode Multiplexer block found in the | |
| 4 | +QCS404 platform. | |
| 5 | + | |
| 6 | +- compatible: | |
| 7 | + Usage: required | |
| 8 | + Value type: <string> | |
| 9 | + Definition: must be "qcom,qcs404-pinctrl" | |
| 10 | + | |
| 11 | +- reg: | |
| 12 | + Usage: required | |
| 13 | + Value type: <prop-encoded-array> | |
| 14 | + Definition: the base address and size of the north, south and east TLMM | |
| 15 | + tiles. | |
| 16 | + | |
| 17 | +- reg-names: | |
| 18 | + Usage: required | |
| 19 | + Value type: <stringlist> | |
| 20 | + Defintiion: names for the cells of reg, must contain "north", "south" | |
| 21 | + and "east". | |
| 22 | + | |
| 23 | +- interrupts: | |
| 24 | + Usage: required | |
| 25 | + Value type: <prop-encoded-array> | |
| 26 | + Definition: should specify the TLMM summary IRQ. | |
| 27 | + | |
| 28 | +- interrupt-controller: | |
| 29 | + Usage: required | |
| 30 | + Value type: <none> | |
| 31 | + Definition: identifies this node as an interrupt controller | |
| 32 | + | |
| 33 | +- #interrupt-cells: | |
| 34 | + Usage: required | |
| 35 | + Value type: <u32> | |
| 36 | + Definition: must be 2. Specifying the pin number and flags, as defined | |
| 37 | + in <dt-bindings/interrupt-controller/irq.h> | |
| 38 | + | |
| 39 | +- gpio-controller: | |
| 40 | + Usage: required | |
| 41 | + Value type: <none> | |
| 42 | + Definition: identifies this node as a gpio controller | |
| 43 | + | |
| 44 | +- #gpio-cells: | |
| 45 | + Usage: required | |
| 46 | + Value type: <u32> | |
| 47 | + Definition: must be 2. Specifying the pin number and flags, as defined | |
| 48 | + in <dt-bindings/gpio/gpio.h> | |
| 49 | + | |
| 50 | +- gpio-ranges: | |
| 51 | + Usage: required | |
| 52 | + Definition: see ../gpio/gpio.txt | |
| 53 | + | |
| 54 | +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for | |
| 55 | +a general description of GPIO and interrupt bindings. | |
| 56 | + | |
| 57 | +Please refer to pinctrl-bindings.txt in this directory for details of the | |
| 58 | +common pinctrl bindings used by client devices, including the meaning of the | |
| 59 | +phrase "pin configuration node". | |
| 60 | + | |
| 61 | +The pin configuration nodes act as a container for an arbitrary number of | |
| 62 | +subnodes. Each of these subnodes represents some desired configuration for a | |
| 63 | +pin, a group, or a list of pins or groups. This configuration can include the | |
| 64 | +mux function to select on those pin(s)/group(s), and various pin configuration | |
| 65 | +parameters, such as pull-up, drive strength, etc. | |
| 66 | + | |
| 67 | + | |
| 68 | +PIN CONFIGURATION NODES: | |
| 69 | + | |
| 70 | +The name of each subnode is not important; all subnodes should be enumerated | |
| 71 | +and processed purely based on their content. | |
| 72 | + | |
| 73 | +Each subnode only affects those parameters that are explicitly listed. In | |
| 74 | +other words, a subnode that lists a mux function but no pin configuration | |
| 75 | +parameters implies no information about any pin configuration parameters. | |
| 76 | +Similarly, a pin subnode that describes a pullup parameter implies no | |
| 77 | +information about e.g. the mux function. | |
| 78 | + | |
| 79 | + | |
| 80 | +The following generic properties as defined in pinctrl-bindings.txt are valid | |
| 81 | +to specify in a pin configuration subnode: | |
| 82 | + | |
| 83 | +- pins: | |
| 84 | + Usage: required | |
| 85 | + Value type: <string-array> | |
| 86 | + Definition: List of gpio pins affected by the properties specified in | |
| 87 | + this subnode. | |
| 88 | + | |
| 89 | + Valid pins are: | |
| 90 | + gpio0-gpio119 | |
| 91 | + Supports mux, bias and drive-strength | |
| 92 | + | |
| 93 | + sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, | |
| 94 | + sdc2_data | |
| 95 | + Supports bias and drive-strength | |
| 96 | + | |
| 97 | + ufs_reset | |
| 98 | + Supports bias and drive-strength | |
| 99 | + | |
| 100 | +- function: | |
| 101 | + Usage: required | |
| 102 | + Value type: <string> | |
| 103 | + Definition: Specify the alternative function to be configured for the | |
| 104 | + specified pins. Functions are only valid for gpio pins. | |
| 105 | + Valid values are: | |
| 106 | + | |
| 107 | + gpio, hdmi_tx, hdmi_ddc, blsp_uart_tx_a2, blsp_spi2, m_voc, | |
| 108 | + qdss_cti_trig_in_a0, blsp_uart_rx_a2, qdss_tracectl_a, | |
| 109 | + blsp_uart2, aud_cdc, blsp_i2c_sda_a2, qdss_tracedata_a, | |
| 110 | + blsp_i2c_scl_a2, qdss_tracectl_b, qdss_cti_trig_in_b0, | |
| 111 | + blsp_uart1, blsp_spi_mosi_a1, blsp_spi_miso_a1, | |
| 112 | + qdss_tracedata_b, blsp_i2c1, blsp_spi_cs_n_a1, gcc_plltest, | |
| 113 | + blsp_spi_clk_a1, rgb_data0, blsp_uart5, blsp_spi5, | |
| 114 | + adsp_ext, rgb_data1, prng_rosc, rgb_data2, blsp_i2c5, | |
| 115 | + gcc_gp1_clk_b, rgb_data3, gcc_gp2_clk_b, blsp_spi0, | |
| 116 | + blsp_uart0, gcc_gp3_clk_b, blsp_i2c0, qdss_traceclk_b, | |
| 117 | + pcie_clk, nfc_irq, blsp_spi4, nfc_dwl, audio_ts, rgb_data4, | |
| 118 | + spi_lcd, blsp_uart_tx_b2, gcc_gp3_clk_a, rgb_data5, | |
| 119 | + blsp_uart_rx_b2, blsp_i2c_sda_b2, blsp_i2c_scl_b2, | |
| 120 | + pwm_led11, i2s_3_data0_a, ebi2_lcd, i2s_3_data1_a, | |
| 121 | + i2s_3_data2_a, atest_char, pwm_led3, i2s_3_data3_a, | |
| 122 | + pwm_led4, i2s_4, ebi2_a, dsd_clk_b, pwm_led5, pwm_led6, | |
| 123 | + pwm_led7, pwm_led8, pwm_led24, spkr_dac0, blsp_i2c4, | |
| 124 | + pwm_led9, pwm_led10, spdifrx_opt, pwm_led12, pwm_led13, | |
| 125 | + pwm_led14, wlan1_adc1, rgb_data_b0, pwm_led15, | |
| 126 | + blsp_spi_mosi_b1, wlan1_adc0, rgb_data_b1, pwm_led16, | |
| 127 | + blsp_spi_miso_b1, qdss_cti_trig_out_b0, wlan2_adc1, | |
| 128 | + rgb_data_b2, pwm_led17, blsp_spi_cs_n_b1, wlan2_adc0, | |
| 129 | + rgb_data_b3, pwm_led18, blsp_spi_clk_b1, rgb_data_b4, | |
| 130 | + pwm_led19, ext_mclk1_b, qdss_traceclk_a, rgb_data_b5, | |
| 131 | + pwm_led20, atest_char3, i2s_3_sck_b, ldo_update, bimc_dte0, | |
| 132 | + rgb_hsync, pwm_led21, i2s_3_ws_b, dbg_out, rgb_vsync, | |
| 133 | + i2s_3_data0_b, ldo_en, hdmi_dtest, rgb_de, i2s_3_data1_b, | |
| 134 | + hdmi_lbk9, rgb_clk, atest_char1, i2s_3_data2_b, ebi_cdc, | |
| 135 | + hdmi_lbk8, rgb_mdp, atest_char0, i2s_3_data3_b, hdmi_lbk7, | |
| 136 | + rgb_data_b6, rgb_data_b7, hdmi_lbk6, rgmii_int, cri_trng1, | |
| 137 | + rgmii_wol, cri_trng0, gcc_tlmm, rgmii_ck, rgmii_tx, | |
| 138 | + hdmi_lbk5, hdmi_pixel, hdmi_rcv, hdmi_lbk4, rgmii_ctl, | |
| 139 | + ext_lpass, rgmii_rx, cri_trng, hdmi_lbk3, hdmi_lbk2, | |
| 140 | + qdss_cti_trig_out_b1, rgmii_mdio, hdmi_lbk1, rgmii_mdc, | |
| 141 | + hdmi_lbk0, ir_in, wsa_en, rgb_data6, rgb_data7, | |
| 142 | + atest_char2, ebi_ch0, blsp_uart3, blsp_spi3, sd_write, | |
| 143 | + blsp_i2c3, gcc_gp1_clk_a, qdss_cti_trig_in_b1, | |
| 144 | + gcc_gp2_clk_a, ext_mclk0, mclk_in1, i2s_1, dsd_clk_a, | |
| 145 | + qdss_cti_trig_in_a1, rgmi_dll1, pwm_led22, pwm_led23, | |
| 146 | + qdss_cti_trig_out_a0, rgmi_dll2, pwm_led1, | |
| 147 | + qdss_cti_trig_out_a1, pwm_led2, i2s_2, pll_bist, | |
| 148 | + ext_mclk1_a, mclk_in2, bimc_dte1, i2s_3_sck_a, i2s_3_ws_a | |
| 149 | + | |
| 150 | +- bias-disable: | |
| 151 | + Usage: optional | |
| 152 | + Value type: <none> | |
| 153 | + Definition: The specified pins should be configued as no pull. | |
| 154 | + | |
| 155 | +- bias-pull-down: | |
| 156 | + Usage: optional | |
| 157 | + Value type: <none> | |
| 158 | + Definition: The specified pins should be configued as pull down. | |
| 159 | + | |
| 160 | +- bias-pull-up: | |
| 161 | + Usage: optional | |
| 162 | + Value type: <none> | |
| 163 | + Definition: The specified pins should be configued as pull up. | |
| 164 | + | |
| 165 | +- output-high: | |
| 166 | + Usage: optional | |
| 167 | + Value type: <none> | |
| 168 | + Definition: The specified pins are configured in output mode, driven | |
| 169 | + high. | |
| 170 | + Not valid for sdc pins. | |
| 171 | + | |
| 172 | +- output-low: | |
| 173 | + Usage: optional | |
| 174 | + Value type: <none> | |
| 175 | + Definition: The specified pins are configured in output mode, driven | |
| 176 | + low. | |
| 177 | + Not valid for sdc pins. | |
| 178 | + | |
| 179 | +- drive-strength: | |
| 180 | + Usage: optional | |
| 181 | + Value type: <u32> | |
| 182 | + Definition: Selects the drive strength for the specified pins, in mA. | |
| 183 | + Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16 | |
| 184 | + | |
| 185 | +Example: | |
| 186 | + | |
| 187 | + tlmm: pinctrl@1000000 { | |
| 188 | + compatible = "qcom,qcs404-pinctrl"; | |
| 189 | + reg = <0x01000000 0x200000>, | |
| 190 | + <0x01300000 0x200000>, | |
| 191 | + <0x07b00000 0x200000>; | |
| 192 | + reg-names = "south", "north", "east"; | |
| 193 | + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>; | |
| 194 | + gpio-controller; | |
| 195 | + #gpio-cells = <2>; | |
| 196 | + gpio-ranges = <&tlmm 0 0 120>; | |
| 197 | + interrupt-controller; | |
| 198 | + #interrupt-cells = <2>; | |
| 199 | + }; | |
| @@ -0,0 +1,191 @@ | ||
| 1 | +Qualcomm Technologies, Inc. SDM660 TLMM block | |
| 2 | + | |
| 3 | +This binding describes the Top Level Mode Multiplexer block found in the | |
| 4 | +SDM660 platform. | |
| 5 | + | |
| 6 | +- compatible: | |
| 7 | + Usage: required | |
| 8 | + Value type: <string> | |
| 9 | + Definition: must be "qcom,sdm660-pinctrl" or | |
| 10 | + "qcom,sdm630-pinctrl". | |
| 11 | + | |
| 12 | +- reg: | |
| 13 | + Usage: required | |
| 14 | + Value type: <prop-encoded-array> | |
| 15 | + Definition: the base address and size of the north, center and south | |
| 16 | + TLMM tiles. | |
| 17 | + | |
| 18 | +- reg-names: | |
| 19 | + Usage: required | |
| 20 | + Value type: <stringlist> | |
| 21 | + Definition: names for the cells of reg, must contain "north", "center" | |
| 22 | + and "south". | |
| 23 | + | |
| 24 | +- interrupts: | |
| 25 | + Usage: required | |
| 26 | + Value type: <prop-encoded-array> | |
| 27 | + Definition: should specify the TLMM summary IRQ. | |
| 28 | + | |
| 29 | +- interrupt-controller: | |
| 30 | + Usage: required | |
| 31 | + Value type: <none> | |
| 32 | + Definition: identifies this node as an interrupt controller | |
| 33 | + | |
| 34 | +- #interrupt-cells: | |
| 35 | + Usage: required | |
| 36 | + Value type: <u32> | |
| 37 | + Definition: must be 2. Specifying the pin number and flags, as defined | |
| 38 | + in <dt-bindings/interrupt-controller/irq.h> | |
| 39 | + | |
| 40 | +- gpio-controller: | |
| 41 | + Usage: required | |
| 42 | + Value type: <none> | |
| 43 | + Definition: identifies this node as a gpio controller | |
| 44 | + | |
| 45 | +- gpio-ranges: | |
| 46 | + Usage: required | |
| 47 | + Value type: <prop-encoded-array> | |
| 48 | + Definition: Specifies the mapping between gpio controller and | |
| 49 | + pin-controller pins. | |
| 50 | + | |
| 51 | +- #gpio-cells: | |
| 52 | + Usage: required | |
| 53 | + Value type: <u32> | |
| 54 | + Definition: must be 2. Specifying the pin number and flags, as defined | |
| 55 | + in <dt-bindings/gpio/gpio.h> | |
| 56 | + | |
| 57 | +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for | |
| 58 | +a general description of GPIO and interrupt bindings. | |
| 59 | + | |
| 60 | +Please refer to pinctrl-bindings.txt in this directory for details of the | |
| 61 | +common pinctrl bindings used by client devices, including the meaning of the | |
| 62 | +phrase "pin configuration node". | |
| 63 | + | |
| 64 | +The pin configuration nodes act as a container for an arbitrary number of | |
| 65 | +subnodes. Each of these subnodes represents some desired configuration for a | |
| 66 | +pin, a group, or a list of pins or groups. This configuration can include the | |
| 67 | +mux function to select on those pin(s)/group(s), and various pin configuration | |
| 68 | +parameters, such as pull-up, drive strength, etc. | |
| 69 | + | |
| 70 | + | |
| 71 | +PIN CONFIGURATION NODES: | |
| 72 | + | |
| 73 | +The name of each subnode is not important; all subnodes should be enumerated | |
| 74 | +and processed purely based on their content. | |
| 75 | + | |
| 76 | +Each subnode only affects those parameters that are explicitly listed. In | |
| 77 | +other words, a subnode that lists a mux function but no pin configuration | |
| 78 | +parameters implies no information about any pin configuration parameters. | |
| 79 | +Similarly, a pin subnode that describes a pullup parameter implies no | |
| 80 | +information about e.g. the mux function. | |
| 81 | + | |
| 82 | + | |
| 83 | +The following generic properties as defined in pinctrl-bindings.txt are valid | |
| 84 | +to specify in a pin configuration subnode: | |
| 85 | + | |
| 86 | +- pins: | |
| 87 | + Usage: required | |
| 88 | + Value type: <string-array> | |
| 89 | + Definition: List of gpio pins affected by the properties specified in | |
| 90 | + this subnode. Valid pins are: | |
| 91 | + gpio0-gpio113, | |
| 92 | + Supports mux, bias and drive-strength | |
| 93 | + sdc1_clk, sdc1_cmd, sdc1_data sdc2_clk, sdc2_cmd, sdc2_data sdc1_rclk, | |
| 94 | + Supports bias and drive-strength | |
| 95 | + | |
| 96 | +- function: | |
| 97 | + Usage: required | |
| 98 | + Value type: <string> | |
| 99 | + Definition: Specify the alternative function to be configured for the | |
| 100 | + specified pins. Functions are only valid for gpio pins. | |
| 101 | + Valid values are: | |
| 102 | + adsp_ext, agera_pll, atest_char, atest_char0, atest_char1, | |
| 103 | + atest_char2, atest_char3, atest_gpsadc0, atest_gpsadc1, | |
| 104 | + atest_tsens, atest_tsens2, atest_usb1, atest_usb10, | |
| 105 | + atest_usb11, atest_usb12, atest_usb13, atest_usb2, | |
| 106 | + atest_usb20, atest_usb21, atest_usb22, atest_usb23, | |
| 107 | + audio_ref, bimc_dte0, bimc_dte1, blsp_i2c1, blsp_i2c2, | |
| 108 | + blsp_i2c3, blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_i2c7, | |
| 109 | + blsp_i2c8_a, blsp_i2c8_b, blsp_spi1, blsp_spi2, blsp_spi3, | |
| 110 | + blsp_spi3_cs1, blsp_spi3_cs2, blsp_spi4, blsp_spi5, | |
| 111 | + blsp_spi6, blsp_spi7, blsp_spi8_a, blsp_spi8_b, | |
| 112 | + blsp_spi8_cs1, blsp_spi8_cs2, blsp_uart1, blsp_uart2, | |
| 113 | + blsp_uart5, blsp_uart6_a, blsp_uart6_b, blsp_uim1, | |
| 114 | + blsp_uim2, blsp_uim5, blsp_uim6, cam_mclk, cci_async, | |
| 115 | + cci_i2c, cri_trng, cri_trng0, cri_trng1, dbg_out, ddr_bist, | |
| 116 | + gcc_gp1, gcc_gp2, gcc_gp3, gpio, gps_tx_a, gps_tx_b, gps_tx_c, | |
| 117 | + isense_dbg, jitter_bist, ldo_en, ldo_update, m_voc, mdp_vsync, | |
| 118 | + mdss_vsync0, mdss_vsync1, mdss_vsync2, mdss_vsync3, mss_lte, | |
| 119 | + nav_pps_a, nav_pps_b, nav_pps_c, pa_indicator, phase_flag0, | |
| 120 | + phase_flag1, phase_flag10, phase_flag11, phase_flag12, | |
| 121 | + phase_flag13, phase_flag14, phase_flag15, phase_flag16, | |
| 122 | + phase_flag17, phase_flag18, phase_flag19, phase_flag2, | |
| 123 | + phase_flag20, phase_flag21, phase_flag22, phase_flag23, | |
| 124 | + phase_flag24, phase_flag25, phase_flag26, phase_flag27, | |
| 125 | + phase_flag28, phase_flag29, phase_flag3, phase_flag30, | |
| 126 | + phase_flag31, phase_flag4, phase_flag5, phase_flag6, | |
| 127 | + phase_flag7, phase_flag8, phase_flag9, pll_bypassnl, | |
| 128 | + pll_reset, pri_mi2s, pri_mi2s_ws, prng_rosc, pwr_crypto, | |
| 129 | + pwr_modem, pwr_nav, qdss_cti0_a, qdss_cti0_b, qdss_cti1_a, | |
| 130 | + qdss_cti1_b, qdss_gpio, qdss_gpio0, qdss_gpio1, qdss_gpio10, | |
| 131 | + qdss_gpio11, qdss_gpio12, qdss_gpio13, qdss_gpio14, qdss_gpio15, | |
| 132 | + qdss_gpio2, qdss_gpio3, qdss_gpio4, qdss_gpio5, qdss_gpio6, | |
| 133 | + qdss_gpio7, qdss_gpio8, qdss_gpio9, qlink_enable, qlink_request, | |
| 134 | + qspi_clk, qspi_cs, qspi_data0, qspi_data1, qspi_data2, | |
| 135 | + qspi_data3, qspi_resetn, sec_mi2s, sndwire_clk, sndwire_data, | |
| 136 | + sp_cmu, ssc_irq, tgu_ch0, tgu_ch1, tsense_pwm1, tsense_pwm2, | |
| 137 | + uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk, | |
| 138 | + uim2_data, uim2_present, uim2_reset, uim_batt, vfr_1, | |
| 139 | + vsense_clkout, vsense_data0, vsense_data1, vsense_mode, | |
| 140 | + wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1 | |
| 141 | + | |
| 142 | +- bias-disable: | |
| 143 | + Usage: optional | |
| 144 | + Value type: <none> | |
| 145 | + Definition: The specified pins should be configued as no pull. | |
| 146 | + | |
| 147 | +- bias-pull-down: | |
| 148 | + Usage: optional | |
| 149 | + Value type: <none> | |
| 150 | + Definition: The specified pins should be configued as pull down. | |
| 151 | + | |
| 152 | +- bias-pull-up: | |
| 153 | + Usage: optional | |
| 154 | + Value type: <none> | |
| 155 | + Definition: The specified pins should be configued as pull up. | |
| 156 | + | |
| 157 | +- output-high: | |
| 158 | + Usage: optional | |
| 159 | + Value type: <none> | |
| 160 | + Definition: The specified pins are configured in output mode, driven | |
| 161 | + high. | |
| 162 | + Not valid for sdc pins. | |
| 163 | + | |
| 164 | +- output-low: | |
| 165 | + Usage: optional | |
| 166 | + Value type: <none> | |
| 167 | + Definition: The specified pins are configured in output mode, driven | |
| 168 | + low. | |
| 169 | + Not valid for sdc pins. | |
| 170 | + | |
| 171 | +- drive-strength: | |
| 172 | + Usage: optional | |
| 173 | + Value type: <u32> | |
| 174 | + Definition: Selects the drive strength for the specified pins, in mA. | |
| 175 | + Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16 | |
| 176 | + | |
| 177 | +Example: | |
| 178 | + | |
| 179 | + tlmm: pinctrl@3100000 { | |
| 180 | + compatible = "qcom,sdm660-pinctrl"; | |
| 181 | + reg = <0x3100000 0x200000>, | |
| 182 | + <0x3500000 0x200000>, | |
| 183 | + <0x3900000 0x200000>; | |
| 184 | + reg-names = "south", "center", "north"; | |
| 185 | + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>; | |
| 186 | + gpio-controller; | |
| 187 | + gpio-ranges = <&tlmm 0 0 114>; | |
| 188 | + #gpio-cells = <2>; | |
| 189 | + interrupt-controller; | |
| 190 | + #interrupt-cells = <2>; | |
| 191 | + }; | |
| @@ -14,8 +14,11 @@ Required Properties: · 13 unmodified lines | ||
| 14 | 14 | - "renesas,pfc-r8a73a4": for R8A73A4 (R-Mobile APE6) compatible pin-controller. |
| 15 | 15 | - "renesas,pfc-r8a7740": for R8A7740 (R-Mobile A1) compatible pin-controller. |
| 16 | 16 | - "renesas,pfc-r8a7743": for R8A7743 (RZ/G1M) compatible pin-controller. |
| 17 | + - "renesas,pfc-r8a7744": for R8A7744 (RZ/G1N) compatible pin-controller. | |
| 17 | 18 | - "renesas,pfc-r8a7745": for R8A7745 (RZ/G1E) compatible pin-controller. |
| 18 | 19 | - "renesas,pfc-r8a77470": for R8A77470 (RZ/G1C) compatible pin-controller. |
| 20 | + - "renesas,pfc-r8a774a1": for R8A774A1 (RZ/G2M) compatible pin-controller. | |
| 21 | + - "renesas,pfc-r8a774c0": for R8A774C0 (RZ/G2E) compatible pin-controller. | |
| 19 | 22 | - "renesas,pfc-r8a7778": for R8A7778 (R-Car M1) compatible pin-controller. |
| 20 | 23 | - "renesas,pfc-r8a7779": for R8A7779 (R-Car H1) compatible pin-controller. |
| 21 | 24 | - "renesas,pfc-r8a7790": for R8A7790 (R-Car H2) compatible pin-controller. |
| @@ -0,0 +1,153 @@ | ||
| 1 | +Renesas RZ/N1 SoC Pinctrl node description. | |
| 2 | + | |
| 3 | +Pin controller node | |
| 4 | +------------------- | |
| 5 | +Required properties: | |
| 6 | +- compatible: SoC-specific compatible string "renesas,<soc-specific>-pinctrl" | |
| 7 | + followed by "renesas,rzn1-pinctrl" as fallback. The SoC-specific compatible | |
| 8 | + strings must be one of: | |
| 9 | + "renesas,r9a06g032-pinctrl" for RZ/N1D | |
| 10 | + "renesas,r9a06g033-pinctrl" for RZ/N1S | |
| 11 | +- reg: Address base and length of the memory area where the pin controller | |
| 12 | + hardware is mapped to. | |
| 13 | +- clocks: phandle for the clock, see the description of clock-names below. | |
| 14 | +- clock-names: Contains the name of the clock: | |
| 15 | + "bus", the bus clock, sometimes described as pclk, for register accesses. | |
| 16 | + | |
| 17 | +Example: | |
| 18 | + pinctrl: pin-controller@40067000 { | |
| 19 | + compatible = "renesas,r9a06g032-pinctrl", "renesas,rzn1-pinctrl"; | |
| 20 | + reg = <0x40067000 0x1000>, <0x51000000 0x480>; | |
| 21 | + clocks = <&sysctrl R9A06G032_HCLK_PINCONFIG>; | |
| 22 | + clock-names = "bus"; | |
| 23 | + }; | |
| 24 | + | |
| 25 | +Sub-nodes | |
| 26 | +--------- | |
| 27 | + | |
| 28 | +The child nodes of the pin controller node describe a pin multiplexing | |
| 29 | +function. | |
| 30 | + | |
| 31 | +- Pin multiplexing sub-nodes: | |
| 32 | + A pin multiplexing sub-node describes how to configure a set of | |
| 33 | + (or a single) pin in some desired alternate function mode. | |
| 34 | + A single sub-node may define several pin configurations. | |
| 35 | + Please refer to pinctrl-bindings.txt to get to know more on generic | |
| 36 | + pin properties usage. | |
| 37 | + | |
| 38 | + The allowed generic formats for a pin multiplexing sub-node are the | |
| 39 | + following ones: | |
| 40 | + | |
| 41 | + node-1 { | |
| 42 | + pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ... ; | |
| 43 | + GENERIC_PINCONFIG; | |
| 44 | + }; | |
| 45 | + | |
| 46 | + node-2 { | |
| 47 | + sub-node-1 { | |
| 48 | + pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ... ; | |
| 49 | + GENERIC_PINCONFIG; | |
| 50 | + }; | |
| 51 | + | |
| 52 | + sub-node-2 { | |
| 53 | + pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ... ; | |
| 54 | + GENERIC_PINCONFIG; | |
| 55 | + }; | |
| 56 | + | |
| 57 | + ... | |
| 58 | + | |
| 59 | + sub-node-n { | |
| 60 | + pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ... ; | |
| 61 | + GENERIC_PINCONFIG; | |
| 62 | + }; | |
| 63 | + }; | |
| 64 | + | |
| 65 | + node-3 { | |
| 66 | + pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ... ; | |
| 67 | + GENERIC_PINCONFIG; | |
| 68 | + | |
| 69 | + sub-node-1 { | |
| 70 | + pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ... ; | |
| 71 | + GENERIC_PINCONFIG; | |
| 72 | + }; | |
| 73 | + | |
| 74 | + ... | |
| 75 | + | |
| 76 | + sub-node-n { | |
| 77 | + pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ... ; | |
| 78 | + GENERIC_PINCONFIG; | |
| 79 | + }; | |
| 80 | + }; | |
| 81 | + | |
| 82 | + Use the latter two formats when pins part of the same logical group need to | |
| 83 | + have different generic pin configuration flags applied. Note that the generic | |
| 84 | + pinconfig in node-3 does not apply to the sub-nodes. | |
| 85 | + | |
| 86 | + Client sub-nodes shall refer to pin multiplexing sub-nodes using the phandle | |
| 87 | + of the most external one. | |
| 88 | + | |
| 89 | + Eg. | |
| 90 | + | |
| 91 | + client-1 { | |
| 92 | + ... | |
| 93 | + pinctrl-0 = <&node-1>; | |
| 94 | + ... | |
| 95 | + }; | |
| 96 | + | |
| 97 | + client-2 { | |
| 98 | + ... | |
| 99 | + pinctrl-0 = <&node-2>; | |
| 100 | + ... | |
| 101 | + }; | |
| 102 | + | |
| 103 | + Required properties: | |
| 104 | + - pinmux: | |
| 105 | + integer array representing pin number and pin multiplexing configuration. | |
| 106 | + When a pin has to be configured in alternate function mode, use this | |
| 107 | + property to identify the pin by its global index, and provide its | |
| 108 | + alternate function configuration number along with it. | |
| 109 | + When multiple pins are required to be configured as part of the same | |
| 110 | + alternate function they shall be specified as members of the same | |
| 111 | + argument list of a single "pinmux" property. | |
| 112 | + Integers values in the "pinmux" argument list are assembled as: | |
| 113 | + (PIN | MUX_FUNC << 8) | |
| 114 | + where PIN directly corresponds to the pl_gpio pin number and MUX_FUNC is | |
| 115 | + one of the alternate function identifiers defined in: | |
| 116 | + <include/dt-bindings/pinctrl/rzn1-pinctrl.h> | |
| 117 | + These identifiers collapse the IO Multiplex Configuration Level 1 and | |
| 118 | + Level 2 numbers that are detailed in the hardware reference manual into a | |
| 119 | + single number. The identifiers for Level 2 are simply offset by 10. | |
| 120 | + Additional identifiers are provided to specify the MDIO source peripheral. | |
| 121 | + | |
| 122 | + Optional generic pinconf properties: | |
| 123 | + - bias-disable - disable any pin bias | |
| 124 | + - bias-pull-up - pull up the pin with 50 KOhm | |
| 125 | + - bias-pull-down - pull down the pin with 50 KOhm | |
| 126 | + - bias-high-impedance - high impedance mode | |
| 127 | + - drive-strength - sink or source at most 4, 6, 8 or 12 mA | |
| 128 | + | |
| 129 | + Example: | |
| 130 | + A serial communication interface with a TX output pin and an RX input pin. | |
| 131 | + | |
| 132 | + &pinctrl { | |
| 133 | + pins_uart0: pins_uart0 { | |
| 134 | + pinmux = < | |
| 135 | + RZN1_PINMUX(103, RZN1_FUNC_UART0_I) /* UART0_TXD */ | |
| 136 | + RZN1_PINMUX(104, RZN1_FUNC_UART0_I) /* UART0_RXD */ | |
| 137 | + >; | |
| 138 | + }; | |
| 139 | + }; | |
| 140 | + | |
| 141 | + Example 2: | |
| 142 | + Here we set the pull up on the RXD pin of the UART. | |
| 143 | + | |
| 144 | + &pinctrl { | |
| 145 | + pins_uart0: pins_uart0 { | |
| 146 | + pinmux = <RZN1_PINMUX(103, RZN1_FUNC_UART0_I)>; /* TXD */ | |
| 147 | + | |
| 148 | + pins_uart6_rx { | |
| 149 | + pinmux = <RZN1_PINMUX(104, RZN1_FUNC_UART0_I)>; /* RXD */ | |
| 150 | + bias-pull-up; | |
| 151 | + }; | |
| 152 | + }; | |
| 153 | + }; | |
| @@ -3,11 +3,13 @@ Actions Semi Owl Smart Power System (SPS) · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible : "actions,s500-sps" for S500 |
| 5 | 5 | "actions,s700-sps" for S700 |
| 6 | + "actions,s900-sps" for S900 | |
| 6 | 7 | - reg : Offset and length of the register set for the device. |
| 7 | 8 | - #power-domain-cells : Must be 1. |
| 8 | 9 | See macros in: |
| 9 | 10 | include/dt-bindings/power/owl-s500-powergate.h for S500 |
| 10 | 11 | include/dt-bindings/power/owl-s700-powergate.h for S700 |
| 12 | + include/dt-bindings/power/owl-s900-powergate.h for S900 | |
| 11 | 13 | |
| 12 | 14 | |
| 13 | 15 | Example: |
| @@ -8,7 +8,9 @@ Required properties: · 7 unmodified lines | ||
| 8 | 8 | - compatible: Should be "renesas,<soctype>-apmu", "renesas,apmu" as fallback. |
| 9 | 9 | Examples with soctypes are: |
| 10 | 10 | - "renesas,r8a7743-apmu" (RZ/G1M) |
| 11 | + - "renesas,r8a7744-apmu" (RZ/G1N) | |
| 11 | 12 | - "renesas,r8a7745-apmu" (RZ/G1E) |
| 13 | + - "renesas,r8a77470-apmu" (RZ/G1C) | |
| 12 | 14 | - "renesas,r8a7790-apmu" (R-Car H2) |
| 13 | 15 | - "renesas,r8a7791-apmu" (R-Car M2-W) |
| 14 | 16 | - "renesas,r8a7792-apmu" (R-Car V2H) |
| @@ -8,8 +8,11 @@ and various coprocessors. · 7 unmodified lines | ||
| 8 | 8 | Required properties: |
| 9 | 9 | - compatible: Must contain exactly one of the following: |
| 10 | 10 | - "renesas,r8a7743-sysc" (RZ/G1M) |
| 11 | + - "renesas,r8a7744-sysc" (RZ/G1N) | |
| 11 | 12 | - "renesas,r8a7745-sysc" (RZ/G1E) |
| 12 | 13 | - "renesas,r8a77470-sysc" (RZ/G1C) |
| 14 | + - "renesas,r8a774a1-sysc" (RZ/G2M) | |
| 15 | + - "renesas,r8a774c0-sysc" (RZ/G2E) | |
| 13 | 16 | - "renesas,r8a7779-sysc" (R-Car H1) |
| 14 | 17 | - "renesas,r8a7790-sysc" (R-Car H2) |
| 15 | 18 | - "renesas,r8a7791-sysc" (R-Car M2-W) |
| @@ -6,7 +6,10 @@ and resin along with the Android reboot-mode. · 5 unmodified lines | ||
| 6 | 6 | This DT node has pwrkey and resin as sub nodes. |
| 7 | 7 | |
| 8 | 8 | Required Properties: |
| 9 | −-compatible: "qcom,pm8916-pon" | |
| 9 | +-compatible: Must be one of: | |
| 10 | + "qcom,pm8916-pon" | |
| 11 | + "qcom,pms405-pon" | |
| 12 | + | |
| 10 | 13 | -reg: Specifies the physical address of the pon register |
| 11 | 14 | |
| 12 | 15 | Optional subnode: |
| @@ -1,5 +1,8 @@ | ||
| 1 | 1 | Binding for TI bq25890 Li-Ion Charger |
| 2 | 2 | |
| 3 | +This driver will support the bq25896 and the bq25890. There are other ICs | |
| 4 | +in the same family but those have not been tested. | |
| 5 | + | |
| 3 | 6 | Required properties: |
| 4 | 7 | - compatible: Should contain one of the following: |
| 5 | 8 | * "ti,bq25890" |
| @@ -23,6 +23,7 @@ Required properties: · 22 unmodified lines | ||
| 23 | 23 | * "ti,bq27546" - BQ27546 |
| 24 | 24 | * "ti,bq27742" - BQ27742 |
| 25 | 25 | * "ti,bq27545" - BQ27545 |
| 26 | + * "ti,bq27411" - BQ27411 | |
| 26 | 27 | * "ti,bq27421" - BQ27421 |
| 27 | 28 | * "ti,bq27425" - BQ27425 |
| 28 | 29 | * "ti,bq27426" - BQ27426 |
| @@ -0,0 +1,40 @@ | ||
| 1 | +Spreadtrum SC2731 PMIC battery charger binding | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: Should be "sprd,sc2731-charger". | |
| 5 | + - reg: Address offset of charger register. | |
| 6 | + - phys: Contains a phandle to the USB phy. | |
| 7 | + | |
| 8 | +Optional Properties: | |
| 9 | +- monitored-battery: phandle of battery characteristics devicetree node. | |
| 10 | + The charger uses the following battery properties: | |
| 11 | +- charge-term-current-microamp: current for charge termination phase. | |
| 12 | +- constant-charge-voltage-max-microvolt: maximum constant input voltage. | |
| 13 | + See Documentation/devicetree/bindings/power/supply/battery.txt | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + | |
| 17 | + bat: battery { | |
| 18 | + compatible = "simple-battery"; | |
| 19 | + charge-term-current-microamp = <120000>; | |
| 20 | + constant-charge-voltage-max-microvolt = <4350000>; | |
| 21 | + ...... | |
| 22 | + }; | |
| 23 | + | |
| 24 | + sc2731_pmic: pmic@0 { | |
| 25 | + compatible = "sprd,sc2731"; | |
| 26 | + reg = <0>; | |
| 27 | + spi-max-frequency = <26000000>; | |
| 28 | + interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>; | |
| 29 | + interrupt-controller; | |
| 30 | + #interrupt-cells = <2>; | |
| 31 | + #address-cells = <1>; | |
| 32 | + #size-cells = <0>; | |
| 33 | + | |
| 34 | + charger@0 { | |
| 35 | + compatible = "sprd,sc2731-charger"; | |
| 36 | + reg = <0x0>; | |
| 37 | + phys = <&ssphy>; | |
| 38 | + monitored-battery = <&bat>; | |
| 39 | + }; | |
| 40 | + }; | |
| @@ -7,6 +7,7 @@ Required properties: · 6 unmodified lines | ||
| 7 | 7 | for da850 - compatible = "ti,da850-ecap", "ti,am3352-ecap", "ti,am33xx-ecap"; |
| 8 | 8 | for dra746 - compatible = "ti,dra746-ecap", "ti,am3352-ecap"; |
| 9 | 9 | for 66ak2g - compatible = "ti,k2g-ecap", "ti,am3352-ecap"; |
| 10 | + for am654 - compatible = "ti,am654-ecap", "ti,am3352-ecap"; | |
| 10 | 11 | - #pwm-cells: should be 3. See pwm.txt in this directory for a description of |
| 11 | 12 | the cells format. The PWM channel index ranges from 0 to 4. The only third |
| 12 | 13 | cell flag supported by this binding is PWM_POLARITY_INVERTED. |
| @@ -3,7 +3,9 @@ · 2 unmodified lines | ||
| 3 | 3 | Required Properties: |
| 4 | 4 | - compatible: should be "renesas,pwm-rcar" and one of the following. |
| 5 | 5 | - "renesas,pwm-r8a7743": for RZ/G1M |
| 6 | + - "renesas,pwm-r8a7744": for RZ/G1N | |
| 6 | 7 | - "renesas,pwm-r8a7745": for RZ/G1E |
| 8 | + - "renesas,pwm-r8a774a1": for RZ/G2M | |
| 7 | 9 | - "renesas,pwm-r8a7778": for R-Car M1A |
| 8 | 10 | - "renesas,pwm-r8a7779": for R-Car H1 |
| 9 | 11 | - "renesas,pwm-r8a7790": for R-Car H2 |
| @@ -12,6 +14,8 @@ Required Properties: · 2 unmodified lines | ||
| 12 | 14 | - "renesas,pwm-r8a7795": for R-Car H3 |
| 13 | 15 | - "renesas,pwm-r8a7796": for R-Car M3-W |
| 14 | 16 | - "renesas,pwm-r8a77965": for R-Car M3-N |
| 17 | + - "renesas,pwm-r8a77970": for R-Car V3M | |
| 18 | + - "renesas,pwm-r8a77980": for R-Car V3H | |
| 15 | 19 | - "renesas,pwm-r8a77990": for R-Car E3 |
| 16 | 20 | - "renesas,pwm-r8a77995": for R-Car D3 |
| 17 | 21 | - reg: base address and length of the registers block for the PWM. |
| @@ -2,13 +2,19 @@ · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required Properties: |
| 4 | 4 | |
| 5 | − - compatible: should be one of the following. | |
| 5 | + - compatible: must contain one or more of the following: | |
| 6 | 6 | - "renesas,tpu-r8a73a4": for R8A73A4 (R-Mobile APE6) compatible PWM controller. |
| 7 | 7 | - "renesas,tpu-r8a7740": for R8A7740 (R-Mobile A1) compatible PWM controller. |
| 8 | 8 | - "renesas,tpu-r8a7743": for R8A7743 (RZ/G1M) compatible PWM controller. |
| 9 | + - "renesas,tpu-r8a7744": for R8A7744 (RZ/G1N) compatible PWM controller. | |
| 9 | 10 | - "renesas,tpu-r8a7745": for R8A7745 (RZ/G1E) compatible PWM controller. |
| 10 | 11 | - "renesas,tpu-r8a7790": for R8A7790 (R-Car H2) compatible PWM controller. |
| 11 | − - "renesas,tpu": for generic R-Car and RZ/G1 TPU PWM controller. | |
| 12 | + - "renesas,tpu-r8a77970": for R8A77970 (R-Car V3M) compatible PWM | |
| 13 | + controller. | |
| 14 | + - "renesas,tpu-r8a77980": for R8A77980 (R-Car V3H) compatible PWM | |
| 15 | + controller. | |
| 16 | + - "renesas,tpu": for the generic TPU PWM controller; this is a fallback for | |
| 17 | + the entries listed above. | |
| 12 | 18 | |
| 13 | 19 | - reg: Base address and length of each memory resource used by the PWM |
| 14 | 20 | controller hardware module. |
| @@ -12,6 +12,11 @@ Optional properties: · 11 unmodified lines | ||
| 12 | 12 | disabled. This binding is a workaround to keep backward compatibility with |
| 13 | 13 | old dtb's which rely on the fact that the switched regulators are always on |
| 14 | 14 | and don't mark them explicit as "regulator-always-on". |
| 15 | +- fsl,pmic-stby-poweroff: if present, configure the PMIC to shutdown all | |
| 16 | + power rails when PMIC_STBY_REQ line is asserted during the power off sequence. | |
| 17 | + Use this option if the SoC should be powered off by external power | |
| 18 | + management IC (PMIC) on PMIC_STBY_REQ signal. | |
| 19 | + As opposite to PMIC_STBY_REQ boards can implement PMIC_ON_REQ signal. | |
| 15 | 20 | |
| 16 | 21 | Required child node: |
| 17 | 22 | - regulators: This is the list of child nodes that specify the regulator |
| @@ -26,6 +26,7 @@ Regulator nodes are identified by their compatible: · 25 unmodified lines | ||
| 26 | 26 | "qcom,rpm-pm8998-regulators" |
| 27 | 27 | "qcom,rpm-pma8084-regulators" |
| 28 | 28 | "qcom,rpm-pmi8998-regulators" |
| 29 | + "qcom,rpm-pms405-regulators" | |
| 29 | 30 | |
| 30 | 31 | - vdd_s1-supply: |
| 31 | 32 | - vdd_s2-supply: |
| @@ -188,6 +189,24 @@ Regulator nodes are identified by their compatible: · 156 unmodified lines | ||
| 188 | 189 | Definition: reference to regulator supplying the input pin, as |
| 189 | 190 | described in the data sheet |
| 190 | 191 | |
| 192 | +- vdd_s1-supply: | |
| 193 | +- vdd_s2-supply: | |
| 194 | +- vdd_s3-supply: | |
| 195 | +- vdd_s4-supply: | |
| 196 | +- vdd_s5-supply: | |
| 197 | +- vdd_l1_l2-supply: | |
| 198 | +- vdd_l3_l8-supply: | |
| 199 | +- vdd_l4-supply: | |
| 200 | +- vdd_l5_l6-supply: | |
| 201 | +- vdd_l7-supply: | |
| 202 | +- vdd_l3_l8-supply: | |
| 203 | +- vdd_l9-supply: | |
| 204 | +- vdd_l10_l11_l12_l13-supply: | |
| 205 | + Usage: optional (pms405 only) | |
| 206 | + Value type: <phandle> | |
| 207 | + Definition: reference to regulator supplying the input pin, as | |
| 208 | + described in the data sheet | |
| 209 | + | |
| 191 | 210 | The regulator node houses sub-nodes for each regulator within the device. Each |
| 192 | 211 | sub-node is identified using the node's name, with valid values listed for each |
| 193 | 212 | of the pmics below. |
| @@ -222,6 +241,10 @@ pma8084: · 28 unmodified lines | ||
| 222 | 241 | pmi8998: |
| 223 | 242 | bob |
| 224 | 243 | |
| 244 | +pms405: | |
| 245 | + s1, s2, s3, s4, s5, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, | |
| 246 | + l13 | |
| 247 | + | |
| 225 | 248 | The content of each sub-node is defined by the standard binding for regulators - |
| 226 | 249 | see regulator.txt. |
| 227 | 250 | |
| @@ -1,7 +1,9 @@ | ||
| 1 | −ROHM BD71837 Power Management Integrated Circuit (PMIC) regulator bindings | |
| 1 | +ROHM BD71837 and BD71847 Power Management Integrated Circuit regulator bindings | |
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | − - regulator-name: should be "buck1", ..., "buck8" and "ldo1", ..., "ldo7" | |
| 4 | + - regulator-name: should be "buck1", ..., "buck8" and "ldo1", ..., "ldo7" for | |
| 5 | + BD71837. For BD71847 names should be "buck1", ..., "buck6" | |
| 6 | + and "ldo1", ..., "ldo6" | |
| 5 | 7 | |
| 6 | 8 | List of regulators provided by this controller. BD71837 regulators node |
| 7 | 9 | should be sub node of the BD71837 MFD node. See BD71837 MFD bindings at |
| @@ -16,10 +18,14 @@ disabled by driver at startup. LDO5 and LDO6 are supplied by those and · 8 unmodified lines | ||
| 16 | 18 | if they are disabled at startup the voltage monitoring for LDO5/LDO6 will |
| 17 | 19 | cause PMIC to reset. |
| 18 | 20 | |
| 19 | −The valid names for regulator nodes are: | |
| 21 | +The valid names for BD71837 regulator nodes are: | |
| 20 | 22 | BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6, BUCK7, BUCK8 |
| 21 | 23 | LDO1, LDO2, LDO3, LDO4, LDO5, LDO6, LDO7 |
| 22 | 24 | |
| 25 | +The valid names for BD71847 regulator nodes are: | |
| 26 | +BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6 | |
| 27 | +LDO1, LDO2, LDO3, LDO4, LDO5, LDO6 | |
| 28 | + | |
| 23 | 29 | Optional properties: |
| 24 | 30 | - Any optional property defined in bindings/regulator/regulator.txt |
| 25 | 31 | |
| @@ -0,0 +1,68 @@ | ||
| 1 | +STMicroelectronics STPMIC1 Voltage regulators | |
| 2 | + | |
| 3 | +Regulator Nodes are optional depending on needs. | |
| 4 | + | |
| 5 | +Available Regulators in STPMIC1 device are: | |
| 6 | + - buck1 for Buck BUCK1 | |
| 7 | + - buck2 for Buck BUCK2 | |
| 8 | + - buck3 for Buck BUCK3 | |
| 9 | + - buck4 for Buck BUCK4 | |
| 10 | + - ldo1 for LDO LDO1 | |
| 11 | + - ldo2 for LDO LDO2 | |
| 12 | + - ldo3 for LDO LDO3 | |
| 13 | + - ldo4 for LDO LDO4 | |
| 14 | + - ldo5 for LDO LDO5 | |
| 15 | + - ldo6 for LDO LDO6 | |
| 16 | + - vref_ddr for LDO Vref DDR | |
| 17 | + - boost for Buck BOOST | |
| 18 | + - pwr_sw1 for VBUS_OTG switch | |
| 19 | + - pwr_sw2 for SW_OUT switch | |
| 20 | + | |
| 21 | +Switches are fixed voltage regulators with only enable/disable capability. | |
| 22 | + | |
| 23 | +Optional properties: | |
| 24 | +- st,mask-reset: mask reset for this regulator: the regulator configuration | |
| 25 | + is maintained during pmic reset. | |
| 26 | +- regulator-pull-down: enable high pull down | |
| 27 | + if not specified light pull down is used | |
| 28 | +- regulator-over-current-protection: | |
| 29 | + if set, all regulators are switched off in case of over-current detection | |
| 30 | + on this regulator, | |
| 31 | + if not set, the driver only sends an over-current event. | |
| 32 | +- interrupt-parent: phandle to the parent interrupt controller | |
| 33 | +- interrupts: index of current limit detection interrupt | |
| 34 | +- <regulator>-supply: phandle to the parent supply/regulator node | |
| 35 | + each regulator supply can be described except vref_ddr. | |
| 36 | + | |
| 37 | +Example: | |
| 38 | +regulators { | |
| 39 | + compatible = "st,stpmic1-regulators"; | |
| 40 | + | |
| 41 | + ldo6-supply = <&v3v3>; | |
| 42 | + | |
| 43 | + vdd_core: buck1 { | |
| 44 | + regulator-name = "vdd_core"; | |
| 45 | + interrupts = <IT_CURLIM_BUCK1 0>; | |
| 46 | + interrupt-parent = <&pmic>; | |
| 47 | + st,mask-reset; | |
| 48 | + regulator-pull-down; | |
| 49 | + regulator-min-microvolt = <700000>; | |
| 50 | + regulator-max-microvolt = <1200000>; | |
| 51 | + }; | |
| 52 | + | |
| 53 | + v3v3: buck4 { | |
| 54 | + regulator-name = "v3v3"; | |
| 55 | + interrupts = <IT_CURLIM_BUCK4 0>; | |
| 56 | + interrupt-parent = <&mypmic>; | |
| 57 | + | |
| 58 | + regulator-min-microvolt = <3300000>; | |
| 59 | + regulator-max-microvolt = <3300000>; | |
| 60 | + }; | |
| 61 | + | |
| 62 | + v1v8: ldo6 { | |
| 63 | + regulator-name = "v1v8"; | |
| 64 | + regulator-min-microvolt = <1800000>; | |
| 65 | + regulator-max-microvolt = <1800000>; | |
| 66 | + regulator-over-current-protection; | |
| 67 | + }; | |
| 68 | +}; | |
| @@ -0,0 +1,126 @@ | ||
| 1 | +Qualcomm Technology Inc. ADSP Peripheral Image Loader | |
| 2 | + | |
| 3 | +This document defines the binding for a component that loads and boots firmware | |
| 4 | +on the Qualcomm Technology Inc. ADSP Hexagon core. | |
| 5 | + | |
| 6 | +- compatible: | |
| 7 | + Usage: required | |
| 8 | + Value type: <string> | |
| 9 | + Definition: must be one of: | |
| 10 | + "qcom,sdm845-adsp-pil" | |
| 11 | + | |
| 12 | +- reg: | |
| 13 | + Usage: required | |
| 14 | + Value type: <prop-encoded-array> | |
| 15 | + Definition: must specify the base address and size of the qdsp6ss register | |
| 16 | + | |
| 17 | +- interrupts-extended: | |
| 18 | + Usage: required | |
| 19 | + Value type: <prop-encoded-array> | |
| 20 | + Definition: must list the watchdog, fatal IRQs ready, handover and | |
| 21 | + stop-ack IRQs | |
| 22 | + | |
| 23 | +- interrupt-names: | |
| 24 | + Usage: required | |
| 25 | + Value type: <stringlist> | |
| 26 | + Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack" | |
| 27 | + | |
| 28 | +- clocks: | |
| 29 | + Usage: required | |
| 30 | + Value type: <prop-encoded-array> | |
| 31 | + Definition: List of 8 phandle and clock specifier pairs for the adsp. | |
| 32 | + | |
| 33 | +- clock-names: | |
| 34 | + Usage: required | |
| 35 | + Value type: <stringlist> | |
| 36 | + Definition: List of clock input name strings sorted in the same | |
| 37 | + order as the clocks property. Definition must have | |
| 38 | + "xo", "sway_cbcr", "lpass_aon", "lpass_ahbs_aon_cbcr", | |
| 39 | + "lpass_ahbm_aon_cbcr", "qdsp6ss_xo", "qdsp6ss_sleep" | |
| 40 | + and "qdsp6ss_core". | |
| 41 | + | |
| 42 | +- power-domains: | |
| 43 | + Usage: required | |
| 44 | + Value type: <phandle> | |
| 45 | + Definition: reference to cx power domain node. | |
| 46 | + | |
| 47 | +- resets: | |
| 48 | + Usage: required | |
| 49 | + Value type: <phandle> | |
| 50 | + Definition: reference to the list of 2 reset-controller for the adsp. | |
| 51 | + | |
| 52 | +- reset-names: | |
| 53 | + Usage: required | |
| 54 | + Value type: <stringlist> | |
| 55 | + Definition: must be "pdc_sync" and "cc_lpass" | |
| 56 | + | |
| 57 | +- qcom,halt-regs: | |
| 58 | + Usage: required | |
| 59 | + Value type: <prop-encoded-array> | |
| 60 | + Definition: a phandle reference to a syscon representing TCSR followed | |
| 61 | + by the offset within syscon for lpass halt register. | |
| 62 | + | |
| 63 | +- memory-region: | |
| 64 | + Usage: required | |
| 65 | + Value type: <phandle> | |
| 66 | + Definition: reference to the reserved-memory for the ADSP | |
| 67 | + | |
| 68 | +- qcom,smem-states: | |
| 69 | + Usage: required | |
| 70 | + Value type: <phandle> | |
| 71 | + Definition: reference to the smem state for requesting the ADSP to | |
| 72 | + shut down | |
| 73 | + | |
| 74 | +- qcom,smem-state-names: | |
| 75 | + Usage: required | |
| 76 | + Value type: <stringlist> | |
| 77 | + Definition: must be "stop" | |
| 78 | + | |
| 79 | + | |
| 80 | += SUBNODES | |
| 81 | +The adsp node may have an subnode named "glink-edge" that describes the | |
| 82 | +communication edge, channels and devices related to the ADSP. | |
| 83 | +See ../soc/qcom/qcom,glink.txt for details on how to describe these. | |
| 84 | + | |
| 85 | += EXAMPLE | |
| 86 | +The following example describes the resources needed to boot control the | |
| 87 | +ADSP, as it is found on SDM845 boards. | |
| 88 | + | |
| 89 | + remoteproc@17300000 { | |
| 90 | + compatible = "qcom,sdm845-adsp-pil"; | |
| 91 | + reg = <0x17300000 0x40c>; | |
| 92 | + | |
| 93 | + interrupts-extended = <&intc GIC_SPI 162 IRQ_TYPE_EDGE_RISING>, | |
| 94 | + <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, | |
| 95 | + <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, | |
| 96 | + <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, | |
| 97 | + <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; | |
| 98 | + interrupt-names = "wdog", "fatal", "ready", | |
| 99 | + "handover", "stop-ack"; | |
| 100 | + | |
| 101 | + clocks = <&rpmhcc RPMH_CXO_CLK>, | |
| 102 | + <&gcc GCC_LPASS_SWAY_CLK>, | |
| 103 | + <&lpasscc LPASS_AUDIO_WRAPPER_AON_CLK>, | |
| 104 | + <&lpasscc LPASS_Q6SS_AHBS_AON_CLK>, | |
| 105 | + <&lpasscc LPASS_Q6SS_AHBM_AON_CLK>, | |
| 106 | + <&lpasscc LPASS_QDSP6SS_XO_CLK>, | |
| 107 | + <&lpasscc LPASS_QDSP6SS_SLEEP_CLK>, | |
| 108 | + <&lpasscc LPASS_QDSP6SS_CORE_CLK>; | |
| 109 | + clock-names = "xo", "sway_cbcr", "lpass_aon", | |
| 110 | + "lpass_ahbs_aon_cbcr", | |
| 111 | + "lpass_ahbm_aon_cbcr", "qdsp6ss_xo", | |
| 112 | + "qdsp6ss_sleep", "qdsp6ss_core"; | |
| 113 | + | |
| 114 | + power-domains = <&rpmhpd SDM845_CX>; | |
| 115 | + | |
| 116 | + resets = <&pdc_reset PDC_AUDIO_SYNC_RESET>, | |
| 117 | + <&aoss_reset AOSS_CC_LPASS_RESTART>; | |
| 118 | + reset-names = "pdc_sync", "cc_lpass"; | |
| 119 | + | |
| 120 | + qcom,halt-regs = <&tcsr_mutex_regs 0x22000>; | |
| 121 | + | |
| 122 | + memory-region = <&pil_adsp_mem>; | |
| 123 | + | |
| 124 | + qcom,smem-states = <&adsp_smp2p_out 0>; | |
| 125 | + qcom,smem-state-names = "stop"; | |
| 126 | + }; | |
| @@ -10,6 +10,11 @@ on the Qualcomm ADSP Hexagon core. · 9 unmodified lines | ||
| 10 | 10 | "qcom,msm8974-adsp-pil" |
| 11 | 11 | "qcom,msm8996-adsp-pil" |
| 12 | 12 | "qcom,msm8996-slpi-pil" |
| 13 | + "qcom,qcs404-adsp-pas" | |
| 14 | + "qcom,qcs404-cdsp-pas" | |
| 15 | + "qcom,qcs404-wcss-pas" | |
| 16 | + "qcom,sdm845-adsp-pas" | |
| 17 | + "qcom,sdm845-cdsp-pas" | |
| 13 | 18 | |
| 14 | 19 | - interrupts-extended: |
| 15 | 20 | Usage: required |
| @@ -53,13 +53,17 @@ on the Qualcomm Hexagon core. · 52 unmodified lines | ||
| 53 | 53 | Definition: reference to the reset-controller for the modem sub-system |
| 54 | 54 | reference to the list of 3 reset-controllers for the |
| 55 | 55 | wcss sub-system |
| 56 | + reference to the list of 2 reset-controllers for the modem | |
| 57 | + sub-system on SDM845 SoCs | |
| 56 | 58 | |
| 57 | 59 | - reset-names: |
| 58 | 60 | Usage: required |
| 59 | 61 | Value type: <stringlist> |
| 60 | 62 | Definition: must be "mss_restart" for the modem sub-system |
| 61 | − Definition: must be "wcss_aon_reset", "wcss_reset", "wcss_q6_reset" | |
| 62 | − for the wcss syb-system | |
| 63 | + must be "wcss_aon_reset", "wcss_reset", "wcss_q6_reset" | |
| 64 | + for the wcss sub-system | |
| 65 | + must be "mss_restart", "pdc_reset" for the modem | |
| 66 | + sub-system on SDM845 SoCs | |
| 63 | 67 | |
| 64 | 68 | - cx-supply: |
| 65 | 69 | - mss-supply: |
| @@ -5,7 +5,7 @@ Please also refer to reset.txt in this directory for common reset · 4 unmodified lines | ||
| 5 | 5 | controller binding usage. |
| 6 | 6 | |
| 7 | 7 | Required properties: |
| 8 | −- compatible: Should be "fsl,imx7-src", "syscon" | |
| 8 | +- compatible: Should be "fsl,imx7d-src", "syscon" | |
| 9 | 9 | - reg: should be register base and length as documented in the |
| 10 | 10 | datasheet |
| 11 | 11 | - interrupts: Should contain SRC interrupt |
| @@ -0,0 +1,52 @@ | ||
| 1 | +PDC Global | |
| 2 | +====================================== | |
| 3 | + | |
| 4 | +This binding describes a reset-controller found on PDC-Global (Power Domain | |
| 5 | +Controller) block for Qualcomm Technologies Inc SDM845 SoCs. | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible: | |
| 9 | + Usage: required | |
| 10 | + Value type: <string> | |
| 11 | + Definition: must be: | |
| 12 | + "qcom,sdm845-pdc-global" | |
| 13 | + | |
| 14 | +- reg: | |
| 15 | + Usage: required | |
| 16 | + Value type: <prop-encoded-array> | |
| 17 | + Definition: must specify the base address and size of the register | |
| 18 | + space. | |
| 19 | + | |
| 20 | +- #reset-cells: | |
| 21 | + Usage: required | |
| 22 | + Value type: <uint> | |
| 23 | + Definition: must be 1; cell entry represents the reset index. | |
| 24 | + | |
| 25 | +Example: | |
| 26 | + | |
| 27 | +pdc_reset: reset-controller@b2e0000 { | |
| 28 | + compatible = "qcom,sdm845-pdc-global"; | |
| 29 | + reg = <0xb2e0000 0x20000>; | |
| 30 | + #reset-cells = <1>; | |
| 31 | +}; | |
| 32 | + | |
| 33 | +PDC reset clients | |
| 34 | +====================================== | |
| 35 | + | |
| 36 | +Device nodes that need access to reset lines should | |
| 37 | +specify them as a reset phandle in their corresponding node as | |
| 38 | +specified in reset.txt. | |
| 39 | + | |
| 40 | +For a list of all valid reset indices see | |
| 41 | +<dt-bindings/reset/qcom,sdm845-pdc.h> | |
| 42 | + | |
| 43 | +Example: | |
| 44 | + | |
| 45 | +modem-pil@4080000 { | |
| 46 | + ... | |
| 47 | + | |
| 48 | + resets = <&pdc_reset PDC_MODEM_SYNC_RESET>; | |
| 49 | + reset-names = "pdc_reset"; | |
| 50 | + | |
| 51 | + ... | |
| 52 | +}; | |
| @@ -16,8 +16,11 @@ Required properties: · 15 unmodified lines | ||
| 16 | 16 | - "renesas,<soctype>-rst" for R-Car Gen2 and Gen3, and RZ/G |
| 17 | 17 | Examples with soctypes are: |
| 18 | 18 | - "renesas,r8a7743-rst" (RZ/G1M) |
| 19 | + - "renesas,r8a7744-rst" (RZ/G1N) | |
| 19 | 20 | - "renesas,r8a7745-rst" (RZ/G1E) |
| 20 | 21 | - "renesas,r8a77470-rst" (RZ/G1C) |
| 22 | + - "renesas,r8a774a1-rst" (RZ/G2M) | |
| 23 | + - "renesas,r8a774c0-rst" (RZ/G2E) | |
| 21 | 24 | - "renesas,r8a7778-reset-wdt" (R-Car M1A) |
| 22 | 25 | - "renesas,r8a7779-reset-wdt" (R-Car H1) |
| 23 | 26 | - "renesas,r8a7790-rst" (R-Car H2) |
| @@ -14,6 +14,10 @@ Required properties: · 13 unmodified lines | ||
| 14 | 14 | - "renesas,scifa-r8a7743" for R8A7743 (RZ/G1M) SCIFA compatible UART. |
| 15 | 15 | - "renesas,scifb-r8a7743" for R8A7743 (RZ/G1M) SCIFB compatible UART. |
| 16 | 16 | - "renesas,hscif-r8a7743" for R8A7743 (RZ/G1M) HSCIF compatible UART. |
| 17 | + - "renesas,scif-r8a7744" for R8A7744 (RZ/G1N) SCIF compatible UART. | |
| 18 | + - "renesas,scifa-r8a7744" for R8A7744 (RZ/G1N) SCIFA compatible UART. | |
| 19 | + - "renesas,scifb-r8a7744" for R8A7744 (RZ/G1N) SCIFB compatible UART. | |
| 20 | + - "renesas,hscif-r8a7744" for R8A7744 (RZ/G1N) HSCIF compatible UART. | |
| 17 | 21 | - "renesas,scif-r8a7745" for R8A7745 (RZ/G1E) SCIF compatible UART. |
| 18 | 22 | - "renesas,scifa-r8a7745" for R8A7745 (RZ/G1E) SCIFA compatible UART. |
| 19 | 23 | - "renesas,scifb-r8a7745" for R8A7745 (RZ/G1E) SCIFB compatible UART. |
| @@ -50,6 +54,8 @@ Required properties: · 30 unmodified lines | ||
| 50 | 54 | - "renesas,hscif-r8a77970" for R8A77970 (R-Car V3M) HSCIF compatible UART. |
| 51 | 55 | - "renesas,scif-r8a77980" for R8A77980 (R-Car V3H) SCIF compatible UART. |
| 52 | 56 | - "renesas,hscif-r8a77980" for R8A77980 (R-Car V3H) HSCIF compatible UART. |
| 57 | + - "renesas,scif-r8a77990" for R8A77990 (R-Car E3) SCIF compatible UART. | |
| 58 | + - "renesas,hscif-r8a77990" for R8A77990 (R-Car E3) HSCIF compatible UART. | |
| 53 | 59 | - "renesas,scif-r8a77995" for R8A77995 (R-Car D3) SCIF compatible UART. |
| 54 | 60 | - "renesas,hscif-r8a77995" for R8A77995 (R-Car D3) HSCIF compatible UART. |
| 55 | 61 | - "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible UART. |
| @@ -7,7 +7,7 @@ Required properties: · 6 unmodified lines | ||
| 7 | 7 | - clocks: phandle to the input clock. |
| 8 | 8 | |
| 9 | 9 | Optional properties: |
| 10 | −- fifo-size: the RX/TX FIFO size. Defaults to 64 if not specified. | |
| 10 | +-auto-flow-control: enable automatic flow control support. | |
| 11 | 11 | |
| 12 | 12 | Example: |
| 13 | 13 | aliases { |
| @@ -19,5 +19,4 @@ Example: · 5 unmodified lines | ||
| 19 | 19 | reg = <0x54006800 0x40>; |
| 20 | 20 | interrupts = <0 33 4>; |
| 21 | 21 | clocks = <&uart_clk>; |
| 22 | − fifo-size = <64>; | |
| 23 | 22 | }; |
| @@ -0,0 +1,29 @@ | ||
| 1 | +Amlogic Canvas | |
| 2 | +================================ | |
| 3 | + | |
| 4 | +A canvas is a collection of metadata that describes a pixel buffer. | |
| 5 | +Those metadata include: width, height, phyaddr, wrapping, block mode | |
| 6 | +and endianness. | |
| 7 | + | |
| 8 | +Many IPs within Amlogic SoCs rely on canvas indexes to read/write pixel data | |
| 9 | +rather than use the phy addresses directly. For instance, this is the case for | |
| 10 | +the video decoders and the display. | |
| 11 | + | |
| 12 | +Amlogic SoCs have 256 canvas. | |
| 13 | + | |
| 14 | +Device Tree Bindings: | |
| 15 | +--------------------- | |
| 16 | + | |
| 17 | +Video Lookup Table | |
| 18 | +-------------------------- | |
| 19 | + | |
| 20 | +Required properties: | |
| 21 | +- compatible: "amlogic,canvas" | |
| 22 | +- reg: Base physical address and size of the canvas registers. | |
| 23 | + | |
| 24 | +Example: | |
| 25 | + | |
| 26 | +canvas: video-lut@48 { | |
| 27 | + compatible = "amlogic,canvas"; | |
| 28 | + reg = <0x0 0x48 0x0 0x14>; | |
| 29 | +}; | |
| @@ -98,6 +98,12 @@ The property below is dependent on fsl,tdm-interface: · 97 unmodified lines | ||
| 98 | 98 | usage: optional for tdm interface |
| 99 | 99 | value type: <empty> |
| 100 | 100 | Definition : Internal loopback connecting on TDM layer. |
| 101 | +- fsl,hmask | |
| 102 | + usage: optional | |
| 103 | + Value type: <u16> | |
| 104 | + Definition: HDLC address recognition. Set to zero to disable | |
| 105 | + address filtering of packets: | |
| 106 | + fsl,hmask = /bits/ 16 <0x0000>; | |
| 101 | 107 | |
| 102 | 108 | Example for tdm interface: |
| 103 | 109 | |
| @@ -19,10 +19,12 @@ IP Pairing · 18 unmodified lines | ||
| 19 | 19 | Required properties in pwrap device node. |
| 20 | 20 | - compatible: |
| 21 | 21 | "mediatek,mt2701-pwrap" for MT2701/7623 SoCs |
| 22 | + "mediatek,mt6765-pwrap" for MT6765 SoCs | |
| 22 | 23 | "mediatek,mt6797-pwrap" for MT6797 SoCs |
| 23 | 24 | "mediatek,mt7622-pwrap" for MT7622 SoCs |
| 24 | 25 | "mediatek,mt8135-pwrap" for MT8135 SoCs |
| 25 | 26 | "mediatek,mt8173-pwrap" for MT8173 SoCs |
| 27 | + "mediatek,mt8183-pwrap" for MT8183 SoCs | |
| 26 | 28 | - interrupts: IRQ for pwrap in SOC |
| 27 | 29 | - reg-names: Must include the following entries: |
| 28 | 30 | "pwrap": Main registers base |
| @@ -53,20 +53,8 @@ Required properties: · 52 unmodified lines | ||
| 53 | 53 | - clocks: Serial engine core clock needed by the device. |
| 54 | 54 | |
| 55 | 55 | Qualcomm Technologies Inc. GENI Serial Engine based SPI Controller |
| 56 | − | |
| 57 | −Required properties: | |
| 58 | −- compatible: Must contain "qcom,geni-spi". | |
| 59 | −- reg: Must contain SPI register location and length. | |
| 60 | −- interrupts: Must contain SPI controller interrupts. | |
| 61 | −- clock-names: Must contain "se". | |
| 62 | −- clocks: Serial engine core clock needed by the device. | |
| 63 | −- spi-max-frequency: Specifies maximum SPI clock frequency, units - Hz. | |
| 64 | −- #address-cells: Must be <1> to define a chip select address on | |
| 65 | − the SPI bus. | |
| 66 | −- #size-cells: Must be <0>. | |
| 67 | − | |
| 68 | −SPI slave nodes must be children of the SPI master node and conform to SPI bus | |
| 69 | −binding as described in Documentation/devicetree/bindings/spi/spi-bus.txt. | |
| 56 | +node binding is described in | |
| 57 | +Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.txt. | |
| 70 | 58 | |
| 71 | 59 | Example: |
| 72 | 60 | geniqup@8c0000 { |
| @@ -103,17 +91,4 @@ Example: · 30 unmodified lines | ||
| 103 | 91 | pinctrl-1 = <&qup_1_uart_3_sleep>; |
| 104 | 92 | }; |
| 105 | 93 | |
| 106 | − spi0: spi@a84000 { | |
| 107 | − compatible = "qcom,geni-spi"; | |
| 108 | − reg = <0xa84000 0x4000>; | |
| 109 | − interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>; | |
| 110 | − clock-names = "se"; | |
| 111 | − clocks = <&clock_gcc GCC_QUPV3_WRAP0_S0_CLK>; | |
| 112 | − pinctrl-names = "default", "sleep"; | |
| 113 | − pinctrl-0 = <&qup_1_spi_2_active>; | |
| 114 | − pinctrl-1 = <&qup_1_spi_2_sleep>; | |
| 115 | − spi-max-frequency = <19200000>; | |
| 116 | − #address-cells = <1>; | |
| 117 | − #size-cells = <0>; | |
| 118 | − }; | |
| 119 | 94 | } |
| @@ -13,6 +13,7 @@ On RK3328 SoCs, the GRF adds a section for USB2PHYGRF, · 12 unmodified lines | ||
| 13 | 13 | Required Properties: |
| 14 | 14 | |
| 15 | 15 | - compatible: GRF should be one of the following: |
| 16 | + - "rockchip,px30-grf", "syscon": for px30 | |
| 16 | 17 | - "rockchip,rk3036-grf", "syscon": for rk3036 |
| 17 | 18 | - "rockchip,rk3066-grf", "syscon": for rk3066 |
| 18 | 19 | - "rockchip,rk3188-grf", "syscon": for rk3188 |
| @@ -23,6 +24,7 @@ Required Properties: · 4 unmodified lines | ||
| 23 | 24 | - "rockchip,rk3399-grf", "syscon": for rk3399 |
| 24 | 25 | - "rockchip,rv1108-grf", "syscon": for rv1108 |
| 25 | 26 | - compatible: PMUGRF should be one of the following: |
| 27 | + - "rockchip,px30-pmugrf", "syscon": for px30 | |
| 26 | 28 | - "rockchip,rk3368-pmugrf", "syscon": for rk3368 |
| 27 | 29 | - "rockchip,rk3399-pmugrf", "syscon": for rk3399 |
| 28 | 30 | - compatible: SGRF should be one of the following |
| @@ -0,0 +1,54 @@ | ||
| 1 | +Analog Devices ADAU1977/ADAU1978/ADAU1979 | |
| 2 | + | |
| 3 | +Datasheets: | |
| 4 | +http://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1977.pdf | |
| 5 | +http://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1978.pdf | |
| 6 | +http://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1979.pdf | |
| 7 | + | |
| 8 | +This driver supports both the I2C and SPI bus. | |
| 9 | + | |
| 10 | +Required properties: | |
| 11 | + - compatible: Should contain one of the following: | |
| 12 | + "adi,adau1977" | |
| 13 | + "adi,adau1978" | |
| 14 | + "adi,adau1979" | |
| 15 | + | |
| 16 | + - AVDD-supply: analog power supply for the device, please consult | |
| 17 | + Documentation/devicetree/bindings/regulator/regulator.txt | |
| 18 | + | |
| 19 | +Optional properties: | |
| 20 | + - reset-gpio: the reset pin for the chip, for more details consult | |
| 21 | + Documentation/devicetree/bindings/gpio/gpio.txt | |
| 22 | + | |
| 23 | + - DVDD-supply: supply voltage for the digital core, please consult | |
| 24 | + Documentation/devicetree/bindings/regulator/regulator.txt | |
| 25 | + | |
| 26 | +For required properties on SPI, please consult | |
| 27 | +Documentation/devicetree/bindings/spi/spi-bus.txt | |
| 28 | + | |
| 29 | +Required properties on I2C: | |
| 30 | + | |
| 31 | + - reg: The i2c address. Value depends on the state of ADDR0 | |
| 32 | + and ADDR1, as wired in hardware. | |
| 33 | + | |
| 34 | +Examples: | |
| 35 | + | |
| 36 | + adau1977_spi: adau1977@0 { | |
| 37 | + compatible = "adi,adau1977"; | |
| 38 | + spi-max-frequency = <600000>; | |
| 39 | + | |
| 40 | + AVDD-supply = <®ulator>; | |
| 41 | + DVDD-supply = <®ulator_digital>; | |
| 42 | + | |
| 43 | + reset_gpio = <&gpio 10 GPIO_ACTIVE_LOW>; | |
| 44 | + }; | |
| 45 | + | |
| 46 | + adau1977_i2c: adau1977@11 { | |
| 47 | + compatible = "adi,adau1977"; | |
| 48 | + reg = <0x11>; | |
| 49 | + | |
| 50 | + AVDD-supply = <®ulator>; | |
| 51 | + DVDD-supply = <®ulator_digital>; | |
| 52 | + | |
| 53 | + reset_gpio = <&gpio 10 GPIO_ACTIVE_LOW>; | |
| 54 | + }; | |
| @@ -0,0 +1,24 @@ | ||
| 1 | +* Amlogic Audio PDM input | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: 'amlogic,axg-pdm' | |
| 5 | +- reg: physical base address of the controller and length of memory | |
| 6 | + mapped region. | |
| 7 | +- clocks: list of clock phandle, one for each entry clock-names. | |
| 8 | +- clock-names: should contain the following: | |
| 9 | + * "pclk" : peripheral clock. | |
| 10 | + * "dclk" : pdm digital clock | |
| 11 | + * "sysclk" : dsp system clock | |
| 12 | +- #sound-dai-cells: must be 0. | |
| 13 | + | |
| 14 | +Example of PDM on the A113 SoC: | |
| 15 | + | |
| 16 | +pdm: audio-controller@ff632000 { | |
| 17 | + compatible = "amlogic,axg-pdm"; | |
| 18 | + reg = <0x0 0xff632000 0x0 0x34>; | |
| 19 | + #sound-dai-cells = <0>; | |
| 20 | + clocks = <&clkc_audio AUD_CLKID_PDM>, | |
| 21 | + <&clkc_audio AUD_CLKID_PDM_DCLK>, | |
| 22 | + <&clkc_audio AUD_CLKID_PDM_SYSCLK>; | |
| 23 | + clock-names = "pclk", "dclk", "sysclk"; | |
| 24 | +}; | |
| @@ -0,0 +1,17 @@ | ||
| 1 | +CS42L51 audio CODEC | |
| 2 | + | |
| 3 | +Optional properties: | |
| 4 | + | |
| 5 | + - clocks : a list of phandles + clock-specifiers, one for each entry in | |
| 6 | + clock-names | |
| 7 | + | |
| 8 | + - clock-names : must contain "MCLK" | |
| 9 | + | |
| 10 | +Example: | |
| 11 | + | |
| 12 | +cs42l51: cs42l51@4a { | |
| 13 | + compatible = "cirrus,cs42l51"; | |
| 14 | + reg = <0x4a>; | |
| 15 | + clocks = <&mclk_prov>; | |
| 16 | + clock-names = "MCLK"; | |
| 17 | +}; | |
| @@ -0,0 +1,23 @@ | ||
| 1 | +MAX98088 audio CODEC | |
| 2 | + | |
| 3 | +This device supports I2C only. | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + | |
| 7 | +- compatible: "maxim,max98088" or "maxim,max98089". | |
| 8 | +- reg: The I2C address of the device. | |
| 9 | + | |
| 10 | +Optional properties: | |
| 11 | + | |
| 12 | +- clocks: the clock provider of MCLK, see ../clock/clock-bindings.txt section | |
| 13 | + "consumer" for more information. | |
| 14 | +- clock-names: must be set to "mclk" | |
| 15 | + | |
| 16 | +Example: | |
| 17 | + | |
| 18 | +max98089: codec@10 { | |
| 19 | + compatible = "maxim,max98089"; | |
| 20 | + reg = <0x10>; | |
| 21 | + clocks = <&clks IMX6QDL_CLK_CKO2>; | |
| 22 | + clock-names = "mclk"; | |
| 23 | +}; | |
| @@ -0,0 +1,23 @@ | ||
| 1 | +Mikroe-PROTO audio board | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: "mikroe,mikroe-proto" | |
| 5 | + - dai-format: Must be "i2s". | |
| 6 | + - i2s-controller: The phandle of the I2S controller. | |
| 7 | + - audio-codec: The phandle of the WM8731 audio codec. | |
| 8 | +Optional properties: | |
| 9 | + - model: The user-visible name of this sound complex. | |
| 10 | + - bitclock-master: Indicates dai-link bit clock master; for details see simple-card.txt (1). | |
| 11 | + - frame-master: Indicates dai-link frame master; for details see simple-card.txt (1). | |
| 12 | + | |
| 13 | +(1) : There must be the same master for both bit and frame clocks. | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + sound { | |
| 17 | + compatible = "mikroe,mikroe-proto"; | |
| 18 | + model = "wm8731 @ sama5d2_xplained"; | |
| 19 | + i2s-controller = <&i2s0>; | |
| 20 | + audio-codec = <&wm8731>; | |
| 21 | + dai-format = "i2s"; | |
| 22 | + }; | |
| 23 | +}; | |
| @@ -0,0 +1,16 @@ | ||
| 1 | +NAU8822 audio CODEC | |
| 2 | + | |
| 3 | +This device supports I2C only. | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + | |
| 7 | + - compatible : "nuvoton,nau8822" | |
| 8 | + | |
| 9 | + - reg : the I2C address of the device. | |
| 10 | + | |
| 11 | +Example: | |
| 12 | + | |
| 13 | +codec: nau8822@1a { | |
| 14 | + compatible = "nuvoton,nau8822"; | |
| 15 | + reg = <0x1a>; | |
| 16 | +}; | |
| @@ -0,0 +1,17 @@ | ||
| 1 | +PCM3060 audio CODEC | |
| 2 | + | |
| 3 | +This driver supports both I2C and SPI. | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + | |
| 7 | +- compatible: "ti,pcm3060" | |
| 8 | + | |
| 9 | +- reg : the I2C address of the device for I2C, the chip select | |
| 10 | + number for SPI. | |
| 11 | + | |
| 12 | +Examples: | |
| 13 | + | |
| 14 | + pcm3060: pcm3060@46 { | |
| 15 | + compatible = "ti,pcm3060"; | |
| 16 | + reg = <0x46>; | |
| 17 | + }; | |
| @@ -49,7 +49,7 @@ configuration of each dai. Must contain the following properties. · 48 unmodified lines | ||
| 49 | 49 | Usage: required for mi2s interface |
| 50 | 50 | Value type: <prop-encoded-array> |
| 51 | 51 | Definition: Must be list of serial data lines used by this dai. |
| 52 | − should be one or more of the 1-4 sd lines. | |
| 52 | + should be one or more of the 0-3 sd lines. | |
| 53 | 53 | |
| 54 | 54 | - qcom,tdm-sync-mode: |
| 55 | 55 | Usage: required for tdm interface |
| @@ -137,42 +137,42 @@ q6afe@4 { · 81 unmodified lines | ||
| 137 | 137 | |
| 138 | 138 | prim-mi2s-rx@16 { |
| 139 | 139 | reg = <16>; |
| 140 | − qcom,sd-lines = <1 3>; | |
| 140 | + qcom,sd-lines = <0 2>; | |
| 141 | 141 | }; |
| 142 | 142 | |
| 143 | 143 | prim-mi2s-tx@17 { |
| 144 | 144 | reg = <17>; |
| 145 | − qcom,sd-lines = <2>; | |
| 145 | + qcom,sd-lines = <1>; | |
| 146 | 146 | }; |
| 147 | 147 | |
| 148 | 148 | sec-mi2s-rx@18 { |
| 149 | 149 | reg = <18>; |
| 150 | − qcom,sd-lines = <1 4>; | |
| 150 | + qcom,sd-lines = <0 3>; | |
| 151 | 151 | }; |
| 152 | 152 | |
| 153 | 153 | sec-mi2s-tx@19 { |
| 154 | 154 | reg = <19>; |
| 155 | − qcom,sd-lines = <2>; | |
| 155 | + qcom,sd-lines = <1>; | |
| 156 | 156 | }; |
| 157 | 157 | |
| 158 | 158 | tert-mi2s-rx@20 { |
| 159 | 159 | reg = <20>; |
| 160 | − qcom,sd-lines = <2 4>; | |
| 160 | + qcom,sd-lines = <1 3>; | |
| 161 | 161 | }; |
| 162 | 162 | |
| 163 | 163 | tert-mi2s-tx@21 { |
| 164 | 164 | reg = <21>; |
| 165 | − qcom,sd-lines = <1>; | |
| 165 | + qcom,sd-lines = <0>; | |
| 166 | 166 | }; |
| 167 | 167 | |
| 168 | 168 | quat-mi2s-rx@22 { |
| 169 | 169 | reg = <22>; |
| 170 | − qcom,sd-lines = <1>; | |
| 170 | + qcom,sd-lines = <0>; | |
| 171 | 171 | }; |
| 172 | 172 | |
| 173 | 173 | quat-mi2s-tx@23 { |
| 174 | 174 | reg = <23>; |
| 175 | − qcom,sd-lines = <2>; | |
| 175 | + qcom,sd-lines = <1>; | |
| 176 | 176 | }; |
| 177 | 177 | }; |
| 178 | 178 | }; |
| @@ -340,10 +340,12 @@ Required properties: · 339 unmodified lines | ||
| 340 | 340 | - compatible : "renesas,rcar_sound-<soctype>", fallbacks |
| 341 | 341 | "renesas,rcar_sound-gen1" if generation1, and |
| 342 | 342 | "renesas,rcar_sound-gen2" if generation2 (or RZ/G1) |
| 343 | − "renesas,rcar_sound-gen3" if generation3 | |
| 343 | + "renesas,rcar_sound-gen3" if generation3 (or RZ/G2) | |
| 344 | 344 | Examples with soctypes are: |
| 345 | 345 | - "renesas,rcar_sound-r8a7743" (RZ/G1M) |
| 346 | + - "renesas,rcar_sound-r8a7744" (RZ/G1N) | |
| 346 | 347 | - "renesas,rcar_sound-r8a7745" (RZ/G1E) |
| 348 | + - "renesas,rcar_sound-r8a774a1" (RZ/G2M) | |
| 347 | 349 | - "renesas,rcar_sound-r8a7778" (R-Car M1A) |
| 348 | 350 | - "renesas,rcar_sound-r8a7779" (R-Car H1) |
| 349 | 351 | - "renesas,rcar_sound-r8a7790" (R-Car H2) |
| @@ -353,6 +355,7 @@ Required properties: · 3 unmodified lines | ||
| 353 | 355 | - "renesas,rcar_sound-r8a7795" (R-Car H3) |
| 354 | 356 | - "renesas,rcar_sound-r8a7796" (R-Car M3-W) |
| 355 | 357 | - "renesas,rcar_sound-r8a77965" (R-Car M3-N) |
| 358 | + - "renesas,rcar_sound-r8a77990" (R-Car E3) | |
| 356 | 359 | - reg : Should contain the register physical address. |
| 357 | 360 | required register is |
| 358 | 361 | SRU/ADG/SSI if generation1 |
| @@ -19,6 +19,10 @@ Required properties: · 18 unmodified lines | ||
| 19 | 19 | |
| 20 | 20 | Optional properties: |
| 21 | 21 | |
| 22 | + - clocks, clock-names: Clock specifier for XTI input clock. | |
| 23 | + If specified, the clock will be enabled when the codec is probed, | |
| 24 | + and disabled when it is removed. The 'clock-names' must be set to 'xti'. | |
| 25 | + | |
| 22 | 26 | - st,output-conf: number, Selects the output configuration: |
| 23 | 27 | 0: 2-channel (full-bridge) power, 2-channel data-out |
| 24 | 28 | 1: 2 (half-bridge). 1 (full-bridge) on-board power |
| @@ -39,6 +43,9 @@ Optional properties: · 14 unmodified lines | ||
| 39 | 43 | - st,thermal-warning-recover: |
| 40 | 44 | If present, thermal warning recovery is enabled. |
| 41 | 45 | |
| 46 | + - st,fault-detect-recovery: | |
| 47 | + If present, fault detect recovery is enabled. | |
| 48 | + | |
| 42 | 49 | - st,thermal-warning-adjustment: |
| 43 | 50 | If present, thermal warning adjustment is enabled. |
| 44 | 51 | |
| @@ -76,6 +83,8 @@ Example: · 31 unmodified lines | ||
| 76 | 83 | codec: sta32x@38 { |
| 77 | 84 | compatible = "st,sta32x"; |
| 78 | 85 | reg = <0x1c>; |
| 86 | + clocks = <&clock>; | |
| 87 | + clock-names = "xti"; | |
| 79 | 88 | reset-gpios = <&gpio1 19 0>; |
| 80 | 89 | power-down-gpios = <&gpio1 16 0>; |
| 81 | 90 | st,output-conf = /bits/ 8 <0x3>; // set output to 2-channel |
| @@ -31,7 +31,11 @@ SAI subnodes required properties: · 30 unmodified lines | ||
| 31 | 31 | - reg: Base address and size of SAI sub-block register set. |
| 32 | 32 | - clocks: Must contain one phandle and clock specifier pair |
| 33 | 33 | for sai_ck which feeds the internal clock generator. |
| 34 | + If the SAI shares a master clock, with another SAI set as MCLK | |
| 35 | + clock provider, SAI provider phandle must be specified here. | |
| 34 | 36 | - clock-names: Must contain "sai_ck". |
| 37 | + Must also contain "MCLK", if SAI shares a master clock, | |
| 38 | + with a SAI set as MCLK clock provider. | |
| 35 | 39 | - dmas: see Documentation/devicetree/bindings/dma/stm32-dma.txt |
| 36 | 40 | - dma-names: identifier string for each DMA request line |
| 37 | 41 | "tx": if sai sub-block is configured as playback DAI |
| @@ -51,6 +55,9 @@ SAI subnodes Optional properties: · 13 unmodified lines | ||
| 51 | 55 | configured according to protocol defined in related DAI link node, |
| 52 | 56 | such as i2s, left justified, right justified, dsp and pdm protocols. |
| 53 | 57 | Note: ac97 protocol is not supported by SAI driver |
| 58 | + - #clock-cells: should be 0. This property must be present if the SAI device | |
| 59 | + is a master clock provider, according to clocks bindings, described in | |
| 60 | + Documentation/devicetree/bindings/clock/clock-bindings.txt. | |
| 54 | 61 | |
| 55 | 62 | The device node should contain one 'port' child node with one child 'endpoint' |
| 56 | 63 | node, according to the bindings defined in Documentation/devicetree/bindings/ |
| @@ -10,6 +10,7 @@ Required properties: · 9 unmodified lines | ||
| 10 | 10 | - "allwinner,sun6i-a31-i2s" |
| 11 | 11 | - "allwinner,sun8i-a83t-i2s" |
| 12 | 12 | - "allwinner,sun8i-h3-i2s" |
| 13 | + - "allwinner,sun50i-a64-codec-i2s" | |
| 13 | 14 | - reg: physical base address of the controller and length of memory mapped |
| 14 | 15 | region. |
| 15 | 16 | - interrupts: should contain the I2S interrupt. |
| @@ -26,6 +27,7 @@ Required properties for the following compatibles: · 10 unmodified lines | ||
| 26 | 27 | - "allwinner,sun6i-a31-i2s" |
| 27 | 28 | - "allwinner,sun8i-a83t-i2s" |
| 28 | 29 | - "allwinner,sun8i-h3-i2s" |
| 30 | + - "allwinner,sun50i-a64-codec-i2s" | |
| 29 | 31 | - resets: phandle to the reset line for this codec |
| 30 | 32 | |
| 31 | 33 | Example: |
| @@ -0,0 +1,12 @@ | ||
| 1 | +* Allwinner A64 Codec Analog Controls | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: must be one of the following compatibles: | |
| 5 | + - "allwinner,sun50i-a64-codec-analog" | |
| 6 | +- reg: must contain the registers location and length | |
| 7 | + | |
| 8 | +Example: | |
| 9 | + codec_analog: codec-analog@1f015c0 { | |
| 10 | + compatible = "allwinner,sun50i-a64-codec-analog"; | |
| 11 | + reg = <0x01f015c0 0x4>; | |
| 12 | + }; | |
| @@ -14,7 +14,7 @@ Required properties: · 13 unmodified lines | ||
| 14 | 14 | |
| 15 | 15 | Optional properies: |
| 16 | 16 | - ti,micbias: Intended MICBIAS voltage (datasheet section 9.6.7). |
| 17 | − Select 0/1/2/3/4/5/6/7 to specify MACBIAS voltage | |
| 17 | + Select 0/1/2/3/4/5/6/7 to specify MICBIAS voltage | |
| 18 | 18 | 2.1V/2.2V/2.3V/2.4V/2.5V/2.6V/2.7V/2.8V |
| 19 | 19 | Default value is "1" (2.2V). |
| 20 | 20 | |
| @@ -0,0 +1,17 @@ | ||
| 1 | +WM8782 stereo ADC | |
| 2 | + | |
| 3 | +This device does not have any control interface or reset pins. | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + | |
| 7 | + - compatible : "wlf,wm8782" | |
| 8 | + - Vdda-supply : phandle to a regulator for the analog power supply (2.7V - 5.5V) | |
| 9 | + - Vdd-supply : phandle to a regulator for the digital power supply (2.7V - 3.6V) | |
| 10 | + | |
| 11 | +Example: | |
| 12 | + | |
| 13 | +wm8782: stereo-adc { | |
| 14 | + compatible = "wlf,wm8782"; | |
| 15 | + Vdda-supply = <&vdda_supply>; | |
| 16 | + Vdd-supply = <&vdd_supply>; | |
| 17 | +}; | |
| @@ -0,0 +1,39 @@ | ||
| 1 | +GENI based Qualcomm Universal Peripheral (QUP) Serial Peripheral Interface (SPI) | |
| 2 | + | |
| 3 | +The QUP v3 core is a GENI based AHB slave that provides a common data path | |
| 4 | +(an output FIFO and an input FIFO) for serial peripheral interface (SPI) | |
| 5 | +mini-core. | |
| 6 | + | |
| 7 | +SPI in master mode supports up to 50MHz, up to four chip selects, programmable | |
| 8 | +data path from 4 bits to 32 bits and numerous protocol variants. | |
| 9 | + | |
| 10 | +Required properties: | |
| 11 | +- compatible: Must contain "qcom,geni-spi". | |
| 12 | +- reg: Must contain SPI register location and length. | |
| 13 | +- interrupts: Must contain SPI controller interrupts. | |
| 14 | +- clock-names: Must contain "se". | |
| 15 | +- clocks: Serial engine core clock needed by the device. | |
| 16 | +- #address-cells: Must be <1> to define a chip select address on | |
| 17 | + the SPI bus. | |
| 18 | +- #size-cells: Must be <0>. | |
| 19 | + | |
| 20 | +SPI Controller nodes must be child of GENI based Qualcomm Universal | |
| 21 | +Peripharal. Please refer GENI based QUP wrapper controller node bindings | |
| 22 | +described in Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt. | |
| 23 | + | |
| 24 | +SPI slave nodes must be children of the SPI master node and conform to SPI bus | |
| 25 | +binding as described in Documentation/devicetree/bindings/spi/spi-bus.txt. | |
| 26 | + | |
| 27 | +Example: | |
| 28 | + spi0: spi@a84000 { | |
| 29 | + compatible = "qcom,geni-spi"; | |
| 30 | + reg = <0xa84000 0x4000>; | |
| 31 | + interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>; | |
| 32 | + clock-names = "se"; | |
| 33 | + clocks = <&clock_gcc GCC_QUPV3_WRAP0_S0_CLK>; | |
| 34 | + pinctrl-names = "default", "sleep"; | |
| 35 | + pinctrl-0 = <&qup_1_spi_2_active>; | |
| 36 | + pinctrl-1 = <&qup_1_spi_2_sleep>; | |
| 37 | + #address-cells = <1>; | |
| 38 | + #size-cells = <0>; | |
| 39 | + }; | |
| @@ -0,0 +1,36 @@ | ||
| 1 | +Qualcomm Quad Serial Peripheral Interface (QSPI) | |
| 2 | + | |
| 3 | +The QSPI controller allows SPI protocol communication in single, dual, or quad | |
| 4 | +wire transmission modes for read/write access to slaves such as NOR flash. | |
| 5 | + | |
| 6 | +Required properties: | |
| 7 | +- compatible: An SoC specific identifier followed by "qcom,qspi-v1", such as | |
| 8 | + "qcom,sdm845-qspi", "qcom,qspi-v1" | |
| 9 | +- reg: Should contain the base register location and length. | |
| 10 | +- interrupts: Interrupt number used by the controller. | |
| 11 | +- clocks: Should contain the core and AHB clock. | |
| 12 | +- clock-names: Should be "core" for core clock and "iface" for AHB clock. | |
| 13 | + | |
| 14 | +SPI slave nodes must be children of the SPI master node and can contain | |
| 15 | +properties described in Documentation/devicetree/bindings/spi/spi-bus.txt | |
| 16 | + | |
| 17 | +Example: | |
| 18 | + | |
| 19 | + qspi: spi@88df000 { | |
| 20 | + compatible = "qcom,sdm845-qspi", "qcom,qspi-v1"; | |
| 21 | + reg = <0x88df000 0x600>; | |
| 22 | + #address-cells = <1>; | |
| 23 | + #size-cells = <0>; | |
| 24 | + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>; | |
| 25 | + clock-names = "iface", "core"; | |
| 26 | + clocks = <&gcc GCC_QSPI_CNOC_PERIPH_AHB_CLK>, | |
| 27 | + <&gcc GCC_QSPI_CORE_CLK>; | |
| 28 | + | |
| 29 | + flash@0 { | |
| 30 | + compatible = "jedec,spi-nor"; | |
| 31 | + reg = <0>; | |
| 32 | + spi-max-frequency = <25000000>; | |
| 33 | + spi-tx-bus-width = <2>; | |
| 34 | + spi-rx-bus-width = <2>; | |
| 35 | + }; | |
| 36 | + }; | |
| @@ -2,7 +2,9 @@ Renesas MSIOF spi controller · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible : "renesas,msiof-r8a7743" (RZ/G1M) |
| 5 | + "renesas,msiof-r8a7744" (RZ/G1N) | |
| 5 | 6 | "renesas,msiof-r8a7745" (RZ/G1E) |
| 7 | + "renesas,msiof-r8a774a1" (RZ/G2M) | |
| 6 | 8 | "renesas,msiof-r8a7790" (R-Car H2) |
| 7 | 9 | "renesas,msiof-r8a7791" (R-Car M2-W) |
| 8 | 10 | "renesas,msiof-r8a7792" (R-Car V2H) |
| @@ -11,10 +13,14 @@ Required properties: · 2 unmodified lines | ||
| 11 | 13 | "renesas,msiof-r8a7795" (R-Car H3) |
| 12 | 14 | "renesas,msiof-r8a7796" (R-Car M3-W) |
| 13 | 15 | "renesas,msiof-r8a77965" (R-Car M3-N) |
| 16 | + "renesas,msiof-r8a77970" (R-Car V3M) | |
| 17 | + "renesas,msiof-r8a77980" (R-Car V3H) | |
| 18 | + "renesas,msiof-r8a77990" (R-Car E3) | |
| 19 | + "renesas,msiof-r8a77995" (R-Car D3) | |
| 14 | 20 | "renesas,msiof-sh73a0" (SH-Mobile AG5) |
| 15 | 21 | "renesas,sh-mobile-msiof" (generic SH-Mobile compatibile device) |
| 16 | 22 | "renesas,rcar-gen2-msiof" (generic R-Car Gen2 and RZ/G1 compatible device) |
| 17 | − "renesas,rcar-gen3-msiof" (generic R-Car Gen3 compatible device) | |
| 23 | + "renesas,rcar-gen3-msiof" (generic R-Car Gen3 and RZ/G2 compatible device) | |
| 18 | 24 | "renesas,sh-msiof" (deprecated) |
| 19 | 25 | |
| 20 | 26 | When compatible with the generic version, nodes |
| @@ -2,7 +2,7 @@ Synopsys DesignWare AMBA 2.0 Synchronous Serial Interface. · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible : "snps,dw-apb-ssi" or "mscc,<soc>-spi", where soc is "ocelot" or |
| 5 | − "jaguar2" | |
| 5 | + "jaguar2", or "amazon,alpine-dw-apb-ssi" | |
| 6 | 6 | - reg : The register base for the controller. For "mscc,<soc>-spi", a second |
| 7 | 7 | register set is required (named ICPU_CFG:SPI_MST) |
| 8 | 8 | - interrupts : One interrupt, used by the controller. |
| @@ -3,6 +3,7 @@ · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible : |
| 5 | 5 | - "fsl,imx7ulp-spi" for LPSPI compatible with the one integrated on i.MX7ULP soc |
| 6 | + - "fsl,imx8qxp-spi" for LPSPI compatible with the one integrated on i.MX8QXP soc | |
| 6 | 7 | - reg : address and length of the lpspi master registers |
| 7 | 8 | - interrupts : lpspi interrupt |
| 8 | 9 | - clocks : lpspi clock specifier |
| @@ -0,0 +1,24 @@ | ||
| 1 | +PXA2xx SSP SPI Controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: Must be "marvell,mmp2-ssp". | |
| 5 | +- reg: Offset and length of the device's register set. | |
| 6 | +- interrupts: Should be the interrupt number. | |
| 7 | +- clocks: Should contain a single entry describing the clock input. | |
| 8 | +- #address-cells: Number of cells required to define a chip select address. | |
| 9 | +- #size-cells: Should be zero. | |
| 10 | + | |
| 11 | +Optional properties: | |
| 12 | +- cs-gpios: list of GPIO chip selects. See the SPI bus bindings, | |
| 13 | + Documentation/devicetree/bindings/spi/spi-bus.txt | |
| 14 | + | |
| 15 | +Child nodes represent devices on the SPI bus | |
| 16 | + See ../spi/spi-bus.txt | |
| 17 | + | |
| 18 | +Example: | |
| 19 | + ssp1: spi@d4035000 { | |
| 20 | + compatible = "marvell,mmp2-ssp"; | |
| 21 | + reg = <0xd4035000 0x1000>; | |
| 22 | + clocks = <&soc_clocks MMP2_CLK_SSP0>; | |
| 23 | + interrupts = <0>; | |
| 24 | + }; | |
| @@ -3,7 +3,7 @@ Device tree configuration for Renesas RSPI/QSPI driver · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible : For Renesas Serial Peripheral Interface on legacy SH: |
| 5 | 5 | "renesas,rspi-<soctype>", "renesas,rspi" as fallback. |
| 6 | − For Renesas Serial Peripheral Interface on RZ/A1H: | |
| 6 | + For Renesas Serial Peripheral Interface on RZ/A: | |
| 7 | 7 | "renesas,rspi-<soctype>", "renesas,rspi-rz" as fallback. |
| 8 | 8 | For Quad Serial Peripheral Interface on R-Car Gen2 and |
| 9 | 9 | RZ/G1 devices: |
| @@ -11,7 +11,9 @@ Required properties: · 1 unmodified line | ||
| 11 | 11 | Examples with soctypes are: |
| 12 | 12 | - "renesas,rspi-sh7757" (SH) |
| 13 | 13 | - "renesas,rspi-r7s72100" (RZ/A1H) |
| 14 | + - "renesas,rspi-r7s9210" (RZ/A2) | |
| 14 | 15 | - "renesas,qspi-r8a7743" (RZ/G1M) |
| 16 | + - "renesas,qspi-r8a7744" (RZ/G1N) | |
| 15 | 17 | - "renesas,qspi-r8a7745" (RZ/G1E) |
| 16 | 18 | - "renesas,qspi-r8a7790" (R-Car H2) |
| 17 | 19 | - "renesas,qspi-r8a7791" (R-Car M2-W) |
| @@ -0,0 +1,32 @@ | ||
| 1 | +Binding for MTK SPI Slave controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be one of the following. | |
| 5 | + - mediatek,mt2712-spi-slave: for mt2712 platforms | |
| 6 | +- reg: Address and length of the register set for the device. | |
| 7 | +- interrupts: Should contain spi interrupt. | |
| 8 | +- clocks: phandles to input clocks. | |
| 9 | + It's clock gate, and should be <&infracfg CLK_INFRA_AO_SPI1>. | |
| 10 | +- clock-names: should be "spi" for the clock gate. | |
| 11 | + | |
| 12 | +Optional properties: | |
| 13 | +- assigned-clocks: it's mux clock, should be <&topckgen CLK_TOP_SPISLV_SEL>. | |
| 14 | +- assigned-clock-parents: parent of mux clock. | |
| 15 | + It's PLL, and should be one of the following. | |
| 16 | + - <&topckgen CLK_TOP_UNIVPLL1_D2>: specify parent clock 312MHZ. | |
| 17 | + It's the default one. | |
| 18 | + - <&topckgen CLK_TOP_UNIVPLL1_D4>: specify parent clock 156MHZ. | |
| 19 | + - <&topckgen CLK_TOP_UNIVPLL2_D4>: specify parent clock 104MHZ. | |
| 20 | + - <&topckgen CLK_TOP_UNIVPLL1_D8>: specify parent clock 78MHZ. | |
| 21 | + | |
| 22 | +Example: | |
| 23 | +- SoC Specific Portion: | |
| 24 | +spis1: spi@10013000 { | |
| 25 | + compatible = "mediatek,mt2712-spi-slave"; | |
| 26 | + reg = <0 0x10013000 0 0x100>; | |
| 27 | + interrupts = <GIC_SPI 283 IRQ_TYPE_LEVEL_LOW>; | |
| 28 | + clocks = <&infracfg CLK_INFRA_AO_SPI1>; | |
| 29 | + clock-names = "spi"; | |
| 30 | + assigned-clocks = <&topckgen CLK_TOP_SPISLV_SEL>; | |
| 31 | + assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL1_D2>; | |
| 32 | +}; | |
| @@ -0,0 +1,26 @@ | ||
| 1 | +Spreadtrum SPI Controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: Should be "sprd,sc9860-spi". | |
| 5 | +- reg: Offset and length of SPI controller register space. | |
| 6 | +- interrupts: Should contain SPI interrupt. | |
| 7 | +- clock-names: Should contain following entries: | |
| 8 | + "spi" for SPI clock, | |
| 9 | + "source" for SPI source (parent) clock, | |
| 10 | + "enable" for SPI module enable clock. | |
| 11 | +- clocks: List of clock input name strings sorted in the same order | |
| 12 | + as the clock-names property. | |
| 13 | +- #address-cells: The number of cells required to define a chip select | |
| 14 | + address on the SPI bus. Should be set to 1. | |
| 15 | +- #size-cells: Should be set to 0. | |
| 16 | + | |
| 17 | +Example: | |
| 18 | +spi0: spi@70a00000{ | |
| 19 | + compatible = "sprd,sc9860-spi"; | |
| 20 | + reg = <0 0x70a00000 0 0x1000>; | |
| 21 | + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; | |
| 22 | + clock-names = "spi", "source","enable"; | |
| 23 | + clocks = <&clk_spi0>, <&ext_26m>, <&clk_ap_apb_gates 5>; | |
| 24 | + #address-cells = <1>; | |
| 25 | + #size-cells = <0>; | |
| 26 | +}; | |
| @@ -0,0 +1,44 @@ | ||
| 1 | +* STMicroelectronics Quad Serial Peripheral Interface(QSPI) | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be "st,stm32f469-qspi" | |
| 5 | +- reg: the first contains the register location and length. | |
| 6 | + the second contains the memory mapping address and length | |
| 7 | +- reg-names: should contain the reg names "qspi" "qspi_mm" | |
| 8 | +- interrupts: should contain the interrupt for the device | |
| 9 | +- clocks: the phandle of the clock needed by the QSPI controller | |
| 10 | +- A pinctrl must be defined to set pins in mode of operation for QSPI transfer | |
| 11 | + | |
| 12 | +Optional properties: | |
| 13 | +- resets: must contain the phandle to the reset controller. | |
| 14 | + | |
| 15 | +A spi flash (NOR/NAND) must be a child of spi node and could have some | |
| 16 | +properties. Also see jedec,spi-nor.txt. | |
| 17 | + | |
| 18 | +Required properties: | |
| 19 | +- reg: chip-Select number (QSPI controller may connect 2 flashes) | |
| 20 | +- spi-max-frequency: max frequency of spi bus | |
| 21 | + | |
| 22 | +Optional property: | |
| 23 | +- spi-rx-bus-width: see ./spi-bus.txt for the description | |
| 24 | + | |
| 25 | +Example: | |
| 26 | + | |
| 27 | +qspi: spi@a0001000 { | |
| 28 | + compatible = "st,stm32f469-qspi"; | |
| 29 | + reg = <0xa0001000 0x1000>, <0x90000000 0x10000000>; | |
| 30 | + reg-names = "qspi", "qspi_mm"; | |
| 31 | + interrupts = <91>; | |
| 32 | + resets = <&rcc STM32F4_AHB3_RESET(QSPI)>; | |
| 33 | + clocks = <&rcc 0 STM32F4_AHB3_CLOCK(QSPI)>; | |
| 34 | + pinctrl-names = "default"; | |
| 35 | + pinctrl-0 = <&pinctrl_qspi0>; | |
| 36 | + | |
| 37 | + flash@0 { | |
| 38 | + compatible = "jedec,spi-nor"; | |
| 39 | + reg = <0>; | |
| 40 | + spi-rx-bus-width = <4>; | |
| 41 | + spi-max-frequency = <108000000>; | |
| 42 | + ... | |
| 43 | + }; | |
| 44 | +}; | |
| @@ -18,6 +18,7 @@ Required properties: · 17 unmodified lines | ||
| 18 | 18 | - "allwinner,sun8i-h3-system-control" |
| 19 | 19 | - "allwinner,sun50i-a64-sram-controller" (deprecated) |
| 20 | 20 | - "allwinner,sun50i-a64-system-control" |
| 21 | + - "allwinner,sun50i-h6-system-control", "allwinner,sun50i-a64-system-control" | |
| 21 | 22 | - reg : sram controller register offset + length |
| 22 | 23 | |
| 23 | 24 | SRAM nodes |
| @@ -54,6 +55,9 @@ The valid sections compatible for H3 are: · 30 unmodified lines | ||
| 54 | 55 | The valid sections compatible for A64 are: |
| 55 | 56 | - allwinner,sun50i-a64-sram-c |
| 56 | 57 | |
| 58 | +The valid sections compatible for H6 are: | |
| 59 | + - allwinner,sun50i-h6-sram-c, allwinner,sun50i-a64-sram-c | |
| 60 | + | |
| 57 | 61 | Devices using SRAM sections |
| 58 | 62 | --------------------------- |
| 59 | 63 | |
| @@ -6,8 +6,7 @@ interrupt signal and status register to identify high PMIC die temperature. · 5 unmodified lines | ||
| 6 | 6 | |
| 7 | 7 | Required properties: |
| 8 | 8 | - compatible: Should contain "qcom,spmi-temp-alarm". |
| 9 | −- reg: Specifies the SPMI address and length of the controller's | |
| 10 | − registers. | |
| 9 | +- reg: Specifies the SPMI address. | |
| 11 | 10 | - interrupts: PMIC temperature alarm interrupt. |
| 12 | 11 | - #thermal-sensor-cells: Should be 0. See thermal.txt for a description. |
| 13 | 12 | |
| @@ -20,7 +19,7 @@ Example: · 6 unmodified lines | ||
| 20 | 19 | |
| 21 | 20 | pm8941_temp: thermal-alarm@2400 { |
| 22 | 21 | compatible = "qcom,spmi-temp-alarm"; |
| 23 | − reg = <0x2400 0x100>; | |
| 22 | + reg = <0x2400>; | |
| 24 | 23 | interrupts = <0 0x24 0 IRQ_TYPE_EDGE_RISING>; |
| 25 | 24 | #thermal-sensor-cells = <0>; |
| 26 | 25 | |
| @@ -36,19 +35,14 @@ Example: · 9 unmodified lines | ||
| 36 | 35 | thermal-sensors = <&pm8941_temp>; |
| 37 | 36 | |
| 38 | 37 | trips { |
| 39 | − passive { | |
| 40 | − temperature = <1050000>; | |
| 38 | + stage1 { | |
| 39 | + temperature = <105000>; | |
| 41 | 40 | hysteresis = <2000>; |
| 42 | 41 | type = "passive"; |
| 43 | 42 | }; |
| 44 | − alert { | |
| 43 | + stage2 { | |
| 45 | 44 | temperature = <125000>; |
| 46 | 45 | hysteresis = <2000>; |
| 47 | − type = "hot"; | |
| 48 | − }; | |
| 49 | − crit { | |
| 50 | − temperature = <145000>; | |
| 51 | − hysteresis = <2000>; | |
| 52 | 46 | type = "critical"; |
| 53 | 47 | }; |
| 54 | 48 | }; |
| @@ -1,9 +1,9 @@ | ||
| 1 | 1 | * Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs |
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | −- compatible : Must include "fsl,qoriq-tmu". The version of the device is | |
| 5 | − determined by the TMU IP Block Revision Register (IPBRR0) at | |
| 6 | − offset 0x0BF8. | |
| 4 | +- compatible : Must include "fsl,qoriq-tmu" or "fsl,imx8mq-tmu". The | |
| 5 | + version of the device is determined by the TMU IP Block Revision | |
| 6 | + Register (IPBRR0) at offset 0x0BF8. | |
| 7 | 7 | Table of correspondences between IPBRR0 values and example chips: |
| 8 | 8 | Value Device |
| 9 | 9 | ---------- ----- |
| @@ -7,9 +7,11 @@ inside the LSI. · 6 unmodified lines | ||
| 7 | 7 | Required properties: |
| 8 | 8 | - compatible : "renesas,<soctype>-thermal", |
| 9 | 9 | Examples with soctypes are: |
| 10 | + - "renesas,r8a774a1-thermal" (RZ/G2M) | |
| 10 | 11 | - "renesas,r8a7795-thermal" (R-Car H3) |
| 11 | 12 | - "renesas,r8a7796-thermal" (R-Car M3-W) |
| 12 | 13 | - "renesas,r8a77965-thermal" (R-Car M3-N) |
| 14 | + - "renesas,r8a77980-thermal" (R-Car V3H) | |
| 13 | 15 | - reg : Address ranges of the thermal registers. Each sensor |
| 14 | 16 | needs one address range. Sorting must be done in |
| 15 | 17 | increasing order according to datasheet, i.e. |
| @@ -19,7 +21,8 @@ Required properties: · 3 unmodified lines | ||
| 19 | 21 | |
| 20 | 22 | Optional properties: |
| 21 | 23 | |
| 22 | −- interrupts : interrupts routed to the TSC (3 for H3, M3-W and M3-N) | |
| 24 | +- interrupts : interrupts routed to the TSC (3 for H3, M3-W, M3-N, | |
| 25 | + and V3H) | |
| 23 | 26 | - power-domain : Must contain a reference to the power domain. This |
| 24 | 27 | property is mandatory if the thermal sensor instance |
| 25 | 28 | is part of a controllable power domain. |
| @@ -4,15 +4,17 @@ Required properties: · 3 unmodified lines | ||
| 4 | 4 | - compatible : "renesas,thermal-<soctype>", |
| 5 | 5 | "renesas,rcar-gen2-thermal" (with thermal-zone) or |
| 6 | 6 | "renesas,rcar-thermal" (without thermal-zone) as |
| 7 | − fallback except R-Car D3. | |
| 7 | + fallback except R-Car V3M/D3. | |
| 8 | 8 | Examples with soctypes are: |
| 9 | 9 | - "renesas,thermal-r8a73a4" (R-Mobile APE6) |
| 10 | 10 | - "renesas,thermal-r8a7743" (RZ/G1M) |
| 11 | + - "renesas,thermal-r8a7744" (RZ/G1N) | |
| 11 | 12 | - "renesas,thermal-r8a7779" (R-Car H1) |
| 12 | 13 | - "renesas,thermal-r8a7790" (R-Car H2) |
| 13 | 14 | - "renesas,thermal-r8a7791" (R-Car M2-W) |
| 14 | 15 | - "renesas,thermal-r8a7792" (R-Car V2H) |
| 15 | 16 | - "renesas,thermal-r8a7793" (R-Car M2-N) |
| 17 | + - "renesas,thermal-r8a77970" (R-Car V3M) | |
| 16 | 18 | - "renesas,thermal-r8a77995" (R-Car D3) |
| 17 | 19 | - reg : Address range of the thermal registers. |
| 18 | 20 | The 1st reg will be recognized as common register |
| @@ -21,7 +23,7 @@ Required properties: · 2 unmodified lines | ||
| 21 | 23 | Option properties: |
| 22 | 24 | |
| 23 | 25 | - interrupts : If present should contain 3 interrupts for |
| 24 | − R-Car D3 or 1 interrupt otherwise. | |
| 26 | + R-Car V3M/D3 or 1 interrupt otherwise. | |
| 25 | 27 | |
| 26 | 28 | Example (non interrupt support): |
| 27 | 29 | |
| @@ -0,0 +1,61 @@ | ||
| 1 | +Binding for Thermal Sensor for STMicroelectronics STM32 series of SoCs. | |
| 2 | + | |
| 3 | +On STM32 SoCs, the Digital Temperature Sensor (DTS) is in charge of managing an | |
| 4 | +analog block which delivers a frequency depending on the internal SoC's | |
| 5 | +temperature. By using a reference frequency, DTS is able to provide a sample | |
| 6 | +number which can be translated into a temperature by the user. | |
| 7 | + | |
| 8 | +DTS provides interrupt notification mechanism by threshold. This mechanism | |
| 9 | +offers two temperature trip points: passive and critical. The first is intended | |
| 10 | +for passive cooling notification while the second is used for over-temperature | |
| 11 | +reset. | |
| 12 | + | |
| 13 | +Required parameters: | |
| 14 | +------------------- | |
| 15 | + | |
| 16 | +compatible: Should be "st,stm32-thermal" | |
| 17 | +reg: This should be the physical base address and length of the | |
| 18 | + sensor's registers. | |
| 19 | +clocks: Phandle of the clock used by the thermal sensor. | |
| 20 | + See: Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 21 | +clock-names: Should be "pclk" for register access clock and reference clock. | |
| 22 | + See: Documentation/devicetree/bindings/resource-names.txt | |
| 23 | +#thermal-sensor-cells: Should be 0. See ./thermal.txt for a description. | |
| 24 | +interrupts: Standard way to define interrupt number. | |
| 25 | + | |
| 26 | +Example: | |
| 27 | + | |
| 28 | + thermal-zones { | |
| 29 | + cpu_thermal: cpu-thermal { | |
| 30 | + polling-delay-passive = <0>; | |
| 31 | + polling-delay = <0>; | |
| 32 | + | |
| 33 | + thermal-sensors = <&thermal>; | |
| 34 | + | |
| 35 | + trips { | |
| 36 | + cpu_alert1: cpu-alert1 { | |
| 37 | + temperature = <85000>; | |
| 38 | + hysteresis = <0>; | |
| 39 | + type = "passive"; | |
| 40 | + }; | |
| 41 | + | |
| 42 | + cpu-crit: cpu-crit { | |
| 43 | + temperature = <120000>; | |
| 44 | + hysteresis = <0>; | |
| 45 | + type = "critical"; | |
| 46 | + }; | |
| 47 | + }; | |
| 48 | + | |
| 49 | + cooling-maps { | |
| 50 | + }; | |
| 51 | + }; | |
| 52 | + }; | |
| 53 | + | |
| 54 | + thermal: thermal@50028000 { | |
| 55 | + compatible = "st,stm32-thermal"; | |
| 56 | + reg = <0x50028000 0x100>; | |
| 57 | + clocks = <&rcc TMPSENS>; | |
| 58 | + clock-names = "pclk"; | |
| 59 | + #thermal-sensor-cells = <0>; | |
| 60 | + interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>; | |
| 61 | + }; | |
| @@ -152,7 +152,7 @@ Optional property: · 151 unmodified lines | ||
| 152 | 152 | Elem size: one cell the sensors listed in the thermal-sensors property. |
| 153 | 153 | Elem type: signed Coefficients defaults to 1, in case this property |
| 154 | 154 | is not specified. A simple linear polynomial is used: |
| 155 | − Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn. | |
| 155 | + Z = c0 * x0 + c1 * x1 + ... + c(n-1) * x(n-1) + cn. | |
| 156 | 156 | |
| 157 | 157 | The coefficients are ordered and they match with sensors |
| 158 | 158 | by means of sensor ID. Additional coefficients are |
| @@ -0,0 +1,42 @@ | ||
| 1 | +================= | |
| 2 | +gx6605s SOC Timer | |
| 3 | +================= | |
| 4 | + | |
| 5 | +The timer is used in gx6605s soc as system timer and the driver | |
| 6 | +contain clk event and clk source. | |
| 7 | + | |
| 8 | +============================== | |
| 9 | +timer node bindings definition | |
| 10 | +============================== | |
| 11 | + | |
| 12 | + Description: Describes gx6605s SOC timer | |
| 13 | + | |
| 14 | + PROPERTIES | |
| 15 | + | |
| 16 | + - compatible | |
| 17 | + Usage: required | |
| 18 | + Value type: <string> | |
| 19 | + Definition: must be "csky,gx6605s-timer" | |
| 20 | + - reg | |
| 21 | + Usage: required | |
| 22 | + Value type: <u32 u32> | |
| 23 | + Definition: <phyaddr size> in soc from cpu view | |
| 24 | + - clocks | |
| 25 | + Usage: required | |
| 26 | + Value type: phandle + clock specifier cells | |
| 27 | + Definition: must be input clk node | |
| 28 | + - interrupt | |
| 29 | + Usage: required | |
| 30 | + Value type: <u32> | |
| 31 | + Definition: must be timer irq num defined by soc | |
| 32 | + | |
| 33 | +Examples: | |
| 34 | +--------- | |
| 35 | + | |
| 36 | + timer0: timer@20a000 { | |
| 37 | + compatible = "csky,gx6605s-timer"; | |
| 38 | + reg = <0x0020a000 0x400>; | |
| 39 | + clocks = <&dummy_apb_clk>; | |
| 40 | + interrupts = <10>; | |
| 41 | + interrupt-parent = <&intc>; | |
| 42 | + }; | |
| @@ -0,0 +1,42 @@ | ||
| 1 | +============================ | |
| 2 | +C-SKY Multi-processors Timer | |
| 3 | +============================ | |
| 4 | + | |
| 5 | +C-SKY multi-processors timer is designed for C-SKY SMP system and the | |
| 6 | +regs is accessed by cpu co-processor 4 registers with mtcr/mfcr. | |
| 7 | + | |
| 8 | + - PTIM_CTLR "cr<0, 14>" Control reg to start reset timer. | |
| 9 | + - PTIM_TSR "cr<1, 14>" Interrupt cleanup status reg. | |
| 10 | + - PTIM_CCVR "cr<3, 14>" Current counter value reg. | |
| 11 | + - PTIM_LVR "cr<6, 14>" Window value reg to triger next event. | |
| 12 | + | |
| 13 | +============================== | |
| 14 | +timer node bindings definition | |
| 15 | +============================== | |
| 16 | + | |
| 17 | + Description: Describes SMP timer | |
| 18 | + | |
| 19 | + PROPERTIES | |
| 20 | + | |
| 21 | + - compatible | |
| 22 | + Usage: required | |
| 23 | + Value type: <string> | |
| 24 | + Definition: must be "csky,mptimer" | |
| 25 | + - clocks | |
| 26 | + Usage: required | |
| 27 | + Value type: <node> | |
| 28 | + Definition: must be input clk node | |
| 29 | + - interrupts | |
| 30 | + Usage: required | |
| 31 | + Value type: <u32> | |
| 32 | + Definition: must be timer irq num defined by soc | |
| 33 | + | |
| 34 | +Examples: | |
| 35 | +--------- | |
| 36 | + | |
| 37 | + timer: timer { | |
| 38 | + compatible = "csky,mptimer"; | |
| 39 | + clocks = <&dummy_apb_clk>; | |
| 40 | + interrupts = <16>; | |
| 41 | + interrupt-parent = <&intc>; | |
| 42 | + }; | |
| @@ -24,6 +24,8 @@ Required Properties: · 23 unmodified lines | ||
| 24 | 24 | - "renesas,r8a73a4-cmt1" for the 48-bit CMT1 device included in r8a73a4. |
| 25 | 25 | - "renesas,r8a7743-cmt0" for the 32-bit CMT0 device included in r8a7743. |
| 26 | 26 | - "renesas,r8a7743-cmt1" for the 48-bit CMT1 device included in r8a7743. |
| 27 | + - "renesas,r8a7744-cmt0" for the 32-bit CMT0 device included in r8a7744. | |
| 28 | + - "renesas,r8a7744-cmt1" for the 48-bit CMT1 device included in r8a7744. | |
| 27 | 29 | - "renesas,r8a7745-cmt0" for the 32-bit CMT0 device included in r8a7745. |
| 28 | 30 | - "renesas,r8a7745-cmt1" for the 48-bit CMT1 device included in r8a7745. |
| 29 | 31 | - "renesas,r8a7790-cmt0" for the 32-bit CMT0 device included in r8a7790. |
| @@ -34,6 +36,10 @@ Required Properties: · 4 unmodified lines | ||
| 34 | 36 | - "renesas,r8a7793-cmt1" for the 48-bit CMT1 device included in r8a7793. |
| 35 | 37 | - "renesas,r8a7794-cmt0" for the 32-bit CMT0 device included in r8a7794. |
| 36 | 38 | - "renesas,r8a7794-cmt1" for the 48-bit CMT1 device included in r8a7794. |
| 39 | + - "renesas,r8a77970-cmt0" for the 32-bit CMT0 device included in r8a77970. | |
| 40 | + - "renesas,r8a77970-cmt1" for the 48-bit CMT1 device included in r8a77970. | |
| 41 | + - "renesas,r8a77980-cmt0" for the 32-bit CMT0 device included in r8a77980. | |
| 42 | + - "renesas,r8a77980-cmt1" for the 48-bit CMT1 device included in r8a77980. | |
| 37 | 43 | |
| 38 | 44 | - "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car Gen2 |
| 39 | 45 | and RZ/G1. |
| @@ -41,6 +47,9 @@ Required Properties: · 1 unmodified line | ||
| 41 | 47 | and RZ/G1. |
| 42 | 48 | These are fallbacks for r8a73a4, R-Car Gen2 and RZ/G1 entries |
| 43 | 49 | listed above. |
| 50 | + - "renesas,rcar-gen3-cmt0" for 32-bit CMT0 devices included in R-Car Gen3. | |
| 51 | + - "renesas,rcar-gen3-cmt1" for 48-bit CMT1 devices included in R-Car Gen3. | |
| 52 | + These are fallbacks for R-Car Gen3 entries listed above. | |
| 44 | 53 | |
| 45 | 54 | - reg: base address and length of the registers block for the timer module. |
| 46 | 55 | - interrupts: interrupt-specifier for the timer, one per channel. |
| @@ -9,7 +9,8 @@ Channels are independent from each other. · 8 unmodified lines | ||
| 9 | 9 | Required Properties: |
| 10 | 10 | |
| 11 | 11 | - compatible: must be one or more of the following: |
| 12 | − - "renesas,r7s72100-ostm" for the r7s72100 OSTM | |
| 12 | + - "renesas,r7s72100-ostm" for the R7S72100 (RZ/A1) OSTM | |
| 13 | + - "renesas,r7s9210-ostm" for the R7S9210 (RZ/A2) OSTM | |
| 13 | 14 | - "renesas,ostm" for any OSTM |
| 14 | 15 | This is a fallback for the above renesas,*-ostm entries |
| 15 | 16 | |
| @@ -12,6 +12,8 @@ Required Properties: · 11 unmodified lines | ||
| 12 | 12 | - "renesas,tmu-r8a7740" for the r8a7740 TMU |
| 13 | 13 | - "renesas,tmu-r8a7778" for the r8a7778 TMU |
| 14 | 14 | - "renesas,tmu-r8a7779" for the r8a7779 TMU |
| 15 | + - "renesas,tmu-r8a77970" for the r8a77970 TMU | |
| 16 | + - "renesas,tmu-r8a77980" for the r8a77980 TMU | |
| 15 | 17 | - "renesas,tmu" for any TMU. |
| 16 | 18 | This is a fallback for the above renesas,tmu-* entries |
| 17 | 19 | |
| @@ -21,21 +21,10 @@ adi,adt7490 +/-1C TDM Extended Temp Range I.C · 20 unmodified lines | ||
| 21 | 21 | adi,adxl345 Three-Axis Digital Accelerometer |
| 22 | 22 | adi,adxl346 Three-Axis Digital Accelerometer (backward-compatibility value "adi,adxl345" must be listed too) |
| 23 | 23 | ams,iaq-core AMS iAQ-Core VOC Sensor |
| 24 | −amstaos,tsl2571 AMS/TAOS ALS and proximity sensor | |
| 25 | −amstaos,tsl2671 AMS/TAOS ALS and proximity sensor | |
| 26 | −amstaos,tmd2671 AMS/TAOS ALS and proximity sensor | |
| 27 | −amstaos,tsl2771 AMS/TAOS ALS and proximity sensor | |
| 28 | −amstaos,tmd2771 AMS/TAOS ALS and proximity sensor | |
| 29 | −amstaos,tsl2572 AMS/TAOS ALS and proximity sensor | |
| 30 | −amstaos,tsl2672 AMS/TAOS ALS and proximity sensor | |
| 31 | −amstaos,tmd2672 AMS/TAOS ALS and proximity sensor | |
| 32 | −amstaos,tsl2772 AMS/TAOS ALS and proximity sensor | |
| 33 | −amstaos,tmd2772 AMS/TAOS ALS and proximity sensor | |
| 34 | 24 | at,24c08 i2c serial eeprom (24cxx) |
| 35 | 25 | atmel,at97sc3204t i2c trusted platform module (TPM) |
| 36 | 26 | capella,cm32181 CM32181: Ambient Light Sensor |
| 37 | 27 | capella,cm3232 CM3232: Ambient Light Sensor |
| 38 | −cirrus,cs42l51 Cirrus Logic CS42L51 audio codec | |
| 39 | 28 | dallas,ds1374 I2C, 32-Bit Binary Counter Watchdog RTC with Trickle Charger and Reset Input/Output |
| 40 | 29 | dallas,ds1631 High-Precision Digital Thermometer |
| 41 | 30 | dallas,ds1672 Dallas DS1672 Real-time Clock |
| @@ -80,6 +80,8 @@ Optional properties: · 79 unmodified lines | ||
| 80 | 80 | controller. It's expected that a mux state of 0 indicates device mode and a |
| 81 | 81 | mux state of 1 indicates host mode. |
| 82 | 82 | - mux-control-names: Shall be "usb_switch" if mux-controls is specified. |
| 83 | +- pinctrl-names: Names for optional pin modes in "default", "host", "device" | |
| 84 | +- pinctrl-n: alternate pin modes | |
| 83 | 85 | |
| 84 | 86 | i.mx specific properties |
| 85 | 87 | - fsl,usbmisc: phandler of non-core register device, with one |
| @@ -6,6 +6,7 @@ Required properties: · 5 unmodified lines | ||
| 6 | 6 | - brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC. |
| 7 | 7 | - hisilicon,hi6220-usb: The DWC2 USB controller instance in the hi6220 SoC. |
| 8 | 8 | - rockchip,rk3066-usb: The DWC2 USB controller instance in the rk3066 Soc; |
| 9 | + - "rockchip,px30-usb", "rockchip,rk3066-usb", "snps,dwc2": for px30 Soc; | |
| 9 | 10 | - "rockchip,rk3188-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3188 Soc; |
| 10 | 11 | - "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 Soc; |
| 11 | 12 | - "lantiq,arx100-usb": The DWC2 USB controller instance in Lantiq ARX SoCs; |
| @@ -19,6 +19,7 @@ Exception for clocks: · 18 unmodified lines | ||
| 19 | 19 | "cavium,octeon-7130-usb-uctl" |
| 20 | 20 | "qcom,dwc3" |
| 21 | 21 | "samsung,exynos5250-dwusb3" |
| 22 | + "samsung,exynos5433-dwusb3" | |
| 22 | 23 | "samsung,exynos7-dwusb3" |
| 23 | 24 | "sprd,sc9860-dwc3" |
| 24 | 25 | "st,stih407-dwc3" |
| @@ -0,0 +1,23 @@ | ||
| 1 | +* Marvell PXA/MMP EHCI controller. | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | +- compatible: must be "marvell,pxau2o-ehci" | |
| 6 | +- reg: physical base addresses of the controller and length of memory mapped region | |
| 7 | +- interrupts: one EHCI controller interrupt should be described here | |
| 8 | +- clocks: phandle list of usb clocks | |
| 9 | +- clock-names: should be "USBCLK" | |
| 10 | +- phys: phandle for the PHY device | |
| 11 | +- phy-names: should be "usb" | |
| 12 | + | |
| 13 | +Example: | |
| 14 | + | |
| 15 | + ehci0: usb-ehci@d4208000 { | |
| 16 | + compatible = "marvell,pxau2o-ehci"; | |
| 17 | + reg = <0xd4208000 0x200>; | |
| 18 | + interrupts = <44>; | |
| 19 | + clocks = <&soc_clocks MMP2_CLK_USB>; | |
| 20 | + clock-names = "USBCLK"; | |
| 21 | + phys = <&usb_otg_phy>; | |
| 22 | + phy-names = "usb"; | |
| 23 | + }; | |
| @@ -83,6 +83,8 @@ Required properties: · 82 unmodified lines | ||
| 83 | 83 | - compatible: should be one of the following - |
| 84 | 84 | "samsung,exynos5250-dwusb3": for USB 3.0 DWC3 controller on |
| 85 | 85 | Exynos5250/5420. |
| 86 | + "samsung,exynos5433-dwusb3": for USB 3.0 DWC3 controller on | |
| 87 | + Exynos5433. | |
| 86 | 88 | "samsung,exynos7-dwusb3": for USB 3.0 DWC3 controller on Exynos7. |
| 87 | 89 | - #address-cells, #size-cells : should be '1' if the device has sub-nodes |
| 88 | 90 | with 'reg' property. |
| @@ -0,0 +1,35 @@ | ||
| 1 | +Faraday FOTG Host controller | |
| 2 | + | |
| 3 | +This OTG-capable USB host controller is found in Cortina Systems | |
| 4 | +Gemini and other SoC products. | |
| 5 | + | |
| 6 | +Required properties: | |
| 7 | +- compatible: should be one of: | |
| 8 | + "faraday,fotg210" | |
| 9 | + "cortina,gemini-usb", "faraday,fotg210" | |
| 10 | +- reg: should contain one register range i.e. start and length | |
| 11 | +- interrupts: description of the interrupt line | |
| 12 | + | |
| 13 | +Optional properties: | |
| 14 | +- clocks: should contain the IP block clock | |
| 15 | +- clock-names: should be "PCLK" for the IP block clock | |
| 16 | + | |
| 17 | +Required properties for "cortina,gemini-usb" compatible: | |
| 18 | +- syscon: a phandle to the system controller to access PHY registers | |
| 19 | + | |
| 20 | +Optional properties for "cortina,gemini-usb" compatible: | |
| 21 | +- cortina,gemini-mini-b: boolean property that indicates that a Mini-B | |
| 22 | + OTG connector is in use | |
| 23 | +- wakeup-source: see power/wakeup-source.txt | |
| 24 | + | |
| 25 | +Example for Gemini: | |
| 26 | + | |
| 27 | +usb@68000000 { | |
| 28 | + compatible = "cortina,gemini-usb", "faraday,fotg210"; | |
| 29 | + reg = <0x68000000 0x1000>; | |
| 30 | + interrupts = <10 IRQ_TYPE_LEVEL_HIGH>; | |
| 31 | + clocks = <&cc 12>; | |
| 32 | + clock-names = "PCLK"; | |
| 33 | + syscon = <&syscon>; | |
| 34 | + wakeup-source; | |
| 35 | +}; | |
| @@ -5,10 +5,19 @@ Required properties : · 4 unmodified lines | ||
| 5 | 5 | - reg : I2C slave address |
| 6 | 6 | - interrupts : Interrupt specifier |
| 7 | 7 | |
| 8 | −Optional properties : | |
| 9 | −- fcs,operating-sink-microwatt : | |
| 10 | − Minimum amount of power accepted from a sink | |
| 11 | − when negotiating | |
| 8 | +Required sub-node: | |
| 9 | +- connector : The "usb-c-connector" attached to the FUSB302 IC. The bindings | |
| 10 | + of the connector node are specified in: | |
| 11 | + | |
| 12 | + Documentation/devicetree/bindings/connector/usb-connector.txt | |
| 13 | + | |
| 14 | +Deprecated properties : | |
| 15 | +- fcs,max-sink-microvolt : Maximum sink voltage accepted by port controller | |
| 16 | +- fcs,max-sink-microamp : Maximum sink current accepted by port controller | |
| 17 | +- fcs,max-sink-microwatt : Maximum sink power accepted by port controller | |
| 18 | +- fcs,operating-sink-microwatt : Minimum amount of power accepted from a sink | |
| 19 | + when negotiating | |
| 20 | + | |
| 12 | 21 | |
| 13 | 22 | Example: |
| 14 | 23 | |
| @@ -17,7 +26,16 @@ fusb302: typec-portc@54 { · 2 unmodified lines | ||
| 17 | 26 | reg = <0x54>; |
| 18 | 27 | interrupt-parent = <&nmi_intc>; |
| 19 | 28 | interrupts = <0 IRQ_TYPE_LEVEL_LOW>; |
| 20 | − fcs,max-sink-microvolt = <12000000>; | |
| 21 | − fcs,max-sink-microamp = <3000000>; | |
| 22 | − fcs,max-sink-microwatt = <36000000>; | |
| 29 | + | |
| 30 | + usb_con: connector { | |
| 31 | + compatible = "usb-c-connector"; | |
| 32 | + label = "USB-C"; | |
| 33 | + power-role = "dual"; | |
| 34 | + try-power-role = "sink"; | |
| 35 | + source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>; | |
| 36 | + sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM) | |
| 37 | + PDO_VAR(3000, 12000, 3000) | |
| 38 | + PDO_PPS_APDO(3000, 11000, 3000)>; | |
| 39 | + op-sink-microwatt = <10000000>; | |
| 40 | + }; | |
| 23 | 41 | }; |
| @@ -2,11 +2,13 @@ Renesas Electronics USB3.0 Peripheral driver · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible: Must contain one of the following: |
| 5 | + - "renesas,r8a774a1-usb3-peri" | |
| 5 | 6 | - "renesas,r8a7795-usb3-peri" |
| 6 | 7 | - "renesas,r8a7796-usb3-peri" |
| 7 | 8 | - "renesas,r8a77965-usb3-peri" |
| 8 | − - "renesas,rcar-gen3-usb3-peri" for a generic R-Car Gen3 compatible | |
| 9 | − device | |
| 9 | + - "renesas,r8a77990-usb3-peri" | |
| 10 | + - "renesas,rcar-gen3-usb3-peri" for a generic R-Car Gen3 or RZ/G2 | |
| 11 | + compatible device | |
| 10 | 12 | |
| 11 | 13 | When compatible with the generic version, nodes must list the |
| 12 | 14 | SoC-specific version corresponding to the platform first |
| @@ -4,7 +4,9 @@ Required properties: · 3 unmodified lines | ||
| 4 | 4 | - compatible: Must contain one or more of the following: |
| 5 | 5 | |
| 6 | 6 | - "renesas,usbhs-r8a7743" for r8a7743 (RZ/G1M) compatible device |
| 7 | + - "renesas,usbhs-r8a7744" for r8a7744 (RZ/G1N) compatible device | |
| 7 | 8 | - "renesas,usbhs-r8a7745" for r8a7745 (RZ/G1E) compatible device |
| 9 | + - "renesas,usbhs-r8a774a1" for r8a774a1 (RZ/G2M) compatible device | |
| 8 | 10 | - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device |
| 9 | 11 | - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device |
| 10 | 12 | - "renesas,usbhs-r8a7792" for r8a7792 (R-Car V2H) compatible device |
| @@ -13,10 +15,11 @@ Required properties: · 2 unmodified lines | ||
| 13 | 15 | - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device |
| 14 | 16 | - "renesas,usbhs-r8a7796" for r8a7796 (R-Car M3-W) compatible device |
| 15 | 17 | - "renesas,usbhs-r8a77965" for r8a77965 (R-Car M3-N) compatible device |
| 18 | + - "renesas,usbhs-r8a77990" for r8a77990 (R-Car E3) compatible device | |
| 16 | 19 | - "renesas,usbhs-r8a77995" for r8a77995 (R-Car D3) compatible device |
| 17 | 20 | - "renesas,usbhs-r7s72100" for r7s72100 (RZ/A1) compatible device |
| 18 | 21 | - "renesas,rcar-gen2-usbhs" for R-Car Gen2 or RZ/G1 compatible devices |
| 19 | − - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device | |
| 22 | + - "renesas,rcar-gen3-usbhs" for R-Car Gen3 or RZ/G2 compatible devices | |
| 20 | 23 | - "renesas,rza1-usbhs" for RZ/A1 compatible device |
| 21 | 24 | |
| 22 | 25 | When compatible with the generic version, nodes must list the |
| @@ -25,7 +28,11 @@ Required properties: · 2 unmodified lines | ||
| 25 | 28 | |
| 26 | 29 | - reg: Base address and length of the register for the USBHS |
| 27 | 30 | - interrupts: Interrupt specifier for the USBHS |
| 28 | − - clocks: A list of phandle + clock specifier pairs | |
| 31 | + - clocks: A list of phandle + clock specifier pairs. | |
| 32 | + - In case of "renesas,rcar-gen3-usbhs", two clocks are required. | |
| 33 | + First clock should be peripheral and second one should be host. | |
| 34 | + - In case of except above, one clock is required. First clock | |
| 35 | + should be peripheral. | |
| 29 | 36 | |
| 30 | 37 | Optional properties: |
| 31 | 38 | - renesas,buswait: Integer to use BUSWAIT register |
| @@ -15,7 +15,11 @@ Optional properties: · 14 unmodified lines | ||
| 15 | 15 | - needs-reset-on-resume : boolean, set this to force EHCI reset after resume |
| 16 | 16 | - has-transaction-translator : boolean, set this if EHCI have a Transaction |
| 17 | 17 | Translator built into the root hub. |
| 18 | − - clocks : a list of phandle + clock specifier pairs | |
| 18 | + - clocks : a list of phandle + clock specifier pairs. In case of Renesas | |
| 19 | + R-Car Gen3 SoCs: | |
| 20 | + - if a host only channel: first clock should be host. | |
| 21 | + - if a USB DRD channel: first clock should be host and second one | |
| 22 | + should be peripheral. | |
| 19 | 23 | - phys : see usb-hcd.txt in the current directory |
| 20 | 24 | - resets : phandle + reset specifier pair |
| 21 | 25 | |
| @@ -12,7 +12,11 @@ Optional properties: · 11 unmodified lines | ||
| 12 | 12 | - no-big-frame-no : boolean, set if frame_no lives in bits [15:0] of HCCA |
| 13 | 13 | - remote-wakeup-connected: remote wakeup is wired on the platform |
| 14 | 14 | - num-ports : u32, to override the detected port count |
| 15 | −- clocks : a list of phandle + clock specifier pairs | |
| 15 | +- clocks : a list of phandle + clock specifier pairs. In case of Renesas | |
| 16 | + R-Car Gen3 SoCs: | |
| 17 | + - if a host only channel: first clock should be host. | |
| 18 | + - if a USB DRD channel: first clock should be host and second one | |
| 19 | + should be peripheral. | |
| 16 | 20 | - phys : see usb-hcd.txt in the current directory |
| 17 | 21 | - resets : a list of phandle + reset specifier pairs |
| 18 | 22 | |
| @@ -8,6 +8,8 @@ Required properties: · 7 unmodified lines | ||
| 8 | 8 | - "marvell,armada-375-xhci" for Armada 375 SoCs |
| 9 | 9 | - "marvell,armada-380-xhci" for Armada 38x SoCs |
| 10 | 10 | - "renesas,xhci-r8a7743" for r8a7743 SoC |
| 11 | + - "renesas,xhci-r8a7744" for r8a7744 SoC | |
| 12 | + - "renesas,xhci-r8a774a1" for r8a774a1 SoC | |
| 11 | 13 | - "renesas,xhci-r8a7790" for r8a7790 SoC |
| 12 | 14 | - "renesas,xhci-r8a7791" for r8a7791 SoC |
| 13 | 15 | - "renesas,xhci-r8a7793" for r8a7793 SoC |
| @@ -17,7 +19,8 @@ Required properties: · 3 unmodified lines | ||
| 17 | 19 | - "renesas,xhci-r8a77990" for r8a77990 SoC |
| 18 | 20 | - "renesas,rcar-gen2-xhci" for a generic R-Car Gen2 or RZ/G1 compatible |
| 19 | 21 | device |
| 20 | − - "renesas,rcar-gen3-xhci" for a generic R-Car Gen3 compatible device | |
| 22 | + - "renesas,rcar-gen3-xhci" for a generic R-Car Gen3 or RZ/G2 compatible | |
| 23 | + device | |
| 21 | 24 | - "xhci-platform" (deprecated) |
| 22 | 25 | |
| 23 | 26 | When compatible with the generic version, nodes must list the |
| @@ -67,6 +67,7 @@ capella Capella Microsystems, Inc · 66 unmodified lines | ||
| 67 | 67 | cascoda Cascoda, Ltd. |
| 68 | 68 | cavium Cavium, Inc. |
| 69 | 69 | cdns Cadence Design Systems Inc. |
| 70 | +cdtech CDTech(H.K.) Electronics Limited | |
| 70 | 71 | ceva Ceva, Inc. |
| 71 | 72 | chipidea Chipidea, Inc |
| 72 | 73 | chipone ChipOne |
| @@ -84,6 +85,7 @@ cosmic Cosmic Circuits · 11 unmodified lines | ||
| 84 | 85 | crane Crane Connectivity Solutions |
| 85 | 86 | creative Creative Technology Ltd |
| 86 | 87 | crystalfontz Crystalfontz America, Inc. |
| 88 | +csky Hangzhou C-SKY Microsystems Co., Ltd | |
| 87 | 89 | cubietech Cubietech, Ltd. |
| 88 | 90 | cypress Cypress Semiconductor Corporation |
| 89 | 91 | cznic CZ.NIC, z.s.p.o. |
| @@ -114,6 +116,7 @@ elan Elan Microelectronic Corp. · 24 unmodified lines | ||
| 114 | 116 | embest Shenzhen Embest Technology Co., Ltd. |
| 115 | 117 | emmicro EM Microelectronic |
| 116 | 118 | emtrion emtrion GmbH |
| 119 | +endless Endless Mobile, Inc. | |
| 117 | 120 | energymicro Silicon Laboratories (formerly Energy Micro AS) |
| 118 | 121 | engicam Engicam S.r.l. |
| 119 | 122 | epcos EPCOS AG |
| @@ -127,6 +130,7 @@ everspin Everspin Technologies, Inc. · 7 unmodified lines | ||
| 127 | 130 | exar Exar Corporation |
| 128 | 131 | excito Excito |
| 129 | 132 | ezchip EZchip Semiconductor |
| 133 | +facebook Facebook | |
| 130 | 134 | fairphone Fairphone B.V. |
| 131 | 135 | faraday Faraday Technology Corporation |
| 132 | 136 | fastrax Fastrax Oy |
| @@ -235,6 +239,7 @@ micrel Micrel Inc. · 102 unmodified lines | ||
| 235 | 239 | microchip Microchip Technology Inc. |
| 236 | 240 | microcrystal Micro Crystal AG |
| 237 | 241 | micron Micron Technology Inc. |
| 242 | +mikroe MikroElektronika d.o.o. | |
| 238 | 243 | minix MINIX Technology Ltd. |
| 239 | 244 | miramems MiraMEMS Sensing Technology Co., Ltd. |
| 240 | 245 | mitsubishi Mitsubishi Electric Corporation |
| @@ -274,6 +279,7 @@ nxp NXP Semiconductors · 33 unmodified lines | ||
| 274 | 279 | okaya Okaya Electric America, Inc. |
| 275 | 280 | oki Oki Electric Industry Co., Ltd. |
| 276 | 281 | olimex OLIMEX Ltd. |
| 282 | +olpc One Laptop Per Child | |
| 277 | 283 | onion Onion Corporation |
| 278 | 284 | onnn ON Semiconductor Corp. |
| 279 | 285 | ontat On Tat Industrial Company |
| @@ -297,6 +303,7 @@ pine64 Pine64 · 17 unmodified lines | ||
| 297 | 303 | pixcir PIXCIR MICROELECTRONICS Co., Ltd |
| 298 | 304 | plathome Plat'Home Co., Ltd. |
| 299 | 305 | plda PLDA |
| 306 | +plx Broadcom Corporation (formerly PLX Technology) | |
| 300 | 307 | portwell Portwell Inc. |
| 301 | 308 | poslab Poslab Technology Co., Ltd. |
| 302 | 309 | powervr PowerVR (deprecated, use img) |
| @@ -0,0 +1,23 @@ | ||
| 1 | +* Armada 37xx CPU Watchdog Timer Controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible : must be "marvell,armada-3700-wdt" | |
| 5 | +- reg : base physical address of the controller and length of memory mapped | |
| 6 | + region. | |
| 7 | +- clocks : the clock feeding the watchdog timer. See clock-bindings.txt | |
| 8 | +- marvell,system-controller : reference to syscon node for the CPU Miscellaneous | |
| 9 | + Registers | |
| 10 | + | |
| 11 | +Example: | |
| 12 | + | |
| 13 | + cpu_misc: system-controller@d000 { | |
| 14 | + compatible = "marvell,armada-3700-cpu-misc", "syscon"; | |
| 15 | + reg = <0xd000 0x1000>; | |
| 16 | + }; | |
| 17 | + | |
| 18 | + wdt: watchdog@8300 { | |
| 19 | + compatible = "marvell,armada-3700-wdt"; | |
| 20 | + reg = <0x8300 0x40>; | |
| 21 | + marvell,system-controller = <&cpu_misc>; | |
| 22 | + clocks = <&xtalclk>; | |
| 23 | + }; | |
| @@ -0,0 +1,25 @@ | ||
| 1 | +* Freescale mpc8xxx watchdog driver (For 83xx, 86xx and 8xx) | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: Shall contain one of the following: | |
| 5 | + "mpc83xx_wdt" for an mpc83xx | |
| 6 | + "fsl,mpc8610-wdt" for an mpc86xx | |
| 7 | + "fsl,mpc823-wdt" for an mpc8xx | |
| 8 | +- reg: base physical address and length of the area hosting the | |
| 9 | + watchdog registers. | |
| 10 | + On the 83xx, "Watchdog Timer Registers" area: <0x200 0x100> | |
| 11 | + On the 86xx, "Watchdog Timer Registers" area: <0xe4000 0x100> | |
| 12 | + On the 8xx, "General System Interface Unit" area: <0x0 0x10> | |
| 13 | + | |
| 14 | +Optional properties: | |
| 15 | +- reg: additional physical address and length (4) of location of the | |
| 16 | + Reset Status Register (called RSTRSCR on the mpc86xx) | |
| 17 | + On the 83xx, it is located at offset 0x910 | |
| 18 | + On the 86xx, it is located at offset 0xe0094 | |
| 19 | + On the 8xx, it is located at offset 0x288 | |
| 20 | + | |
| 21 | +Example: | |
| 22 | + WDT: watchdog@0 { | |
| 23 | + compatible = "fsl,mpc823-wdt"; | |
| 24 | + reg = <0x0 0x10 0x288 0x4>; | |
| 25 | + }; | |
| @@ -6,6 +6,7 @@ Required properties: · 5 unmodified lines | ||
| 6 | 6 | version. |
| 7 | 7 | Examples with soctypes are: |
| 8 | 8 | - "renesas,r8a7743-wdt" (RZ/G1M) |
| 9 | + - "renesas,r8a7744-wdt" (RZ/G1N) | |
| 9 | 10 | - "renesas,r8a7745-wdt" (RZ/G1E) |
| 10 | 11 | - "renesas,r8a774a1-wdt" (RZ/G2M) |
| 11 | 12 | - "renesas,r8a7790-wdt" (R-Car H2) |
| @@ -20,6 +21,7 @@ Required properties: · 8 unmodified lines | ||
| 20 | 21 | - "renesas,r8a77990-wdt" (R-Car E3) |
| 21 | 22 | - "renesas,r8a77995-wdt" (R-Car D3) |
| 22 | 23 | - "renesas,r7s72100-wdt" (RZ/A1) |
| 24 | + - "renesas,r7s9210-wdt" (RZ/A2) | |
| 23 | 25 | The generic compatible string must be: |
| 24 | 26 | - "renesas,rza-wdt" for RZ/A |
| 25 | 27 | - "renesas,rcar-gen2-wdt" for R-Car Gen2 and RZ/G1 |
| @@ -121,6 +121,9 @@ Kernel utility functions · 120 unmodified lines | ||
| 121 | 121 | .. kernel-doc:: kernel/rcu/update.c |
| 122 | 122 | :export: |
| 123 | 123 | |
| 124 | +.. kernel-doc:: include/linux/overflow.h | |
| 125 | + :internal: | |
| 126 | + | |
| 124 | 127 | Device Resource Management |
| 125 | 128 | -------------------------- |
| 126 | 129 | |
| @@ -0,0 +1,48 @@ | ||
| 1 | +=========================================== | |
| 2 | +Firewire (IEEE 1394) driver Interface Guide | |
| 3 | +=========================================== | |
| 4 | + | |
| 5 | +Introduction and Overview | |
| 6 | +========================= | |
| 7 | + | |
| 8 | +The Linux FireWire subsystem adds some interfaces into the Linux system to | |
| 9 | + use/maintain+any resource on IEEE 1394 bus. | |
| 10 | + | |
| 11 | +The main purpose of these interfaces is to access address space on each node | |
| 12 | +on IEEE 1394 bus by ISO/IEC 13213 (IEEE 1212) procedure, and to control | |
| 13 | +isochronous resources on the bus by IEEE 1394 procedure. | |
| 14 | + | |
| 15 | +Two types of interfaces are added, according to consumers of the interface. A | |
| 16 | +set of userspace interfaces is available via `firewire character devices`. A set | |
| 17 | +of kernel interfaces is available via exported symbols in `firewire-core` module. | |
| 18 | + | |
| 19 | +Firewire char device data structures | |
| 20 | +==================================== | |
| 21 | + | |
| 22 | +.. include:: /ABI/stable/firewire-cdev | |
| 23 | + :literal: | |
| 24 | + | |
| 25 | +.. kernel-doc:: include/uapi/linux/firewire-cdev.h | |
| 26 | + :internal: | |
| 27 | + | |
| 28 | +Firewire device probing and sysfs interfaces | |
| 29 | +============================================ | |
| 30 | + | |
| 31 | +.. include:: /ABI/stable/sysfs-bus-firewire | |
| 32 | + :literal: | |
| 33 | + | |
| 34 | +.. kernel-doc:: drivers/firewire/core-device.c | |
| 35 | + :export: | |
| 36 | + | |
| 37 | +Firewire core transaction interfaces | |
| 38 | +==================================== | |
| 39 | + | |
| 40 | +.. kernel-doc:: drivers/firewire/core-transaction.c | |
| 41 | + :export: | |
| 42 | + | |
| 43 | +Firewire Isochronous I/O interfaces | |
| 44 | +=================================== | |
| 45 | + | |
| 46 | +.. kernel-doc:: drivers/firewire/core-iso.c | |
| 47 | + :export: | |
| 48 | + | |
| @@ -4,6 +4,12 @@ FPGA Bridge · 3 unmodified lines | ||
| 4 | 4 | API to implement a new FPGA bridge |
| 5 | 5 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 6 | 6 | |
| 7 | +* struct :c:type:`fpga_bridge` — The FPGA Bridge structure | |
| 8 | +* struct :c:type:`fpga_bridge_ops` — Low level Bridge driver ops | |
| 9 | +* :c:func:`devm_fpga_bridge_create()` — Allocate and init a bridge struct | |
| 10 | +* :c:func:`fpga_bridge_register()` — Register a bridge | |
| 11 | +* :c:func:`fpga_bridge_unregister()` — Unregister a bridge | |
| 12 | + | |
| 7 | 13 | .. kernel-doc:: include/linux/fpga/fpga-bridge.h |
| 8 | 14 | :functions: fpga_bridge |
| 9 | 15 | |
| @@ -11,39 +17,10 @@ API to implement a new FPGA bridge · 1 unmodified line | ||
| 11 | 17 | :functions: fpga_bridge_ops |
| 12 | 18 | |
| 13 | 19 | .. kernel-doc:: drivers/fpga/fpga-bridge.c |
| 14 | − :functions: fpga_bridge_create | |
| 15 | − | |
| 16 | −.. kernel-doc:: drivers/fpga/fpga-bridge.c | |
| 17 | − :functions: fpga_bridge_free | |
| 20 | + :functions: devm_fpga_bridge_create | |
| 18 | 21 | |
| 19 | 22 | .. kernel-doc:: drivers/fpga/fpga-bridge.c |
| 20 | 23 | :functions: fpga_bridge_register |
| 21 | 24 | |
| 22 | 25 | .. kernel-doc:: drivers/fpga/fpga-bridge.c |
| 23 | 26 | :functions: fpga_bridge_unregister |
| 24 | − | |
| 25 | −API to control an FPGA bridge | |
| 26 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 27 | − | |
| 28 | −You probably won't need these directly. FPGA regions should handle this. | |
| 29 | − | |
| 30 | −.. kernel-doc:: drivers/fpga/fpga-bridge.c | |
| 31 | − :functions: of_fpga_bridge_get | |
| 32 | − | |
| 33 | −.. kernel-doc:: drivers/fpga/fpga-bridge.c | |
| 34 | − :functions: fpga_bridge_get | |
| 35 | − | |
| 36 | −.. kernel-doc:: drivers/fpga/fpga-bridge.c | |
| 37 | − :functions: fpga_bridge_put | |
| 38 | − | |
| 39 | −.. kernel-doc:: drivers/fpga/fpga-bridge.c | |
| 40 | − :functions: fpga_bridge_get_to_list | |
| 41 | − | |
| 42 | −.. kernel-doc:: drivers/fpga/fpga-bridge.c | |
| 43 | − :functions: of_fpga_bridge_get_to_list | |
| 44 | − | |
| 45 | −.. kernel-doc:: drivers/fpga/fpga-bridge.c | |
| 46 | − :functions: fpga_bridge_enable | |
| 47 | − | |
| 48 | −.. kernel-doc:: drivers/fpga/fpga-bridge.c | |
| 49 | − :functions: fpga_bridge_disable | |
| @@ -49,18 +49,14 @@ probe function calls fpga_mgr_register(), such as:: · 48 unmodified lines | ||
| 49 | 49 | * them in priv |
| 50 | 50 | */ |
| 51 | 51 | |
| 52 | − mgr = fpga_mgr_create(dev, "Altera SOCFPGA FPGA Manager", | |
| 53 | − &socfpga_fpga_ops, priv); | |
| 52 | + mgr = devm_fpga_mgr_create(dev, "Altera SOCFPGA FPGA Manager", | |
| 53 | + &socfpga_fpga_ops, priv); | |
| 54 | 54 | if (!mgr) |
| 55 | 55 | return -ENOMEM; |
| 56 | 56 | |
| 57 | 57 | platform_set_drvdata(pdev, mgr); |
| 58 | 58 | |
| 59 | − ret = fpga_mgr_register(mgr); | |
| 60 | − if (ret) | |
| 61 | − fpga_mgr_free(mgr); | |
| 62 | − | |
| 63 | − return ret; | |
| 59 | + return fpga_mgr_register(mgr); | |
| 64 | 60 | } |
| 65 | 61 | |
| 66 | 62 | static int socfpga_fpga_remove(struct platform_device *pdev) |
| @@ -102,67 +98,19 @@ The ops include a .state function which will determine the state the FPGA is in · 35 unmodified lines | ||
| 102 | 98 | and return a code of type enum fpga_mgr_states. It doesn't result in a change |
| 103 | 99 | in state. |
| 104 | 100 | |
| 105 | −How to write an image buffer to a supported FPGA | |
| 106 | −------------------------------------------------ | |
| 107 | − | |
| 108 | −Some sample code:: | |
| 109 | − | |
| 110 | − #include <linux/fpga/fpga-mgr.h> | |
| 111 | − | |
| 112 | − struct fpga_manager *mgr; | |
| 113 | − struct fpga_image_info *info; | |
| 114 | − int ret; | |
| 115 | − | |
| 116 | − /* | |
| 117 | − * Get a reference to FPGA manager. The manager is not locked, so you can | |
| 118 | − * hold onto this reference without it preventing programming. | |
| 119 | − * | |
| 120 | − * This example uses the device node of the manager. Alternatively, use | |
| 121 | − * fpga_mgr_get(dev) instead if you have the device. | |
| 122 | − */ | |
| 123 | − mgr = of_fpga_mgr_get(mgr_node); | |
| 124 | − | |
| 125 | − /* struct with information about the FPGA image to program. */ | |
| 126 | − info = fpga_image_info_alloc(dev); | |
| 127 | − | |
| 128 | − /* flags indicates whether to do full or partial reconfiguration */ | |
| 129 | − info->flags = FPGA_MGR_PARTIAL_RECONFIG; | |
| 130 | − | |
| 131 | − /* | |
| 132 | − * At this point, indicate where the image is. This is pseudo-code; you're | |
| 133 | − * going to use one of these three. | |
| 134 | − */ | |
| 135 | − if (image is in a scatter gather table) { | |
| 136 | − | |
| 137 | − info->sgt = [your scatter gather table] | |
| 138 | − | |
| 139 | − } else if (image is in a buffer) { | |
| 140 | − | |
| 141 | − info->buf = [your image buffer] | |
| 142 | − info->count = [image buffer size] | |
| 143 | − | |
| 144 | − } else if (image is in a firmware file) { | |
| 145 | − | |
| 146 | − info->firmware_name = devm_kstrdup(dev, firmware_name, GFP_KERNEL); | |
| 147 | − | |
| 148 | − } | |
| 149 | − | |
| 150 | − /* Get exclusive control of FPGA manager */ | |
| 151 | − ret = fpga_mgr_lock(mgr); | |
| 152 | − | |
| 153 | − /* Load the buffer to the FPGA */ | |
| 154 | − ret = fpga_mgr_buf_load(mgr, &info, buf, count); | |
| 155 | − | |
| 156 | − /* Release the FPGA manager */ | |
| 157 | − fpga_mgr_unlock(mgr); | |
| 158 | − fpga_mgr_put(mgr); | |
| 159 | − | |
| 160 | − /* Deallocate the image info if you're done with it */ | |
| 161 | − fpga_image_info_free(info); | |
| 162 | − | |
| 163 | 101 | API for implementing a new FPGA Manager driver |
| 164 | 102 | ---------------------------------------------- |
| 165 | 103 | |
| 104 | +* ``fpga_mgr_states`` — Values for :c:member:`fpga_manager->state`. | |
| 105 | +* struct :c:type:`fpga_manager` — the FPGA manager struct | |
| 106 | +* struct :c:type:`fpga_manager_ops` — Low level FPGA manager driver ops | |
| 107 | +* :c:func:`devm_fpga_mgr_create` — Allocate and init a manager struct | |
| 108 | +* :c:func:`fpga_mgr_register` — Register an FPGA manager | |
| 109 | +* :c:func:`fpga_mgr_unregister` — Unregister an FPGA manager | |
| 110 | + | |
| 111 | +.. kernel-doc:: include/linux/fpga/fpga-mgr.h | |
| 112 | + :functions: fpga_mgr_states | |
| 113 | + | |
| 166 | 114 | .. kernel-doc:: include/linux/fpga/fpga-mgr.h |
| 167 | 115 | :functions: fpga_manager |
| 168 | 116 | |
| @@ -170,51 +118,10 @@ API for implementing a new FPGA Manager driver · 1 unmodified line | ||
| 170 | 118 | :functions: fpga_manager_ops |
| 171 | 119 | |
| 172 | 120 | .. kernel-doc:: drivers/fpga/fpga-mgr.c |
| 173 | − :functions: fpga_mgr_create | |
| 174 | − | |
| 175 | −.. kernel-doc:: drivers/fpga/fpga-mgr.c | |
| 176 | − :functions: fpga_mgr_free | |
| 121 | + :functions: devm_fpga_mgr_create | |
| 177 | 122 | |
| 178 | 123 | .. kernel-doc:: drivers/fpga/fpga-mgr.c |
| 179 | 124 | :functions: fpga_mgr_register |
| 180 | 125 | |
| 181 | 126 | .. kernel-doc:: drivers/fpga/fpga-mgr.c |
| 182 | 127 | :functions: fpga_mgr_unregister |
| 183 | − | |
| 184 | −API for programming an FPGA | |
| 185 | −--------------------------- | |
| 186 | − | |
| 187 | −.. kernel-doc:: include/linux/fpga/fpga-mgr.h | |
| 188 | − :functions: fpga_image_info | |
| 189 | − | |
| 190 | −.. kernel-doc:: include/linux/fpga/fpga-mgr.h | |
| 191 | − :functions: fpga_mgr_states | |
| 192 | − | |
| 193 | −.. kernel-doc:: drivers/fpga/fpga-mgr.c | |
| 194 | − :functions: fpga_image_info_alloc | |
| 195 | − | |
| 196 | −.. kernel-doc:: drivers/fpga/fpga-mgr.c | |
| 197 | − :functions: fpga_image_info_free | |
| 198 | − | |
| 199 | −.. kernel-doc:: drivers/fpga/fpga-mgr.c | |
| 200 | − :functions: of_fpga_mgr_get | |
| 201 | − | |
| 202 | −.. kernel-doc:: drivers/fpga/fpga-mgr.c | |
| 203 | − :functions: fpga_mgr_get | |
| 204 | − | |
| 205 | −.. kernel-doc:: drivers/fpga/fpga-mgr.c | |
| 206 | − :functions: fpga_mgr_put | |
| 207 | − | |
| 208 | −.. kernel-doc:: drivers/fpga/fpga-mgr.c | |
| 209 | − :functions: fpga_mgr_lock | |
| 210 | − | |
| 211 | −.. kernel-doc:: drivers/fpga/fpga-mgr.c | |
| 212 | − :functions: fpga_mgr_unlock | |
| 213 | − | |
| 214 | −.. kernel-doc:: include/linux/fpga/fpga-mgr.h | |
| 215 | − :functions: fpga_mgr_states | |
| 216 | − | |
| 217 | −Note - use :c:func:`fpga_region_program_fpga()` instead of :c:func:`fpga_mgr_load()` | |
| 218 | − | |
| 219 | −.. kernel-doc:: drivers/fpga/fpga-mgr.c | |
| 220 | − :functions: fpga_mgr_load | |
| @@ -0,0 +1,107 @@ | ||
| 1 | +In-kernel API for FPGA Programming | |
| 2 | +================================== | |
| 3 | + | |
| 4 | +Overview | |
| 5 | +-------- | |
| 6 | + | |
| 7 | +The in-kernel API for FPGA programming is a combination of APIs from | |
| 8 | +FPGA manager, bridge, and regions. The actual function used to | |
| 9 | +trigger FPGA programming is :c:func:`fpga_region_program_fpga()`. | |
| 10 | + | |
| 11 | +:c:func:`fpga_region_program_fpga()` uses functionality supplied by | |
| 12 | +the FPGA manager and bridges. It will: | |
| 13 | + | |
| 14 | + * lock the region's mutex | |
| 15 | + * lock the mutex of the region's FPGA manager | |
| 16 | + * build a list of FPGA bridges if a method has been specified to do so | |
| 17 | + * disable the bridges | |
| 18 | + * program the FPGA using info passed in :c:member:`fpga_region->info`. | |
| 19 | + * re-enable the bridges | |
| 20 | + * release the locks | |
| 21 | + | |
| 22 | +The struct fpga_image_info specifies what FPGA image to program. It is | |
| 23 | +allocated/freed by :c:func:`fpga_image_info_alloc()` and freed with | |
| 24 | +:c:func:`fpga_image_info_free()` | |
| 25 | + | |
| 26 | +How to program an FPGA using a region | |
| 27 | +------------------------------------- | |
| 28 | + | |
| 29 | +When the FPGA region driver probed, it was given a pointer to an FPGA manager | |
| 30 | +driver so it knows which manager to use. The region also either has a list of | |
| 31 | +bridges to control during programming or it has a pointer to a function that | |
| 32 | +will generate that list. Here's some sample code of what to do next:: | |
| 33 | + | |
| 34 | + #include <linux/fpga/fpga-mgr.h> | |
| 35 | + #include <linux/fpga/fpga-region.h> | |
| 36 | + | |
| 37 | + struct fpga_image_info *info; | |
| 38 | + int ret; | |
| 39 | + | |
| 40 | + /* | |
| 41 | + * First, alloc the struct with information about the FPGA image to | |
| 42 | + * program. | |
| 43 | + */ | |
| 44 | + info = fpga_image_info_alloc(dev); | |
| 45 | + if (!info) | |
| 46 | + return -ENOMEM; | |
| 47 | + | |
| 48 | + /* Set flags as needed, such as: */ | |
| 49 | + info->flags = FPGA_MGR_PARTIAL_RECONFIG; | |
| 50 | + | |
| 51 | + /* | |
| 52 | + * Indicate where the FPGA image is. This is pseudo-code; you're | |
| 53 | + * going to use one of these three. | |
| 54 | + */ | |
| 55 | + if (image is in a scatter gather table) { | |
| 56 | + | |
| 57 | + info->sgt = [your scatter gather table] | |
| 58 | + | |
| 59 | + } else if (image is in a buffer) { | |
| 60 | + | |
| 61 | + info->buf = [your image buffer] | |
| 62 | + info->count = [image buffer size] | |
| 63 | + | |
| 64 | + } else if (image is in a firmware file) { | |
| 65 | + | |
| 66 | + info->firmware_name = devm_kstrdup(dev, firmware_name, | |
| 67 | + GFP_KERNEL); | |
| 68 | + | |
| 69 | + } | |
| 70 | + | |
| 71 | + /* Add info to region and do the programming */ | |
| 72 | + region->info = info; | |
| 73 | + ret = fpga_region_program_fpga(region); | |
| 74 | + | |
| 75 | + /* Deallocate the image info if you're done with it */ | |
| 76 | + region->info = NULL; | |
| 77 | + fpga_image_info_free(info); | |
| 78 | + | |
| 79 | + if (ret) | |
| 80 | + return ret; | |
| 81 | + | |
| 82 | + /* Now enumerate whatever hardware has appeared in the FPGA. */ | |
| 83 | + | |
| 84 | +API for programming an FPGA | |
| 85 | +--------------------------- | |
| 86 | + | |
| 87 | +* :c:func:`fpga_region_program_fpga` — Program an FPGA | |
| 88 | +* :c:type:`fpga_image_info` — Specifies what FPGA image to program | |
| 89 | +* :c:func:`fpga_image_info_alloc()` — Allocate an FPGA image info struct | |
| 90 | +* :c:func:`fpga_image_info_free()` — Free an FPGA image info struct | |
| 91 | + | |
| 92 | +.. kernel-doc:: drivers/fpga/fpga-region.c | |
| 93 | + :functions: fpga_region_program_fpga | |
| 94 | + | |
| 95 | +FPGA Manager flags | |
| 96 | + | |
| 97 | +.. kernel-doc:: include/linux/fpga/fpga-mgr.h | |
| 98 | + :doc: FPGA Manager flags | |
| 99 | + | |
| 100 | +.. kernel-doc:: include/linux/fpga/fpga-mgr.h | |
| 101 | + :functions: fpga_image_info | |
| 102 | + | |
| 103 | +.. kernel-doc:: drivers/fpga/fpga-mgr.c | |
| 104 | + :functions: fpga_image_info_alloc | |
| 105 | + | |
| 106 | +.. kernel-doc:: drivers/fpga/fpga-mgr.c | |
| 107 | + :functions: fpga_image_info_free | |
| @@ -34,41 +34,6 @@ fpga_image_info including: · 33 unmodified lines | ||
| 34 | 34 | * flags indicating specifics such as whether the image is for partial |
| 35 | 35 | reconfiguration. |
| 36 | 36 | |
| 37 | −How to program an FPGA using a region | |
| 38 | −------------------------------------- | |
| 39 | − | |
| 40 | −First, allocate the info struct:: | |
| 41 | − | |
| 42 | − info = fpga_image_info_alloc(dev); | |
| 43 | − if (!info) | |
| 44 | − return -ENOMEM; | |
| 45 | − | |
| 46 | −Set flags as needed, i.e.:: | |
| 47 | − | |
| 48 | − info->flags |= FPGA_MGR_PARTIAL_RECONFIG; | |
| 49 | − | |
| 50 | −Point to your FPGA image, such as:: | |
| 51 | − | |
| 52 | − info->sgt = &sgt; | |
| 53 | − | |
| 54 | −Add info to region and do the programming:: | |
| 55 | − | |
| 56 | − region->info = info; | |
| 57 | − ret = fpga_region_program_fpga(region); | |
| 58 | − | |
| 59 | −:c:func:`fpga_region_program_fpga()` operates on info passed in the | |
| 60 | −fpga_image_info (region->info). This function will attempt to: | |
| 61 | − | |
| 62 | − * lock the region's mutex | |
| 63 | − * lock the region's FPGA manager | |
| 64 | − * build a list of FPGA bridges if a method has been specified to do so | |
| 65 | − * disable the bridges | |
| 66 | − * program the FPGA | |
| 67 | − * re-enable the bridges | |
| 68 | − * release the locks | |
| 69 | − | |
| 70 | −Then you will want to enumerate whatever hardware has appeared in the FPGA. | |
| 71 | − | |
| 72 | 37 | How to add a new FPGA region |
| 73 | 38 | ---------------------------- |
| 74 | 39 | |
| @@ -77,26 +42,62 @@ An example of usage can be seen in the probe function of [#f2]_. · 2 unmodified lines | ||
| 77 | 42 | .. [#f1] ../devicetree/bindings/fpga/fpga-region.txt |
| 78 | 43 | .. [#f2] ../../drivers/fpga/of-fpga-region.c |
| 79 | 44 | |
| 80 | −API to program an FPGA | |
| 81 | −---------------------- | |
| 82 | − | |
| 83 | −.. kernel-doc:: drivers/fpga/fpga-region.c | |
| 84 | − :functions: fpga_region_program_fpga | |
| 85 | − | |
| 86 | 45 | API to add a new FPGA region |
| 87 | 46 | ---------------------------- |
| 88 | 47 | |
| 48 | +* struct :c:type:`fpga_region` — The FPGA region struct | |
| 49 | +* :c:func:`devm_fpga_region_create` — Allocate and init a region struct | |
| 50 | +* :c:func:`fpga_region_register` — Register an FPGA region | |
| 51 | +* :c:func:`fpga_region_unregister` — Unregister an FPGA region | |
| 52 | + | |
| 53 | +The FPGA region's probe function will need to get a reference to the FPGA | |
| 54 | +Manager it will be using to do the programming. This usually would happen | |
| 55 | +during the region's probe function. | |
| 56 | + | |
| 57 | +* :c:func:`fpga_mgr_get` — Get a reference to an FPGA manager, raise ref count | |
| 58 | +* :c:func:`of_fpga_mgr_get` — Get a reference to an FPGA manager, raise ref count, | |
| 59 | + given a device node. | |
| 60 | +* :c:func:`fpga_mgr_put` — Put an FPGA manager | |
| 61 | + | |
| 62 | +The FPGA region will need to specify which bridges to control while programming | |
| 63 | +the FPGA. The region driver can build a list of bridges during probe time | |
| 64 | +(:c:member:`fpga_region->bridge_list`) or it can have a function that creates | |
| 65 | +the list of bridges to program just before programming | |
| 66 | +(:c:member:`fpga_region->get_bridges`). The FPGA bridge framework supplies the | |
| 67 | +following APIs to handle building or tearing down that list. | |
| 68 | + | |
| 69 | +* :c:func:`fpga_bridge_get_to_list` — Get a ref of an FPGA bridge, add it to a | |
| 70 | + list | |
| 71 | +* :c:func:`of_fpga_bridge_get_to_list` — Get a ref of an FPGA bridge, add it to a | |
| 72 | + list, given a device node | |
| 73 | +* :c:func:`fpga_bridges_put` — Given a list of bridges, put them | |
| 74 | + | |
| 89 | 75 | .. kernel-doc:: include/linux/fpga/fpga-region.h |
| 90 | 76 | :functions: fpga_region |
| 91 | 77 | |
| 92 | 78 | .. kernel-doc:: drivers/fpga/fpga-region.c |
| 93 | − :functions: fpga_region_create | |
| 94 | − | |
| 95 | −.. kernel-doc:: drivers/fpga/fpga-region.c | |
| 96 | − :functions: fpga_region_free | |
| 79 | + :functions: devm_fpga_region_create | |
| 97 | 80 | |
| 98 | 81 | .. kernel-doc:: drivers/fpga/fpga-region.c |
| 99 | 82 | :functions: fpga_region_register |
| 100 | 83 | |
| 101 | 84 | .. kernel-doc:: drivers/fpga/fpga-region.c |
| 102 | 85 | :functions: fpga_region_unregister |
| 86 | + | |
| 87 | +.. kernel-doc:: drivers/fpga/fpga-mgr.c | |
| 88 | + :functions: fpga_mgr_get | |
| 89 | + | |
| 90 | +.. kernel-doc:: drivers/fpga/fpga-mgr.c | |
| 91 | + :functions: of_fpga_mgr_get | |
| 92 | + | |
| 93 | +.. kernel-doc:: drivers/fpga/fpga-mgr.c | |
| 94 | + :functions: fpga_mgr_put | |
| 95 | + | |
| 96 | +.. kernel-doc:: drivers/fpga/fpga-bridge.c | |
| 97 | + :functions: fpga_bridge_get_to_list | |
| 98 | + | |
| 99 | +.. kernel-doc:: drivers/fpga/fpga-bridge.c | |
| 100 | + :functions: of_fpga_bridge_get_to_list | |
| 101 | + | |
| 102 | +.. kernel-doc:: drivers/fpga/fpga-bridge.c | |
| 103 | + :functions: fpga_bridges_put | |
| @@ -11,3 +11,5 @@ FPGA Subsystem · 10 unmodified lines | ||
| 11 | 11 | fpga-mgr |
| 12 | 12 | fpga-bridge |
| 13 | 13 | fpga-region |
| 14 | + fpga-programming | |
| 15 | + | |
| @@ -44,7 +44,7 @@ FPGA Region · 43 unmodified lines | ||
| 44 | 44 | ----------- |
| 45 | 45 | |
| 46 | 46 | If you are adding a new interface to the FPGA framework, add it on top |
| 47 | −of an FPGA region to allow the most reuse of your interface. | |
| 47 | +of an FPGA region. | |
| 48 | 48 | |
| 49 | 49 | The FPGA Region framework (fpga-region.c) associates managers and |
| 50 | 50 | bridges as reconfigurable regions. A region may refer to the whole |
| @@ -193,3 +193,27 @@ And the table can be added to the board code as follows:: · 192 unmodified lines | ||
| 193 | 193 | |
| 194 | 194 | The line will be hogged as soon as the gpiochip is created or - in case the |
| 195 | 195 | chip was created earlier - when the hog table is registered. |
| 196 | + | |
| 197 | +Arrays of pins | |
| 198 | +-------------- | |
| 199 | +In addition to requesting pins belonging to a function one by one, a device may | |
| 200 | +also request an array of pins assigned to the function. The way those pins are | |
| 201 | +mapped to the device determines if the array qualifies for fast bitmap | |
| 202 | +processing. If yes, a bitmap is passed over get/set array functions directly | |
| 203 | +between a caller and a respective .get/set_multiple() callback of a GPIO chip. | |
| 204 | + | |
| 205 | +In order to qualify for fast bitmap processing, the array must meet the | |
| 206 | +following requirements: | |
| 207 | +- pin hardware number of array member 0 must also be 0, | |
| 208 | +- pin hardware numbers of consecutive array members which belong to the same | |
| 209 | + chip as member 0 does must also match their array indexes. | |
| 210 | + | |
| 211 | +Otherwise fast bitmap processing path is not used in order to avoid consecutive | |
| 212 | +pins which belong to the same chip but are not in hardware order being processed | |
| 213 | +separately. | |
| 214 | + | |
| 215 | +If the array applies for fast bitmap processing path, pins which belong to | |
| 216 | +different chips than member 0 does, as well as those with indexes different from | |
| 217 | +their hardware pin numbers, are excluded from the fast path, both input and | |
| 218 | +output. Moreover, open drain and open source pins are excluded from fast bitmap | |
| 219 | +output processing. | |
| @@ -109,9 +109,11 @@ For a function using multiple GPIOs all of those can be obtained with one call:: · 108 unmodified lines | ||
| 109 | 109 | enum gpiod_flags flags) |
| 110 | 110 | |
| 111 | 111 | This function returns a struct gpio_descs which contains an array of |
| 112 | −descriptors:: | |
| 112 | +descriptors. It also contains a pointer to a gpiolib private structure which, | |
| 113 | +if passed back to get/set array functions, may speed up I/O proocessing:: | |
| 113 | 114 | |
| 114 | 115 | struct gpio_descs { |
| 116 | + struct gpio_array *info; | |
| 115 | 117 | unsigned int ndescs; |
| 116 | 118 | struct gpio_desc *desc[]; |
| 117 | 119 | } |
| @@ -323,29 +325,37 @@ The following functions get or set the values of an array of GPIOs:: · 205 unmodified lines | ||
| 323 | 325 | |
| 324 | 326 | int gpiod_get_array_value(unsigned int array_size, |
| 325 | 327 | struct gpio_desc **desc_array, |
| 326 | − int *value_array); | |
| 328 | + struct gpio_array *array_info, | |
| 329 | + unsigned long *value_bitmap); | |
| 327 | 330 | int gpiod_get_raw_array_value(unsigned int array_size, |
| 328 | 331 | struct gpio_desc **desc_array, |
| 329 | − int *value_array); | |
| 332 | + struct gpio_array *array_info, | |
| 333 | + unsigned long *value_bitmap); | |
| 330 | 334 | int gpiod_get_array_value_cansleep(unsigned int array_size, |
| 331 | 335 | struct gpio_desc **desc_array, |
| 332 | − int *value_array); | |
| 336 | + struct gpio_array *array_info, | |
| 337 | + unsigned long *value_bitmap); | |
| 333 | 338 | int gpiod_get_raw_array_value_cansleep(unsigned int array_size, |
| 334 | 339 | struct gpio_desc **desc_array, |
| 335 | − int *value_array); | |
| 336 | − | |
| 337 | − void gpiod_set_array_value(unsigned int array_size, | |
| 338 | − struct gpio_desc **desc_array, | |
| 339 | − int *value_array) | |
| 340 | − void gpiod_set_raw_array_value(unsigned int array_size, | |
| 341 | − struct gpio_desc **desc_array, | |
| 342 | − int *value_array) | |
| 343 | − void gpiod_set_array_value_cansleep(unsigned int array_size, | |
| 344 | − struct gpio_desc **desc_array, | |
| 345 | − int *value_array) | |
| 346 | − void gpiod_set_raw_array_value_cansleep(unsigned int array_size, | |
| 347 | − struct gpio_desc **desc_array, | |
| 348 | − int *value_array) | |
| 340 | + struct gpio_array *array_info, | |
| 341 | + unsigned long *value_bitmap); | |
| 342 | + | |
| 343 | + int gpiod_set_array_value(unsigned int array_size, | |
| 344 | + struct gpio_desc **desc_array, | |
| 345 | + struct gpio_array *array_info, | |
| 346 | + unsigned long *value_bitmap) | |
| 347 | + int gpiod_set_raw_array_value(unsigned int array_size, | |
| 348 | + struct gpio_desc **desc_array, | |
| 349 | + struct gpio_array *array_info, | |
| 350 | + unsigned long *value_bitmap) | |
| 351 | + int gpiod_set_array_value_cansleep(unsigned int array_size, | |
| 352 | + struct gpio_desc **desc_array, | |
| 353 | + struct gpio_array *array_info, | |
| 354 | + unsigned long *value_bitmap) | |
| 355 | + int gpiod_set_raw_array_value_cansleep(unsigned int array_size, | |
| 356 | + struct gpio_desc **desc_array, | |
| 357 | + struct gpio_array *array_info, | |
| 358 | + unsigned long *value_bitmap) | |
| 349 | 359 | |
| 350 | 360 | The array can be an arbitrary set of GPIOs. The functions will try to access |
| 351 | 361 | GPIOs belonging to the same bank or chip simultaneously if supported by the |
| @@ -356,8 +366,9 @@ accessed sequentially. · 4 unmodified lines | ||
| 356 | 366 | The functions take three arguments: |
| 357 | 367 | * array_size - the number of array elements |
| 358 | 368 | * desc_array - an array of GPIO descriptors |
| 359 | − * value_array - an array to store the GPIOs' values (get) or | |
| 360 | − an array of values to assign to the GPIOs (set) | |
| 369 | + * array_info - optional information obtained from gpiod_array_get() | |
| 370 | + * value_bitmap - a bitmap to store the GPIOs' values (get) or | |
| 371 | + a bitmap of values to assign to the GPIOs (set) | |
| 361 | 372 | |
| 362 | 373 | The descriptor array can be obtained using the gpiod_get_array() function |
| 363 | 374 | or one of its variants. If the group of descriptors returned by that function |
| @@ -366,16 +377,25 @@ the struct gpio_descs returned by gpiod_get_array():: · 2 unmodified lines | ||
| 366 | 377 | |
| 367 | 378 | struct gpio_descs *my_gpio_descs = gpiod_get_array(...); |
| 368 | 379 | gpiod_set_array_value(my_gpio_descs->ndescs, my_gpio_descs->desc, |
| 369 | − my_gpio_values); | |
| 380 | + my_gpio_descs->info, my_gpio_value_bitmap); | |
| 370 | 381 | |
| 371 | 382 | It is also possible to access a completely arbitrary array of descriptors. The |
| 372 | 383 | descriptors may be obtained using any combination of gpiod_get() and |
| 373 | 384 | gpiod_get_array(). Afterwards the array of descriptors has to be setup |
| 374 | −manually before it can be passed to one of the above functions. | |
| 385 | +manually before it can be passed to one of the above functions. In that case, | |
| 386 | +array_info should be set to NULL. | |
| 375 | 387 | |
| 376 | 388 | Note that for optimal performance GPIOs belonging to the same chip should be |
| 377 | 389 | contiguous within the array of descriptors. |
| 378 | 390 | |
| 391 | +Still better performance may be achieved if array indexes of the descriptors | |
| 392 | +match hardware pin numbers of a single chip. If an array passed to a get/set | |
| 393 | +array function matches the one obtained from gpiod_get_array() and array_info | |
| 394 | +associated with the array is also passed, the function may take a fast bitmap | |
| 395 | +processing path, passing the value_bitmap argument directly to the respective | |
| 396 | +.get/set_multiple() callback of the chip. That allows for utilization of GPIO | |
| 397 | +banks as data I/O ports without much loss of performance. | |
| 398 | + | |
| 379 | 399 | The return value of gpiod_get_array_value() and its variants is 0 on success |
| 380 | 400 | or negative on error. Note the difference to gpiod_get_value(), which returns |
| 381 | 401 | 0 or 1 on success to convey the GPIO value. With the array functions, the GPIO |
| @@ -374,7 +374,28 @@ When implementing an irqchip inside a GPIO driver, these two functions should · 373 unmodified lines | ||
| 374 | 374 | typically be called in the .startup() and .shutdown() callbacks from the |
| 375 | 375 | irqchip. |
| 376 | 376 | |
| 377 | −When using the gpiolib irqchip helpers, these callback are automatically | |
| 377 | +When using the gpiolib irqchip helpers, these callbacks are automatically | |
| 378 | +assigned. | |
| 379 | + | |
| 380 | + | |
| 381 | +Disabling and enabling IRQs | |
| 382 | +--------------------------- | |
| 383 | +When a GPIO is used as an IRQ signal, then gpiolib also needs to know if | |
| 384 | +the IRQ is enabled or disabled. In order to inform gpiolib about this, | |
| 385 | +a driver should call:: | |
| 386 | + | |
| 387 | + void gpiochip_disable_irq(struct gpio_chip *chip, unsigned int offset) | |
| 388 | + | |
| 389 | +This allows drivers to drive the GPIO as an output while the IRQ is | |
| 390 | +disabled. When the IRQ is enabled again, a driver should call:: | |
| 391 | + | |
| 392 | + void gpiochip_enable_irq(struct gpio_chip *chip, unsigned int offset) | |
| 393 | + | |
| 394 | +When implementing an irqchip inside a GPIO driver, these two functions should | |
| 395 | +typically be called in the .irq_disable() and .irq_enable() callbacks from the | |
| 396 | +irqchip. | |
| 397 | + | |
| 398 | +When using the gpiolib irqchip helpers, these callbacks are automatically | |
| 378 | 399 | assigned. |
| 379 | 400 | |
| 380 | 401 | Real-Time compliance for GPIO IRQ chips |
| @@ -38,7 +38,7 @@ Device tree support · 37 unmodified lines | ||
| 38 | 38 | Device-managed API |
| 39 | 39 | ================== |
| 40 | 40 | |
| 41 | −.. kernel-doc:: drivers/gpio/devres.c | |
| 41 | +.. kernel-doc:: drivers/gpio/gpiolib-devres.c | |
| 42 | 42 | :export: |
| 43 | 43 | |
| 44 | 44 | sysfs helpers |
| @@ -29,7 +29,8 @@ available subsections can be seen below. · 28 unmodified lines | ||
| 29 | 29 | iio/index |
| 30 | 30 | input |
| 31 | 31 | usb/index |
| 32 | − pci | |
| 32 | + firewire | |
| 33 | + pci/index | |
| 33 | 34 | spi |
| 34 | 35 | i2c |
| 35 | 36 | hsi |
| @@ -180,10 +180,10 @@ by a chip select decoder. · 179 unmodified lines | ||
| 180 | 180 | { |
| 181 | 181 | struct nand_chip *this = mtd_to_nand(mtd); |
| 182 | 182 | switch(cmd){ |
| 183 | − case NAND_CTL_SETCLE: this->IO_ADDR_W |= CLE_ADRR_BIT; break; | |
| 184 | − case NAND_CTL_CLRCLE: this->IO_ADDR_W &= ~CLE_ADRR_BIT; break; | |
| 185 | − case NAND_CTL_SETALE: this->IO_ADDR_W |= ALE_ADRR_BIT; break; | |
| 186 | − case NAND_CTL_CLRALE: this->IO_ADDR_W &= ~ALE_ADRR_BIT; break; | |
| 183 | + case NAND_CTL_SETCLE: this->legacy.IO_ADDR_W |= CLE_ADRR_BIT; break; | |
| 184 | + case NAND_CTL_CLRCLE: this->legacy.IO_ADDR_W &= ~CLE_ADRR_BIT; break; | |
| 185 | + case NAND_CTL_SETALE: this->legacy.IO_ADDR_W |= ALE_ADRR_BIT; break; | |
| 186 | + case NAND_CTL_CLRALE: this->legacy.IO_ADDR_W &= ~ALE_ADRR_BIT; break; | |
| 187 | 187 | } |
| 188 | 188 | } |
| 189 | 189 | |
| @@ -197,7 +197,7 @@ to read back the state of the pin. The function has no arguments and · 7 unmodified lines | ||
| 197 | 197 | should return 0, if the device is busy (R/B pin is low) and 1, if the |
| 198 | 198 | device is ready (R/B pin is high). If the hardware interface does not |
| 199 | 199 | give access to the ready busy pin, then the function must not be defined |
| 200 | −and the function pointer this->dev_ready is set to NULL. | |
| 200 | +and the function pointer this->legacy.dev_ready is set to NULL. | |
| 201 | 201 | |
| 202 | 202 | Init function |
| 203 | 203 | ------------- |
| @@ -235,18 +235,18 @@ necessary information about the device. · 31 unmodified lines | ||
| 235 | 235 | } |
| 236 | 236 | |
| 237 | 237 | /* Set address of NAND IO lines */ |
| 238 | − this->IO_ADDR_R = baseaddr; | |
| 239 | − this->IO_ADDR_W = baseaddr; | |
| 238 | + this->legacy.IO_ADDR_R = baseaddr; | |
| 239 | + this->legacy.IO_ADDR_W = baseaddr; | |
| 240 | 240 | /* Reference hardware control function */ |
| 241 | 241 | this->hwcontrol = board_hwcontrol; |
| 242 | 242 | /* Set command delay time, see datasheet for correct value */ |
| 243 | − this->chip_delay = CHIP_DEPENDEND_COMMAND_DELAY; | |
| 243 | + this->legacy.chip_delay = CHIP_DEPENDEND_COMMAND_DELAY; | |
| 244 | 244 | /* Assign the device ready function, if available */ |
| 245 | − this->dev_ready = board_dev_ready; | |
| 245 | + this->legacy.dev_ready = board_dev_ready; | |
| 246 | 246 | this->eccmode = NAND_ECC_SOFT; |
| 247 | 247 | |
| 248 | 248 | /* Scan to find existence of the device */ |
| 249 | − if (nand_scan (board_mtd, 1)) { | |
| 249 | + if (nand_scan (this, 1)) { | |
| 250 | 250 | err = -ENXIO; |
| 251 | 251 | goto out_ior; |
| 252 | 252 | } |
| @@ -277,7 +277,7 @@ unregisters the partitions in the MTD layer. · 24 unmodified lines | ||
| 277 | 277 | static void __exit board_cleanup (void) |
| 278 | 278 | { |
| 279 | 279 | /* Release resources, unregister device */ |
| 280 | − nand_release (board_mtd); | |
| 280 | + nand_release (mtd_to_nand(board_mtd)); | |
| 281 | 281 | |
| 282 | 282 | /* unmap physical address */ |
| 283 | 283 | iounmap(baseaddr); |
| @@ -336,17 +336,17 @@ connected to an address decoder. · 52 unmodified lines | ||
| 336 | 336 | struct nand_chip *this = mtd_to_nand(mtd); |
| 337 | 337 | |
| 338 | 338 | /* Deselect all chips */ |
| 339 | − this->IO_ADDR_R &= ~BOARD_NAND_ADDR_MASK; | |
| 340 | − this->IO_ADDR_W &= ~BOARD_NAND_ADDR_MASK; | |
| 339 | + this->legacy.IO_ADDR_R &= ~BOARD_NAND_ADDR_MASK; | |
| 340 | + this->legacy.IO_ADDR_W &= ~BOARD_NAND_ADDR_MASK; | |
| 341 | 341 | switch (chip) { |
| 342 | 342 | case 0: |
| 343 | − this->IO_ADDR_R |= BOARD_NAND_ADDR_CHIP0; | |
| 344 | − this->IO_ADDR_W |= BOARD_NAND_ADDR_CHIP0; | |
| 343 | + this->legacy.IO_ADDR_R |= BOARD_NAND_ADDR_CHIP0; | |
| 344 | + this->legacy.IO_ADDR_W |= BOARD_NAND_ADDR_CHIP0; | |
| 345 | 345 | break; |
| 346 | 346 | .... |
| 347 | 347 | case n: |
| 348 | − this->IO_ADDR_R |= BOARD_NAND_ADDR_CHIPn; | |
| 349 | − this->IO_ADDR_W |= BOARD_NAND_ADDR_CHIPn; | |
| 348 | + this->legacy.IO_ADDR_R |= BOARD_NAND_ADDR_CHIPn; | |
| 349 | + this->legacy.IO_ADDR_W |= BOARD_NAND_ADDR_CHIPn; | |
| 350 | 350 | break; |
| 351 | 351 | } |
| 352 | 352 | } |
| @@ -0,0 +1,22 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +============================================ | |
| 4 | +The Linux PCI driver implementer's API guide | |
| 5 | +============================================ | |
| 6 | + | |
| 7 | +.. class:: toc-title | |
| 8 | + | |
| 9 | + Table of contents | |
| 10 | + | |
| 11 | +.. toctree:: | |
| 12 | + :maxdepth: 2 | |
| 13 | + | |
| 14 | + pci | |
| 15 | + p2pdma | |
| 16 | + | |
| 17 | +.. only:: subproject and html | |
| 18 | + | |
| 19 | + Indices | |
| 20 | + ======= | |
| 21 | + | |
| 22 | + * :ref:`genindex` | |
| @@ -0,0 +1,145 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +============================ | |
| 4 | +PCI Peer-to-Peer DMA Support | |
| 5 | +============================ | |
| 6 | + | |
| 7 | +The PCI bus has pretty decent support for performing DMA transfers | |
| 8 | +between two devices on the bus. This type of transaction is henceforth | |
| 9 | +called Peer-to-Peer (or P2P). However, there are a number of issues that | |
| 10 | +make P2P transactions tricky to do in a perfectly safe way. | |
| 11 | + | |
| 12 | +One of the biggest issues is that PCI doesn't require forwarding | |
| 13 | +transactions between hierarchy domains, and in PCIe, each Root Port | |
| 14 | +defines a separate hierarchy domain. To make things worse, there is no | |
| 15 | +simple way to determine if a given Root Complex supports this or not. | |
| 16 | +(See PCIe r4.0, sec 1.3.1). Therefore, as of this writing, the kernel | |
| 17 | +only supports doing P2P when the endpoints involved are all behind the | |
| 18 | +same PCI bridge, as such devices are all in the same PCI hierarchy | |
| 19 | +domain, and the spec guarantees that all transactions within the | |
| 20 | +hierarchy will be routable, but it does not require routing | |
| 21 | +between hierarchies. | |
| 22 | + | |
| 23 | +The second issue is that to make use of existing interfaces in Linux, | |
| 24 | +memory that is used for P2P transactions needs to be backed by struct | |
| 25 | +pages. However, PCI BARs are not typically cache coherent so there are | |
| 26 | +a few corner case gotchas with these pages so developers need to | |
| 27 | +be careful about what they do with them. | |
| 28 | + | |
| 29 | + | |
| 30 | +Driver Writer's Guide | |
| 31 | +===================== | |
| 32 | + | |
| 33 | +In a given P2P implementation there may be three or more different | |
| 34 | +types of kernel drivers in play: | |
| 35 | + | |
| 36 | +* Provider - A driver which provides or publishes P2P resources like | |
| 37 | + memory or doorbell registers to other drivers. | |
| 38 | +* Client - A driver which makes use of a resource by setting up a | |
| 39 | + DMA transaction to or from it. | |
| 40 | +* Orchestrator - A driver which orchestrates the flow of data between | |
| 41 | + clients and providers. | |
| 42 | + | |
| 43 | +In many cases there could be overlap between these three types (i.e., | |
| 44 | +it may be typical for a driver to be both a provider and a client). | |
| 45 | + | |
| 46 | +For example, in the NVMe Target Copy Offload implementation: | |
| 47 | + | |
| 48 | +* The NVMe PCI driver is both a client, provider and orchestrator | |
| 49 | + in that it exposes any CMB (Controller Memory Buffer) as a P2P memory | |
| 50 | + resource (provider), it accepts P2P memory pages as buffers in requests | |
| 51 | + to be used directly (client) and it can also make use of the CMB as | |
| 52 | + submission queue entries (orchastrator). | |
| 53 | +* The RDMA driver is a client in this arrangement so that an RNIC | |
| 54 | + can DMA directly to the memory exposed by the NVMe device. | |
| 55 | +* The NVMe Target driver (nvmet) can orchestrate the data from the RNIC | |
| 56 | + to the P2P memory (CMB) and then to the NVMe device (and vice versa). | |
| 57 | + | |
| 58 | +This is currently the only arrangement supported by the kernel but | |
| 59 | +one could imagine slight tweaks to this that would allow for the same | |
| 60 | +functionality. For example, if a specific RNIC added a BAR with some | |
| 61 | +memory behind it, its driver could add support as a P2P provider and | |
| 62 | +then the NVMe Target could use the RNIC's memory instead of the CMB | |
| 63 | +in cases where the NVMe cards in use do not have CMB support. | |
| 64 | + | |
| 65 | + | |
| 66 | +Provider Drivers | |
| 67 | +---------------- | |
| 68 | + | |
| 69 | +A provider simply needs to register a BAR (or a portion of a BAR) | |
| 70 | +as a P2P DMA resource using :c:func:`pci_p2pdma_add_resource()`. | |
| 71 | +This will register struct pages for all the specified memory. | |
| 72 | + | |
| 73 | +After that it may optionally publish all of its resources as | |
| 74 | +P2P memory using :c:func:`pci_p2pmem_publish()`. This will allow | |
| 75 | +any orchestrator drivers to find and use the memory. When marked in | |
| 76 | +this way, the resource must be regular memory with no side effects. | |
| 77 | + | |
| 78 | +For the time being this is fairly rudimentary in that all resources | |
| 79 | +are typically going to be P2P memory. Future work will likely expand | |
| 80 | +this to include other types of resources like doorbells. | |
| 81 | + | |
| 82 | + | |
| 83 | +Client Drivers | |
| 84 | +-------------- | |
| 85 | + | |
| 86 | +A client driver typically only has to conditionally change its DMA map | |
| 87 | +routine to use the mapping function :c:func:`pci_p2pdma_map_sg()` instead | |
| 88 | +of the usual :c:func:`dma_map_sg()` function. Memory mapped in this | |
| 89 | +way does not need to be unmapped. | |
| 90 | + | |
| 91 | +The client may also, optionally, make use of | |
| 92 | +:c:func:`is_pci_p2pdma_page()` to determine when to use the P2P mapping | |
| 93 | +functions and when to use the regular mapping functions. In some | |
| 94 | +situations, it may be more appropriate to use a flag to indicate a | |
| 95 | +given request is P2P memory and map appropriately. It is important to | |
| 96 | +ensure that struct pages that back P2P memory stay out of code that | |
| 97 | +does not have support for them as other code may treat the pages as | |
| 98 | +regular memory which may not be appropriate. | |
| 99 | + | |
| 100 | + | |
| 101 | +Orchestrator Drivers | |
| 102 | +-------------------- | |
| 103 | + | |
| 104 | +The first task an orchestrator driver must do is compile a list of | |
| 105 | +all client devices that will be involved in a given transaction. For | |
| 106 | +example, the NVMe Target driver creates a list including the namespace | |
| 107 | +block device and the RNIC in use. If the orchestrator has access to | |
| 108 | +a specific P2P provider to use it may check compatibility using | |
| 109 | +:c:func:`pci_p2pdma_distance()` otherwise it may find a memory provider | |
| 110 | +that's compatible with all clients using :c:func:`pci_p2pmem_find()`. | |
| 111 | +If more than one provider is supported, the one nearest to all the clients will | |
| 112 | +be chosen first. If more than one provider is an equal distance away, the | |
| 113 | +one returned will be chosen at random (it is not an arbitrary but | |
| 114 | +truely random). This function returns the PCI device to use for the provider | |
| 115 | +with a reference taken and therefore when it's no longer needed it should be | |
| 116 | +returned with pci_dev_put(). | |
| 117 | + | |
| 118 | +Once a provider is selected, the orchestrator can then use | |
| 119 | +:c:func:`pci_alloc_p2pmem()` and :c:func:`pci_free_p2pmem()` to | |
| 120 | +allocate P2P memory from the provider. :c:func:`pci_p2pmem_alloc_sgl()` | |
| 121 | +and :c:func:`pci_p2pmem_free_sgl()` are convenience functions for | |
| 122 | +allocating scatter-gather lists with P2P memory. | |
| 123 | + | |
| 124 | +Struct Page Caveats | |
| 125 | +------------------- | |
| 126 | + | |
| 127 | +Driver writers should be very careful about not passing these special | |
| 128 | +struct pages to code that isn't prepared for it. At this time, the kernel | |
| 129 | +interfaces do not have any checks for ensuring this. This obviously | |
| 130 | +precludes passing these pages to userspace. | |
| 131 | + | |
| 132 | +P2P memory is also technically IO memory but should never have any side | |
| 133 | +effects behind it. Thus, the order of loads and stores should not be important | |
| 134 | +and ioreadX(), iowriteX() and friends should not be necessary. | |
| 135 | +However, as the memory is not cache coherent, if access ever needs to | |
| 136 | +be protected by a spinlock then :c:func:`mmiowb()` must be used before | |
| 137 | +unlocking the lock. (See ACQUIRES VS I/O ACCESSES in | |
| 138 | +Documentation/memory-barriers.txt) | |
| 139 | + | |
| 140 | + | |
| 141 | +P2P DMA Support Library | |
| 142 | +======================= | |
| 143 | + | |
| 144 | +.. kernel-doc:: drivers/pci/p2pdma.c | |
| 145 | + :export: | |
File renamed without changes.
| @@ -101,6 +101,34 @@ interface. :: · 100 unmodified lines | ||
| 101 | 101 | +--------------------+ | | |
| 102 | 102 | +----------------+ |
| 103 | 103 | |
| 104 | +Example 5: Stereo Stream with L and R channel is rendered by 2 Masters, each | |
| 105 | +rendering one channel, and is received by two different Slaves, each | |
| 106 | +receiving one channel. Both Masters and both Slaves are using single port. :: | |
| 107 | + | |
| 108 | + +---------------+ Clock Signal +---------------+ | |
| 109 | + | Master +----------------------------------+ Slave | | |
| 110 | + | Interface | | Interface | | |
| 111 | + | 1 | | 1 | | |
| 112 | + | | Data Signal | | | |
| 113 | + | L +----------------------------------+ L | | |
| 114 | + | (Data) | Data Direction | (Data) | | |
| 115 | + +---------------+ +-----------------------> +---------------+ | |
| 116 | + | |
| 117 | + +---------------+ Clock Signal +---------------+ | |
| 118 | + | Master +----------------------------------+ Slave | | |
| 119 | + | Interface | | Interface | | |
| 120 | + | 2 | | 2 | | |
| 121 | + | | Data Signal | | | |
| 122 | + | R +----------------------------------+ R | | |
| 123 | + | (Data) | Data Direction | (Data) | | |
| 124 | + +---------------+ +-----------------------> +---------------+ | |
| 125 | + | |
| 126 | +Note: In multi-link cases like above, to lock, one would acquire a global | |
| 127 | +lock and then go on locking bus instances. But, in this case the caller | |
| 128 | +framework(ASoC DPCM) guarantees that stream operations on a card are | |
| 129 | +always serialized. So, there is no race condition and hence no need for | |
| 130 | +global lock. | |
| 131 | + | |
| 104 | 132 | SoundWire Stream Management flow |
| 105 | 133 | ================================ |
| 106 | 134 | |
| @@ -174,6 +202,7 @@ per stream. From ASoC DPCM framework, this stream state maybe linked to · 67 unmodified lines | ||
| 174 | 202 | .startup() operation. |
| 175 | 203 | |
| 176 | 204 | .. code-block:: c |
| 205 | + | |
| 177 | 206 | int sdw_alloc_stream(char * stream_name); |
| 178 | 207 | |
| 179 | 208 | |
| @@ -200,6 +229,7 @@ only be invoked once by respective Master(s) and Slave(s). From ASoC DPCM · 20 unmodified lines | ||
| 200 | 229 | framework, this stream state is linked to .hw_params() operation. |
| 201 | 230 | |
| 202 | 231 | .. code-block:: c |
| 232 | + | |
| 203 | 233 | int sdw_stream_add_master(struct sdw_bus * bus, |
| 204 | 234 | struct sdw_stream_config * stream_config, |
| 205 | 235 | struct sdw_ports_config * ports_config, |
| @@ -245,6 +275,7 @@ stream. From ASoC DPCM framework, this stream state is linked to · 39 unmodified lines | ||
| 245 | 275 | .prepare() operation. |
| 246 | 276 | |
| 247 | 277 | .. code-block:: c |
| 278 | + | |
| 248 | 279 | int sdw_prepare_stream(struct sdw_stream_runtime * stream); |
| 249 | 280 | |
| 250 | 281 | |
| @@ -274,6 +305,7 @@ stream. From ASoC DPCM framework, this stream state is linked to · 23 unmodified lines | ||
| 274 | 305 | .trigger() start operation. |
| 275 | 306 | |
| 276 | 307 | .. code-block:: c |
| 308 | + | |
| 277 | 309 | int sdw_enable_stream(struct sdw_stream_runtime * stream); |
| 278 | 310 | |
| 279 | 311 | SDW_STREAM_DISABLED |
| @@ -301,6 +333,7 @@ per stream. From ASoC DPCM framework, this stream state is linked to · 21 unmodified lines | ||
| 301 | 333 | .trigger() stop operation. |
| 302 | 334 | |
| 303 | 335 | .. code-block:: c |
| 336 | + | |
| 304 | 337 | int sdw_disable_stream(struct sdw_stream_runtime * stream); |
| 305 | 338 | |
| 306 | 339 | |
| @@ -325,6 +358,7 @@ per stream. From ASoC DPCM framework, this stream state is linked to · 18 unmodified lines | ||
| 325 | 358 | .trigger() stop operation. |
| 326 | 359 | |
| 327 | 360 | .. code-block:: c |
| 361 | + | |
| 328 | 362 | int sdw_deprepare_stream(struct sdw_stream_runtime * stream); |
| 329 | 363 | |
| 330 | 364 | |
| @@ -349,6 +383,7 @@ all the Master(s) and Slave(s) associated with stream. From ASoC DPCM · 18 unmodified lines | ||
| 349 | 383 | framework, this stream state is linked to .hw_free() operation. |
| 350 | 384 | |
| 351 | 385 | .. code-block:: c |
| 386 | + | |
| 352 | 387 | int sdw_stream_remove_master(struct sdw_bus * bus, |
| 353 | 388 | struct sdw_stream_runtime * stream); |
| 354 | 389 | int sdw_stream_remove_slave(struct sdw_slave * slave, |
| @@ -361,6 +396,7 @@ stream assigned as part of ALLOCATED state. · 6 unmodified lines | ||
| 361 | 396 | In .shutdown() the data structure maintaining stream state are freed up. |
| 362 | 397 | |
| 363 | 398 | .. code-block:: c |
| 399 | + | |
| 364 | 400 | void sdw_release_stream(struct sdw_stream_runtime * stream); |
| 365 | 401 | |
| 366 | 402 | Not Supported |
| @@ -463,8 +463,8 @@ Getting information about your UIO device · 462 unmodified lines | ||
| 463 | 463 | |
| 464 | 464 | Information about all UIO devices is available in sysfs. The first thing |
| 465 | 465 | you should do in your driver is check ``name`` and ``version`` to make |
| 466 | −sure your talking to the right device and that its kernel driver has the | |
| 467 | −version you expect. | |
| 466 | +sure you're talking to the right device and that its kernel driver has | |
| 467 | +the version you expect. | |
| 468 | 468 | |
| 469 | 469 | You should also make sure that the memory mapping you need exists and |
| 470 | 470 | has the size you expect. |
| @@ -83,7 +83,18 @@ is passed to bzImage.efi. · 82 unmodified lines | ||
| 83 | 83 | The "dtb=" option |
| 84 | 84 | ----------------- |
| 85 | 85 | |
| 86 | −For the ARM and arm64 architectures, we also need to be able to provide a | |
| 87 | −device tree to the kernel. This is done with the "dtb=" command line option, | |
| 88 | −and is processed in the same manner as the "initrd=" option that is | |
| 86 | +For the ARM and arm64 architectures, a device tree must be provided to | |
| 87 | +the kernel. Normally firmware shall supply the device tree via the | |
| 88 | +EFI CONFIGURATION TABLE. However, the "dtb=" command line option can | |
| 89 | +be used to override the firmware supplied device tree, or to supply | |
| 90 | +one when firmware is unable to. | |
| 91 | + | |
| 92 | +Please note: Firmware adds runtime configuration information to the | |
| 93 | +device tree before booting the kernel. If dtb= is used to override | |
| 94 | +the device tree, then any runtime data provided by firmware will be | |
| 95 | +lost. The dtb= option should only be used either as a debug tool, or | |
| 96 | +as a last resort when a device tree is not provided in the EFI | |
| 97 | +CONFIGURATION TABLE. | |
| 98 | + | |
| 99 | +"dtb=" is processed in the same manner as the "initrd=" option that is | |
| 89 | 100 | described above. |
| @@ -1,75 +0,0 @@ | ||
| 1 | −Index of files in Documentation/fb. If you think something about frame | |
| 2 | −buffer devices needs an entry here, needs correction or you've written one | |
| 3 | −please mail me. | |
| 4 | − Geert Uytterhoeven <geert@linux-m68k.org> | |
| 5 | − | |
| 6 | −00-INDEX | |
| 7 | − - this file. | |
| 8 | −api.txt | |
| 9 | − - The frame buffer API between applications and buffer devices. | |
| 10 | −arkfb.txt | |
| 11 | − - info on the fbdev driver for ARK Logic chips. | |
| 12 | −aty128fb.txt | |
| 13 | − - info on the ATI Rage128 frame buffer driver. | |
| 14 | −cirrusfb.txt | |
| 15 | − - info on the driver for Cirrus Logic chipsets. | |
| 16 | −cmap_xfbdev.txt | |
| 17 | − - an introduction to fbdev's cmap structures. | |
| 18 | −deferred_io.txt | |
| 19 | − - an introduction to deferred IO. | |
| 20 | −efifb.txt | |
| 21 | − - info on the EFI platform driver for Intel based Apple computers. | |
| 22 | −ep93xx-fb.txt | |
| 23 | − - info on the driver for EP93xx LCD controller. | |
| 24 | −fbcon.txt | |
| 25 | − - intro to and usage guide for the framebuffer console (fbcon). | |
| 26 | −framebuffer.txt | |
| 27 | − - introduction to frame buffer devices. | |
| 28 | −gxfb.txt | |
| 29 | − - info on the framebuffer driver for AMD Geode GX2 based processors. | |
| 30 | −intel810.txt | |
| 31 | − - documentation for the Intel 810/815 framebuffer driver. | |
| 32 | −intelfb.txt | |
| 33 | − - docs for Intel 830M/845G/852GM/855GM/865G/915G/945G fb driver. | |
| 34 | −internals.txt | |
| 35 | − - quick overview of frame buffer device internals. | |
| 36 | −lxfb.txt | |
| 37 | − - info on the framebuffer driver for AMD Geode LX based processors. | |
| 38 | −matroxfb.txt | |
| 39 | − - info on the Matrox framebuffer driver for Alpha, Intel and PPC. | |
| 40 | −metronomefb.txt | |
| 41 | − - info on the driver for the Metronome display controller. | |
| 42 | −modedb.txt | |
| 43 | − - info on the video mode database. | |
| 44 | −pvr2fb.txt | |
| 45 | − - info on the PowerVR 2 frame buffer driver. | |
| 46 | −pxafb.txt | |
| 47 | − - info on the driver for the PXA25x LCD controller. | |
| 48 | −s3fb.txt | |
| 49 | − - info on the fbdev driver for S3 Trio/Virge chips. | |
| 50 | −sa1100fb.txt | |
| 51 | − - information about the driver for the SA-1100 LCD controller. | |
| 52 | −sh7760fb.txt | |
| 53 | − - info on the SH7760/SH7763 integrated LCDC Framebuffer driver. | |
| 54 | −sisfb.txt | |
| 55 | − - info on the framebuffer device driver for various SiS chips. | |
| 56 | −sm501.txt | |
| 57 | − - info on the framebuffer device driver for sm501 videoframebuffer. | |
| 58 | −sstfb.txt | |
| 59 | − - info on the frame buffer driver for 3dfx' Voodoo Graphics boards. | |
| 60 | −tgafb.txt | |
| 61 | − - info on the TGA (DECChip 21030) frame buffer driver. | |
| 62 | −tridentfb.txt | |
| 63 | − info on the framebuffer driver for some Trident chip based cards. | |
| 64 | −udlfb.txt | |
| 65 | − - Driver for DisplayLink USB 2.0 chips. | |
| 66 | −uvesafb.txt | |
| 67 | − - info on the userspace VESA (VBE2+ compliant) frame buffer device. | |
| 68 | −vesafb.txt | |
| 69 | − - info on the VESA frame buffer device. | |
| 70 | −viafb.modes | |
| 71 | − - list of modes for VIA Integration Graphic Chip. | |
| 72 | −viafb.txt | |
| 73 | − - info on the VIA Integration Graphic Chip console framebuffer driver. | |
| 74 | −vt8623fb.txt | |
| 75 | − - info on the fb driver for the graphics core in VIA VT8623 chipsets. | |
| @@ -15,7 +15,8 @@ than x86. Check the v86d documentation for a list of currently supported · 14 unmodified lines | ||
| 15 | 15 | arches. |
| 16 | 16 | |
| 17 | 17 | v86d source code can be downloaded from the following website: |
| 18 | − http://dev.gentoo.org/~spock/projects/uvesafb | |
| 18 | + | |
| 19 | + https://github.com/mjanusz/v86d | |
| 19 | 20 | |
| 20 | 21 | Please refer to the v86d documentation for detailed configuration and |
| 21 | 22 | installation instructions. |
| @@ -177,7 +178,7 @@ from the Video BIOS if you set pixclock to 0 in fb_var_screeninfo. · 155 unmodified lines | ||
| 177 | 178 | |
| 178 | 179 | -- |
| 179 | 180 | Michal Januszewski <spock@gentoo.org> |
| 180 | − Last updated: 2009-03-30 | |
| 181 | + Last updated: 2017-10-10 | |
| 181 | 182 | |
| 182 | 183 | Documentation of the uvesafb options is loosely based on vesafb.txt. |
| 183 | 184 | |
| @@ -114,11 +114,11 @@ to turn it on. · 113 unmodified lines | ||
| 114 | 114 | |
| 115 | 115 | You can pass options to vesafb using "video=vesafb:option" on |
| 116 | 116 | the kernel command line. Multiple options should be separated |
| 117 | −by comma, like this: "video=vesafb:ypan,invers" | |
| 117 | +by comma, like this: "video=vesafb:ypan,inverse" | |
| 118 | 118 | |
| 119 | 119 | Accepted options: |
| 120 | 120 | |
| 121 | −invers no comment... | |
| 121 | +inverse use inverse color map | |
| 122 | 122 | |
| 123 | 123 | ypan enable display panning using the VESA protected mode |
| 124 | 124 | interface. The visible screen is just a window of the |
| @@ -1,153 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - this file (info on some of the filesystems supported by linux). | |
| 3 | −Locking | |
| 4 | − - info on locking rules as they pertain to Linux VFS. | |
| 5 | −9p.txt | |
| 6 | − - 9p (v9fs) is an implementation of the Plan 9 remote fs protocol. | |
| 7 | −adfs.txt | |
| 8 | − - info and mount options for the Acorn Advanced Disc Filing System. | |
| 9 | −afs.txt | |
| 10 | − - info and examples for the distributed AFS (Andrew File System) fs. | |
| 11 | −affs.txt | |
| 12 | − - info and mount options for the Amiga Fast File System. | |
| 13 | −autofs-mount-control.txt | |
| 14 | − - info on device control operations for autofs module. | |
| 15 | −automount-support.txt | |
| 16 | − - information about filesystem automount support. | |
| 17 | −befs.txt | |
| 18 | − - information about the BeOS filesystem for Linux. | |
| 19 | −bfs.txt | |
| 20 | − - info for the SCO UnixWare Boot Filesystem (BFS). | |
| 21 | −btrfs.txt | |
| 22 | − - info for the BTRFS filesystem. | |
| 23 | −caching/ | |
| 24 | − - directory containing filesystem cache documentation. | |
| 25 | −ceph.txt | |
| 26 | − - info for the Ceph Distributed File System. | |
| 27 | −cifs/ | |
| 28 | − - directory containing CIFS filesystem documentation and example code. | |
| 29 | −coda.txt | |
| 30 | − - description of the CODA filesystem. | |
| 31 | −configfs/ | |
| 32 | − - directory containing configfs documentation and example code. | |
| 33 | −cramfs.txt | |
| 34 | − - info on the cram filesystem for small storage (ROMs etc). | |
| 35 | −dax.txt | |
| 36 | − - info on avoiding the page cache for files stored on CPU-addressable | |
| 37 | − storage devices. | |
| 38 | −debugfs.txt | |
| 39 | − - info on the debugfs filesystem. | |
| 40 | −devpts.txt | |
| 41 | − - info on the devpts filesystem. | |
| 42 | −directory-locking | |
| 43 | − - info about the locking scheme used for directory operations. | |
| 44 | −dlmfs.txt | |
| 45 | − - info on the userspace interface to the OCFS2 DLM. | |
| 46 | −dnotify.txt | |
| 47 | − - info about directory notification in Linux. | |
| 48 | −dnotify_test.c | |
| 49 | − - example program for dnotify. | |
| 50 | −ecryptfs.txt | |
| 51 | − - docs on eCryptfs: stacked cryptographic filesystem for Linux. | |
| 52 | −efivarfs.txt | |
| 53 | − - info for the efivarfs filesystem. | |
| 54 | −exofs.txt | |
| 55 | − - info, usage, mount options, design about EXOFS. | |
| 56 | −ext2.txt | |
| 57 | − - info, mount options and specifications for the Ext2 filesystem. | |
| 58 | −ext3.txt | |
| 59 | − - info, mount options and specifications for the Ext3 filesystem. | |
| 60 | −ext4.txt | |
| 61 | − - info, mount options and specifications for the Ext4 filesystem. | |
| 62 | −f2fs.txt | |
| 63 | − - info and mount options for the F2FS filesystem. | |
| 64 | −fiemap.txt | |
| 65 | − - info on fiemap ioctl. | |
| 66 | −files.txt | |
| 67 | − - info on file management in the Linux kernel. | |
| 68 | −fuse.txt | |
| 69 | − - info on the Filesystem in User SpacE including mount options. | |
| 70 | −gfs2-glocks.txt | |
| 71 | − - info on the Global File System 2 - Glock internal locking rules. | |
| 72 | −gfs2-uevents.txt | |
| 73 | − - info on the Global File System 2 - uevents. | |
| 74 | −gfs2.txt | |
| 75 | − - info on the Global File System 2. | |
| 76 | −hfs.txt | |
| 77 | − - info on the Macintosh HFS Filesystem for Linux. | |
| 78 | −hfsplus.txt | |
| 79 | − - info on the Macintosh HFSPlus Filesystem for Linux. | |
| 80 | −hpfs.txt | |
| 81 | − - info and mount options for the OS/2 HPFS. | |
| 82 | −inotify.txt | |
| 83 | − - info on the powerful yet simple file change notification system. | |
| 84 | −isofs.txt | |
| 85 | − - info and mount options for the ISO 9660 (CDROM) filesystem. | |
| 86 | −jfs.txt | |
| 87 | − - info and mount options for the JFS filesystem. | |
| 88 | −locks.txt | |
| 89 | − - info on file locking implementations, flock() vs. fcntl(), etc. | |
| 90 | −mandatory-locking.txt | |
| 91 | − - info on the Linux implementation of Sys V mandatory file locking. | |
| 92 | −nfs/ | |
| 93 | − - nfs-related documentation. | |
| 94 | −nilfs2.txt | |
| 95 | − - info and mount options for the NILFS2 filesystem. | |
| 96 | −ntfs.txt | |
| 97 | − - info and mount options for the NTFS filesystem (Windows NT). | |
| 98 | −ocfs2.txt | |
| 99 | − - info and mount options for the OCFS2 clustered filesystem. | |
| 100 | −omfs.txt | |
| 101 | − - info on the Optimized MPEG FileSystem. | |
| 102 | −path-lookup.txt | |
| 103 | − - info on path walking and name lookup locking. | |
| 104 | −pohmelfs/ | |
| 105 | − - directory containing pohmelfs filesystem documentation. | |
| 106 | −porting | |
| 107 | − - various information on filesystem porting. | |
| 108 | −proc.txt | |
| 109 | − - info on Linux's /proc filesystem. | |
| 110 | −qnx6.txt | |
| 111 | − - info on the QNX6 filesystem. | |
| 112 | −quota.txt | |
| 113 | − - info on Quota subsystem. | |
| 114 | −ramfs-rootfs-initramfs.txt | |
| 115 | − - info on the 'in memory' filesystems ramfs, rootfs and initramfs. | |
| 116 | −relay.txt | |
| 117 | − - info on relay, for efficient streaming from kernel to user space. | |
| 118 | −romfs.txt | |
| 119 | − - description of the ROMFS filesystem. | |
| 120 | −seq_file.txt | |
| 121 | − - how to use the seq_file API. | |
| 122 | −sharedsubtree.txt | |
| 123 | − - a description of shared subtrees for namespaces. | |
| 124 | −spufs.txt | |
| 125 | − - info and mount options for the SPU filesystem used on Cell. | |
| 126 | −squashfs.txt | |
| 127 | − - info on the squashfs filesystem. | |
| 128 | −sysfs-pci.txt | |
| 129 | − - info on accessing PCI device resources through sysfs. | |
| 130 | −sysfs-tagging.txt | |
| 131 | − - info on sysfs tagging to avoid duplicates. | |
| 132 | −sysfs.txt | |
| 133 | − - info on sysfs, a ram-based filesystem for exporting kernel objects. | |
| 134 | −sysv-fs.txt | |
| 135 | − - info on the SystemV/V7/Xenix/Coherent filesystem. | |
| 136 | −tmpfs.txt | |
| 137 | − - info on tmpfs, a filesystem that holds all files in virtual memory. | |
| 138 | −ubifs.txt | |
| 139 | − - info on the Unsorted Block Images FileSystem. | |
| 140 | −udf.txt | |
| 141 | − - info and mount options for the UDF filesystem. | |
| 142 | −ufs.txt | |
| 143 | − - info on the ufs filesystem. | |
| 144 | −vfat.txt | |
| 145 | − - info on using the VFAT filesystem used in Windows NT and Windows 95. | |
| 146 | −vfs.txt | |
| 147 | − - overview of the Virtual File System. | |
| 148 | −xfs-delayed-logging-design.txt | |
| 149 | − - info on the XFS Delayed Logging Design. | |
| 150 | −xfs-self-describing-metadata.txt | |
| 151 | − - info on XFS Self Describing Metadata. | |
| 152 | −xfs.txt | |
| 153 | − - info and mount options for the XFS filesystem. | |
| @@ -151,6 +151,11 @@ Mount Options · 150 unmodified lines | ||
| 151 | 151 | Report overall filesystem usage in statfs instead of using the root |
| 152 | 152 | directory quota. |
| 153 | 153 | |
| 154 | + nocopyfrom | |
| 155 | + Don't use the RADOS 'copy-from' operation to perform remote object | |
| 156 | + copies. Currently, it's only used in copy_file_range, which will revert | |
| 157 | + to the default VFS implementation if this option is used. | |
| 158 | + | |
| 154 | 159 | More Information |
| 155 | 160 | ================ |
| 156 | 161 | |
| @@ -75,7 +75,7 @@ exposure of uninitialized data through mmap. · 74 unmodified lines | ||
| 75 | 75 | |
| 76 | 76 | These filesystems may be used for inspiration: |
| 77 | 77 | - ext2: see Documentation/filesystems/ext2.txt |
| 78 | −- ext4: see Documentation/filesystems/ext4.txt | |
| 78 | +- ext4: see Documentation/filesystems/ext4/ext4.rst | |
| 79 | 79 | - xfs: see Documentation/filesystems/xfs.txt |
| 80 | 80 | |
| 81 | 81 | |
| @@ -358,7 +358,7 @@ and are copied into the filesystem. If a transaction is incomplete at · 357 unmodified lines | ||
| 358 | 358 | the time of the crash, then there is no guarantee of consistency for |
| 359 | 359 | the blocks in that transaction so they are discarded (which means any |
| 360 | 360 | filesystem changes they represent are also lost). |
| 361 | −Check Documentation/filesystems/ext4.txt if you want to read more about | |
| 361 | +Check Documentation/filesystems/ext4/ext4.rst if you want to read more about | |
| 362 | 362 | ext4 and journaling. |
| 363 | 363 | |
| 364 | 364 | References |
File renamed without changes.
File renamed without changes.
| @@ -30,7 +30,7 @@ Extended attributes, when stored after the inode, have a header · 29 unmodified lines | ||
| 30 | 30 | ``ext4_xattr_ibody_header`` that is 4 bytes long: |
| 31 | 31 | |
| 32 | 32 | .. list-table:: |
| 33 | − :widths: 1 1 1 77 | |
| 33 | + :widths: 8 8 24 40 | |
| 34 | 34 | :header-rows: 1 |
| 35 | 35 | |
| 36 | 36 | * - Offset |
| @@ -47,7 +47,7 @@ The beginning of an extended attribute block is in · 10 unmodified lines | ||
| 47 | 47 | ``struct ext4_xattr_header``, which is 32 bytes long: |
| 48 | 48 | |
| 49 | 49 | .. list-table:: |
| 50 | − :widths: 1 1 1 77 | |
| 50 | + :widths: 8 8 24 40 | |
| 51 | 51 | :header-rows: 1 |
| 52 | 52 | |
| 53 | 53 | * - Offset |
| @@ -92,7 +92,7 @@ entries must be stored in sorted order. The sort order is · 38 unmodified lines | ||
| 92 | 92 | Attributes stored inside an inode do not need be stored in sorted order. |
| 93 | 93 | |
| 94 | 94 | .. list-table:: |
| 95 | − :widths: 1 1 1 77 | |
| 95 | + :widths: 8 8 24 40 | |
| 96 | 96 | :header-rows: 1 |
| 97 | 97 | |
| 98 | 98 | * - Offset |
| @@ -157,7 +157,7 @@ attribute name index field is set, and matching string is removed from · 58 unmodified lines | ||
| 157 | 157 | the key name. Here is a map of name index values to key prefixes: |
| 158 | 158 | |
| 159 | 159 | .. list-table:: |
| 160 | − :widths: 1 79 | |
| 160 | + :widths: 16 64 | |
| 161 | 161 | :header-rows: 1 |
| 162 | 162 | |
| 163 | 163 | * - Name Index |
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
| @@ -28,7 +28,7 @@ of checksum. The checksum function is whatever the superblock describes · 27 unmodified lines | ||
| 28 | 28 | (crc32c as of October 2013) unless noted otherwise. |
| 29 | 29 | |
| 30 | 30 | .. list-table:: |
| 31 | − :widths: 1 1 4 | |
| 31 | + :widths: 20 8 50 | |
| 32 | 32 | :header-rows: 1 |
| 33 | 33 | |
| 34 | 34 | * - Metadata |
| @@ -34,7 +34,7 @@ is at most 263 bytes long, though on disk you'll need to reference · 33 unmodified lines | ||
| 34 | 34 | ``dirent.rec_len`` to know for sure. |
| 35 | 35 | |
| 36 | 36 | .. list-table:: |
| 37 | − :widths: 1 1 1 77 | |
| 37 | + :widths: 8 8 24 40 | |
| 38 | 38 | :header-rows: 1 |
| 39 | 39 | |
| 40 | 40 | * - Offset |
| @@ -66,7 +66,7 @@ tree traversal. This format is ``ext4_dir_entry_2``, which is at most · 25 unmodified lines | ||
| 66 | 66 | ``dirent.rec_len`` to know for sure. |
| 67 | 67 | |
| 68 | 68 | .. list-table:: |
| 69 | − :widths: 1 1 1 77 | |
| 69 | + :widths: 8 8 24 40 | |
| 70 | 70 | :header-rows: 1 |
| 71 | 71 | |
| 72 | 72 | * - Offset |
| @@ -99,7 +99,7 @@ tree traversal. This format is ``ext4_dir_entry_2``, which is at most · 26 unmodified lines | ||
| 99 | 99 | The directory file type is one of the following values: |
| 100 | 100 | |
| 101 | 101 | .. list-table:: |
| 102 | − :widths: 1 79 | |
| 102 | + :widths: 16 64 | |
| 103 | 103 | :header-rows: 1 |
| 104 | 104 | |
| 105 | 105 | * - Value |
| @@ -130,7 +130,7 @@ in the place where the name normally goes. The structure is · 24 unmodified lines | ||
| 130 | 130 | ``struct ext4_dir_entry_tail``: |
| 131 | 131 | |
| 132 | 132 | .. list-table:: |
| 133 | − :widths: 1 1 1 77 | |
| 133 | + :widths: 8 8 24 40 | |
| 134 | 134 | :header-rows: 1 |
| 135 | 135 | |
| 136 | 136 | * - Offset |
| @@ -212,7 +212,7 @@ The root of the htree is in ``struct dx_root``, which is the full length · 75 unmodified lines | ||
| 212 | 212 | of a data block: |
| 213 | 213 | |
| 214 | 214 | .. list-table:: |
| 215 | − :widths: 1 1 1 77 | |
| 215 | + :widths: 8 8 24 40 | |
| 216 | 216 | :header-rows: 1 |
| 217 | 217 | |
| 218 | 218 | * - Offset |
| @@ -305,7 +305,7 @@ of a data block: · 86 unmodified lines | ||
| 305 | 305 | The directory hash is one of the following values: |
| 306 | 306 | |
| 307 | 307 | .. list-table:: |
| 308 | − :widths: 1 79 | |
| 308 | + :widths: 16 64 | |
| 309 | 309 | :header-rows: 1 |
| 310 | 310 | |
| 311 | 311 | * - Value |
| @@ -327,7 +327,7 @@ Interior nodes of an htree are recorded as ``struct dx_node``, which is · 15 unmodified lines | ||
| 327 | 327 | also the full length of a data block: |
| 328 | 328 | |
| 329 | 329 | .. list-table:: |
| 330 | − :widths: 1 1 1 77 | |
| 330 | + :widths: 8 8 24 40 | |
| 331 | 331 | :header-rows: 1 |
| 332 | 332 | |
| 333 | 333 | * - Offset |
| @@ -375,7 +375,7 @@ The hash maps that exist in both ``struct dx_root`` and · 41 unmodified lines | ||
| 375 | 375 | long: |
| 376 | 376 | |
| 377 | 377 | .. list-table:: |
| 378 | − :widths: 1 1 1 77 | |
| 378 | + :widths: 8 8 24 40 | |
| 379 | 379 | :header-rows: 1 |
| 380 | 380 | |
| 381 | 381 | * - Offset |
| @@ -405,7 +405,7 @@ directory index (which will ensure that there's space for the checksum. · 23 unmodified lines | ||
| 405 | 405 | The dx\_tail structure is 8 bytes long and looks like this: |
| 406 | 406 | |
| 407 | 407 | .. list-table:: |
| 408 | − :widths: 1 1 1 77 | |
| 408 | + :widths: 8 8 24 40 | |
| 409 | 409 | :header-rows: 1 |
| 410 | 410 | |
| 411 | 411 | * - Offset |
File renamed without changes.
File renamed without changes.
| @@ -1,613 +0,0 @@ | ||
| 1 | −.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | − | |
| 3 | −======================== | |
| 4 | −General Information | |
| 5 | −======================== | |
| 6 | − | |
| 7 | −Ext4 is an advanced level of the ext3 filesystem which incorporates | |
| 8 | −scalability and reliability enhancements for supporting large filesystems | |
| 9 | −(64 bit) in keeping with increasing disk capacities and state-of-the-art | |
| 10 | −feature requirements. | |
| 11 | − | |
| 12 | −Mailing list: linux-ext4@vger.kernel.org | |
| 13 | −Web site: http://ext4.wiki.kernel.org | |
| 14 | − | |
| 15 | − | |
| 16 | −Quick usage instructions | |
| 17 | −======================== | |
| 18 | − | |
| 19 | −Note: More extensive information for getting started with ext4 can be | |
| 20 | −found at the ext4 wiki site at the URL: | |
| 21 | −http://ext4.wiki.kernel.org/index.php/Ext4_Howto | |
| 22 | − | |
| 23 | − - The latest version of e2fsprogs can be found at: | |
| 24 | − | |
| 25 | − https://www.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/ | |
| 26 | − | |
| 27 | − or | |
| 28 | − | |
| 29 | − http://sourceforge.net/project/showfiles.php?group_id=2406 | |
| 30 | − | |
| 31 | − or grab the latest git repository from: | |
| 32 | − | |
| 33 | − https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git | |
| 34 | − | |
| 35 | − - Create a new filesystem using the ext4 filesystem type: | |
| 36 | − | |
| 37 | − # mke2fs -t ext4 /dev/hda1 | |
| 38 | − | |
| 39 | − Or to configure an existing ext3 filesystem to support extents: | |
| 40 | − | |
| 41 | − # tune2fs -O extents /dev/hda1 | |
| 42 | − | |
| 43 | − If the filesystem was created with 128 byte inodes, it can be | |
| 44 | − converted to use 256 byte for greater efficiency via: | |
| 45 | − | |
| 46 | − # tune2fs -I 256 /dev/hda1 | |
| 47 | − | |
| 48 | − - Mounting: | |
| 49 | − | |
| 50 | − # mount -t ext4 /dev/hda1 /wherever | |
| 51 | − | |
| 52 | − - When comparing performance with other filesystems, it's always | |
| 53 | − important to try multiple workloads; very often a subtle change in a | |
| 54 | − workload parameter can completely change the ranking of which | |
| 55 | − filesystems do well compared to others. When comparing versus ext3, | |
| 56 | − note that ext4 enables write barriers by default, while ext3 does | |
| 57 | − not enable write barriers by default. So it is useful to use | |
| 58 | − explicitly specify whether barriers are enabled or not when via the | |
| 59 | − '-o barriers=[0|1]' mount option for both ext3 and ext4 filesystems | |
| 60 | − for a fair comparison. When tuning ext3 for best benchmark numbers, | |
| 61 | − it is often worthwhile to try changing the data journaling mode; '-o | |
| 62 | − data=writeback' can be faster for some workloads. (Note however that | |
| 63 | − running mounted with data=writeback can potentially leave stale data | |
| 64 | − exposed in recently written files in case of an unclean shutdown, | |
| 65 | − which could be a security exposure in some situations.) Configuring | |
| 66 | − the filesystem with a large journal can also be helpful for | |
| 67 | − metadata-intensive workloads. | |
| 68 | − | |
| 69 | −Features | |
| 70 | −======== | |
| 71 | − | |
| 72 | −Currently Available | |
| 73 | −------------------- | |
| 74 | − | |
| 75 | −* ability to use filesystems > 16TB (e2fsprogs support not available yet) | |
| 76 | −* extent format reduces metadata overhead (RAM, IO for access, transactions) | |
| 77 | −* extent format more robust in face of on-disk corruption due to magics, | |
| 78 | −* internal redundancy in tree | |
| 79 | −* improved file allocation (multi-block alloc) | |
| 80 | −* lift 32000 subdirectory limit imposed by i_links_count[1] | |
| 81 | −* nsec timestamps for mtime, atime, ctime, create time | |
| 82 | −* inode version field on disk (NFSv4, Lustre) | |
| 83 | −* reduced e2fsck time via uninit_bg feature | |
| 84 | −* journal checksumming for robustness, performance | |
| 85 | −* persistent file preallocation (e.g for streaming media, databases) | |
| 86 | −* ability to pack bitmaps and inode tables into larger virtual groups via the | |
| 87 | − flex_bg feature | |
| 88 | −* large file support | |
| 89 | −* inode allocation using large virtual block groups via flex_bg | |
| 90 | −* delayed allocation | |
| 91 | −* large block (up to pagesize) support | |
| 92 | −* efficient new ordered mode in JBD2 and ext4 (avoid using buffer head to force | |
| 93 | − the ordering) | |
| 94 | − | |
| 95 | −[1] Filesystems with a block size of 1k may see a limit imposed by the | |
| 96 | −directory hash tree having a maximum depth of two. | |
| 97 | − | |
| 98 | −Options | |
| 99 | −======= | |
| 100 | − | |
| 101 | −When mounting an ext4 filesystem, the following option are accepted: | |
| 102 | −(*) == default | |
| 103 | − | |
| 104 | −======================= ======================================================= | |
| 105 | −Mount Option Description | |
| 106 | −======================= ======================================================= | |
| 107 | −ro Mount filesystem read only. Note that ext4 will | |
| 108 | − replay the journal (and thus write to the | |
| 109 | − partition) even when mounted "read only". The | |
| 110 | − mount options "ro,noload" can be used to prevent | |
| 111 | − writes to the filesystem. | |
| 112 | − | |
| 113 | −journal_checksum Enable checksumming of the journal transactions. | |
| 114 | − This will allow the recovery code in e2fsck and the | |
| 115 | − kernel to detect corruption in the kernel. It is a | |
| 116 | − compatible change and will be ignored by older kernels. | |
| 117 | − | |
| 118 | −journal_async_commit Commit block can be written to disk without waiting | |
| 119 | − for descriptor blocks. If enabled older kernels cannot | |
| 120 | − mount the device. This will enable 'journal_checksum' | |
| 121 | − internally. | |
| 122 | − | |
| 123 | −journal_path=path | |
| 124 | −journal_dev=devnum When the external journal device's major/minor numbers | |
| 125 | − have changed, these options allow the user to specify | |
| 126 | − the new journal location. The journal device is | |
| 127 | − identified through either its new major/minor numbers | |
| 128 | − encoded in devnum, or via a path to the device. | |
| 129 | − | |
| 130 | −norecovery Don't load the journal on mounting. Note that | |
| 131 | −noload if the filesystem was not unmounted cleanly, | |
| 132 | − skipping the journal replay will lead to the | |
| 133 | − filesystem containing inconsistencies that can | |
| 134 | − lead to any number of problems. | |
| 135 | − | |
| 136 | −data=journal All data are committed into the journal prior to being | |
| 137 | − written into the main file system. Enabling | |
| 138 | − this mode will disable delayed allocation and | |
| 139 | − O_DIRECT support. | |
| 140 | − | |
| 141 | −data=ordered (*) All data are forced directly out to the main file | |
| 142 | − system prior to its metadata being committed to the | |
| 143 | − journal. | |
| 144 | − | |
| 145 | −data=writeback Data ordering is not preserved, data may be written | |
| 146 | − into the main file system after its metadata has been | |
| 147 | − committed to the journal. | |
| 148 | − | |
| 149 | −commit=nrsec (*) Ext4 can be told to sync all its data and metadata | |
| 150 | − every 'nrsec' seconds. The default value is 5 seconds. | |
| 151 | − This means that if you lose your power, you will lose | |
| 152 | − as much as the latest 5 seconds of work (your | |
| 153 | − filesystem will not be damaged though, thanks to the | |
| 154 | − journaling). This default value (or any low value) | |
| 155 | − will hurt performance, but it's good for data-safety. | |
| 156 | − Setting it to 0 will have the same effect as leaving | |
| 157 | − it at the default (5 seconds). | |
| 158 | − Setting it to very large values will improve | |
| 159 | − performance. | |
| 160 | − | |
| 161 | −barrier=<0|1(*)> This enables/disables the use of write barriers in | |
| 162 | −barrier(*) the jbd code. barrier=0 disables, barrier=1 enables. | |
| 163 | −nobarrier This also requires an IO stack which can support | |
| 164 | − barriers, and if jbd gets an error on a barrier | |
| 165 | − write, it will disable again with a warning. | |
| 166 | − Write barriers enforce proper on-disk ordering | |
| 167 | − of journal commits, making volatile disk write caches | |
| 168 | − safe to use, at some performance penalty. If | |
| 169 | − your disks are battery-backed in one way or another, | |
| 170 | − disabling barriers may safely improve performance. | |
| 171 | − The mount options "barrier" and "nobarrier" can | |
| 172 | − also be used to enable or disable barriers, for | |
| 173 | − consistency with other ext4 mount options. | |
| 174 | − | |
| 175 | −inode_readahead_blks=n This tuning parameter controls the maximum | |
| 176 | − number of inode table blocks that ext4's inode | |
| 177 | − table readahead algorithm will pre-read into | |
| 178 | − the buffer cache. The default value is 32 blocks. | |
| 179 | − | |
| 180 | −nouser_xattr Disables Extended User Attributes. See the | |
| 181 | − attr(5) manual page for more information about | |
| 182 | − extended attributes. | |
| 183 | − | |
| 184 | −noacl This option disables POSIX Access Control List | |
| 185 | − support. If ACL support is enabled in the kernel | |
| 186 | − configuration (CONFIG_EXT4_FS_POSIX_ACL), ACL is | |
| 187 | − enabled by default on mount. See the acl(5) manual | |
| 188 | − page for more information about acl. | |
| 189 | − | |
| 190 | −bsddf (*) Make 'df' act like BSD. | |
| 191 | −minixdf Make 'df' act like Minix. | |
| 192 | − | |
| 193 | −debug Extra debugging information is sent to syslog. | |
| 194 | − | |
| 195 | −abort Simulate the effects of calling ext4_abort() for | |
| 196 | − debugging purposes. This is normally used while | |
| 197 | − remounting a filesystem which is already mounted. | |
| 198 | − | |
| 199 | −errors=remount-ro Remount the filesystem read-only on an error. | |
| 200 | −errors=continue Keep going on a filesystem error. | |
| 201 | −errors=panic Panic and halt the machine if an error occurs. | |
| 202 | − (These mount options override the errors behavior | |
| 203 | − specified in the superblock, which can be configured | |
| 204 | − using tune2fs) | |
| 205 | − | |
| 206 | −data_err=ignore(*) Just print an error message if an error occurs | |
| 207 | − in a file data buffer in ordered mode. | |
| 208 | −data_err=abort Abort the journal if an error occurs in a file | |
| 209 | − data buffer in ordered mode. | |
| 210 | − | |
| 211 | −grpid New objects have the group ID of their parent. | |
| 212 | −bsdgroups | |
| 213 | − | |
| 214 | −nogrpid (*) New objects have the group ID of their creator. | |
| 215 | −sysvgroups | |
| 216 | − | |
| 217 | −resgid=n The group ID which may use the reserved blocks. | |
| 218 | − | |
| 219 | −resuid=n The user ID which may use the reserved blocks. | |
| 220 | − | |
| 221 | −sb=n Use alternate superblock at this location. | |
| 222 | − | |
| 223 | −quota These options are ignored by the filesystem. They | |
| 224 | −noquota are used only by quota tools to recognize volumes | |
| 225 | −grpquota where quota should be turned on. See documentation | |
| 226 | −usrquota in the quota-tools package for more details | |
| 227 | − (http://sourceforge.net/projects/linuxquota). | |
| 228 | − | |
| 229 | −jqfmt=<quota type> These options tell filesystem details about quota | |
| 230 | −usrjquota=<file> so that quota information can be properly updated | |
| 231 | −grpjquota=<file> during journal replay. They replace the above | |
| 232 | − quota options. See documentation in the quota-tools | |
| 233 | − package for more details | |
| 234 | − (http://sourceforge.net/projects/linuxquota). | |
| 235 | − | |
| 236 | −stripe=n Number of filesystem blocks that mballoc will try | |
| 237 | − to use for allocation size and alignment. For RAID5/6 | |
| 238 | − systems this should be the number of data | |
| 239 | − disks * RAID chunk size in file system blocks. | |
| 240 | − | |
| 241 | −delalloc (*) Defer block allocation until just before ext4 | |
| 242 | − writes out the block(s) in question. This | |
| 243 | − allows ext4 to better allocation decisions | |
| 244 | − more efficiently. | |
| 245 | −nodelalloc Disable delayed allocation. Blocks are allocated | |
| 246 | − when the data is copied from userspace to the | |
| 247 | − page cache, either via the write(2) system call | |
| 248 | − or when an mmap'ed page which was previously | |
| 249 | − unallocated is written for the first time. | |
| 250 | − | |
| 251 | −max_batch_time=usec Maximum amount of time ext4 should wait for | |
| 252 | − additional filesystem operations to be batch | |
| 253 | − together with a synchronous write operation. | |
| 254 | − Since a synchronous write operation is going to | |
| 255 | − force a commit and then a wait for the I/O | |
| 256 | − complete, it doesn't cost much, and can be a | |
| 257 | − huge throughput win, we wait for a small amount | |
| 258 | − of time to see if any other transactions can | |
| 259 | − piggyback on the synchronous write. The | |
| 260 | − algorithm used is designed to automatically tune | |
| 261 | − for the speed of the disk, by measuring the | |
| 262 | − amount of time (on average) that it takes to | |
| 263 | − finish committing a transaction. Call this time | |
| 264 | − the "commit time". If the time that the | |
| 265 | − transaction has been running is less than the | |
| 266 | − commit time, ext4 will try sleeping for the | |
| 267 | − commit time to see if other operations will join | |
| 268 | − the transaction. The commit time is capped by | |
| 269 | − the max_batch_time, which defaults to 15000us | |
| 270 | − (15ms). This optimization can be turned off | |
| 271 | − entirely by setting max_batch_time to 0. | |
| 272 | − | |
| 273 | −min_batch_time=usec This parameter sets the commit time (as | |
| 274 | − described above) to be at least min_batch_time. | |
| 275 | − It defaults to zero microseconds. Increasing | |
| 276 | − this parameter may improve the throughput of | |
| 277 | − multi-threaded, synchronous workloads on very | |
| 278 | − fast disks, at the cost of increasing latency. | |
| 279 | − | |
| 280 | −journal_ioprio=prio The I/O priority (from 0 to 7, where 0 is the | |
| 281 | − highest priority) which should be used for I/O | |
| 282 | − operations submitted by kjournald2 during a | |
| 283 | − commit operation. This defaults to 3, which is | |
| 284 | − a slightly higher priority than the default I/O | |
| 285 | − priority. | |
| 286 | − | |
| 287 | −auto_da_alloc(*) Many broken applications don't use fsync() when | |
| 288 | −noauto_da_alloc replacing existing files via patterns such as | |
| 289 | − fd = open("foo.new")/write(fd,..)/close(fd)/ | |
| 290 | − rename("foo.new", "foo"), or worse yet, | |
| 291 | − fd = open("foo", O_TRUNC)/write(fd,..)/close(fd). | |
| 292 | − If auto_da_alloc is enabled, ext4 will detect | |
| 293 | − the replace-via-rename and replace-via-truncate | |
| 294 | − patterns and force that any delayed allocation | |
| 295 | − blocks are allocated such that at the next | |
| 296 | − journal commit, in the default data=ordered | |
| 297 | − mode, the data blocks of the new file are forced | |
| 298 | − to disk before the rename() operation is | |
| 299 | − committed. This provides roughly the same level | |
| 300 | − of guarantees as ext3, and avoids the | |
| 301 | − "zero-length" problem that can happen when a | |
| 302 | − system crashes before the delayed allocation | |
| 303 | − blocks are forced to disk. | |
| 304 | − | |
| 305 | −noinit_itable Do not initialize any uninitialized inode table | |
| 306 | − blocks in the background. This feature may be | |
| 307 | − used by installation CD's so that the install | |
| 308 | − process can complete as quickly as possible; the | |
| 309 | − inode table initialization process would then be | |
| 310 | − deferred until the next time the file system | |
| 311 | − is unmounted. | |
| 312 | − | |
| 313 | −init_itable=n The lazy itable init code will wait n times the | |
| 314 | − number of milliseconds it took to zero out the | |
| 315 | − previous block group's inode table. This | |
| 316 | − minimizes the impact on the system performance | |
| 317 | − while file system's inode table is being initialized. | |
| 318 | − | |
| 319 | −discard Controls whether ext4 should issue discard/TRIM | |
| 320 | −nodiscard(*) commands to the underlying block device when | |
| 321 | − blocks are freed. This is useful for SSD devices | |
| 322 | − and sparse/thinly-provisioned LUNs, but it is off | |
| 323 | − by default until sufficient testing has been done. | |
| 324 | − | |
| 325 | −nouid32 Disables 32-bit UIDs and GIDs. This is for | |
| 326 | − interoperability with older kernels which only | |
| 327 | − store and expect 16-bit values. | |
| 328 | − | |
| 329 | −block_validity(*) These options enable or disable the in-kernel | |
| 330 | −noblock_validity facility for tracking filesystem metadata blocks | |
| 331 | − within internal data structures. This allows multi- | |
| 332 | − block allocator and other routines to notice | |
| 333 | − bugs or corrupted allocation bitmaps which cause | |
| 334 | − blocks to be allocated which overlap with | |
| 335 | − filesystem metadata blocks. | |
| 336 | − | |
| 337 | −dioread_lock Controls whether or not ext4 should use the DIO read | |
| 338 | −dioread_nolock locking. If the dioread_nolock option is specified | |
| 339 | − ext4 will allocate uninitialized extent before buffer | |
| 340 | − write and convert the extent to initialized after IO | |
| 341 | − completes. This approach allows ext4 code to avoid | |
| 342 | − using inode mutex, which improves scalability on high | |
| 343 | − speed storages. However this does not work with | |
| 344 | − data journaling and dioread_nolock option will be | |
| 345 | − ignored with kernel warning. Note that dioread_nolock | |
| 346 | − code path is only used for extent-based files. | |
| 347 | − Because of the restrictions this options comprises | |
| 348 | − it is off by default (e.g. dioread_lock). | |
| 349 | − | |
| 350 | −max_dir_size_kb=n This limits the size of directories so that any | |
| 351 | − attempt to expand them beyond the specified | |
| 352 | − limit in kilobytes will cause an ENOSPC error. | |
| 353 | − This is useful in memory constrained | |
| 354 | − environments, where a very large directory can | |
| 355 | − cause severe performance problems or even | |
| 356 | − provoke the Out Of Memory killer. (For example, | |
| 357 | − if there is only 512mb memory available, a 176mb | |
| 358 | − directory may seriously cramp the system's style.) | |
| 359 | − | |
| 360 | −i_version Enable 64-bit inode version support. This option is | |
| 361 | − off by default. | |
| 362 | − | |
| 363 | −dax Use direct access (no page cache). See | |
| 364 | − Documentation/filesystems/dax.txt. Note that | |
| 365 | − this option is incompatible with data=journal. | |
| 366 | −======================= ======================================================= | |
| 367 | − | |
| 368 | −Data Mode | |
| 369 | −========= | |
| 370 | −There are 3 different data modes: | |
| 371 | − | |
| 372 | −* writeback mode | |
| 373 | − | |
| 374 | − In data=writeback mode, ext4 does not journal data at all. This mode provides | |
| 375 | − a similar level of journaling as that of XFS, JFS, and ReiserFS in its default | |
| 376 | − mode - metadata journaling. A crash+recovery can cause incorrect data to | |
| 377 | − appear in files which were written shortly before the crash. This mode will | |
| 378 | − typically provide the best ext4 performance. | |
| 379 | − | |
| 380 | −* ordered mode | |
| 381 | − | |
| 382 | − In data=ordered mode, ext4 only officially journals metadata, but it logically | |
| 383 | − groups metadata information related to data changes with the data blocks into | |
| 384 | − a single unit called a transaction. When it's time to write the new metadata | |
| 385 | − out to disk, the associated data blocks are written first. In general, this | |
| 386 | − mode performs slightly slower than writeback but significantly faster than | |
| 387 | − journal mode. | |
| 388 | − | |
| 389 | −* journal mode | |
| 390 | − | |
| 391 | − data=journal mode provides full data and metadata journaling. All new data is | |
| 392 | − written to the journal first, and then to its final location. In the event of | |
| 393 | − a crash, the journal can be replayed, bringing both data and metadata into a | |
| 394 | − consistent state. This mode is the slowest except when data needs to be read | |
| 395 | − from and written to disk at the same time where it outperforms all others | |
| 396 | − modes. Enabling this mode will disable delayed allocation and O_DIRECT | |
| 397 | − support. | |
| 398 | − | |
| 399 | −/proc entries | |
| 400 | −============= | |
| 401 | − | |
| 402 | −Information about mounted ext4 file systems can be found in | |
| 403 | −/proc/fs/ext4. Each mounted filesystem will have a directory in | |
| 404 | −/proc/fs/ext4 based on its device name (i.e., /proc/fs/ext4/hdc or | |
| 405 | −/proc/fs/ext4/dm-0). The files in each per-device directory are shown | |
| 406 | −in table below. | |
| 407 | − | |
| 408 | −Files in /proc/fs/ext4/<devname> | |
| 409 | − | |
| 410 | −================ ======= | |
| 411 | − File Content | |
| 412 | −================ ======= | |
| 413 | − mb_groups details of multiblock allocator buddy cache of free blocks | |
| 414 | −================ ======= | |
| 415 | − | |
| 416 | −/sys entries | |
| 417 | −============ | |
| 418 | − | |
| 419 | −Information about mounted ext4 file systems can be found in | |
| 420 | −/sys/fs/ext4. Each mounted filesystem will have a directory in | |
| 421 | −/sys/fs/ext4 based on its device name (i.e., /sys/fs/ext4/hdc or | |
| 422 | −/sys/fs/ext4/dm-0). The files in each per-device directory are shown | |
| 423 | −in table below. | |
| 424 | − | |
| 425 | −Files in /sys/fs/ext4/<devname>: | |
| 426 | − | |
| 427 | −(see also Documentation/ABI/testing/sysfs-fs-ext4) | |
| 428 | − | |
| 429 | −============================= ================================================= | |
| 430 | −File Content | |
| 431 | −============================= ================================================= | |
| 432 | − delayed_allocation_blocks This file is read-only and shows the number of | |
| 433 | − blocks that are dirty in the page cache, but | |
| 434 | − which do not have their location in the | |
| 435 | − filesystem allocated yet. | |
| 436 | − | |
| 437 | −inode_goal Tuning parameter which (if non-zero) controls | |
| 438 | − the goal inode used by the inode allocator in | |
| 439 | − preference to all other allocation heuristics. | |
| 440 | − This is intended for debugging use only, and | |
| 441 | − should be 0 on production systems. | |
| 442 | − | |
| 443 | −inode_readahead_blks Tuning parameter which controls the maximum | |
| 444 | − number of inode table blocks that ext4's inode | |
| 445 | − table readahead algorithm will pre-read into | |
| 446 | − the buffer cache | |
| 447 | − | |
| 448 | −lifetime_write_kbytes This file is read-only and shows the number of | |
| 449 | − kilobytes of data that have been written to this | |
| 450 | − filesystem since it was created. | |
| 451 | − | |
| 452 | − max_writeback_mb_bump The maximum number of megabytes the writeback | |
| 453 | − code will try to write out before move on to | |
| 454 | − another inode. | |
| 455 | − | |
| 456 | − mb_group_prealloc The multiblock allocator will round up allocation | |
| 457 | − requests to a multiple of this tuning parameter if | |
| 458 | − the stripe size is not set in the ext4 superblock | |
| 459 | − | |
| 460 | − mb_max_to_scan The maximum number of extents the multiblock | |
| 461 | − allocator will search to find the best extent | |
| 462 | − | |
| 463 | − mb_min_to_scan The minimum number of extents the multiblock | |
| 464 | − allocator will search to find the best extent | |
| 465 | − | |
| 466 | − mb_order2_req Tuning parameter which controls the minimum size | |
| 467 | − for requests (as a power of 2) where the buddy | |
| 468 | − cache is used | |
| 469 | − | |
| 470 | − mb_stats Controls whether the multiblock allocator should | |
| 471 | − collect statistics, which are shown during the | |
| 472 | − unmount. 1 means to collect statistics, 0 means | |
| 473 | − not to collect statistics | |
| 474 | − | |
| 475 | − mb_stream_req Files which have fewer blocks than this tunable | |
| 476 | − parameter will have their blocks allocated out | |
| 477 | − of a block group specific preallocation pool, so | |
| 478 | − that small files are packed closely together. | |
| 479 | − Each large file will have its blocks allocated | |
| 480 | − out of its own unique preallocation pool. | |
| 481 | − | |
| 482 | − session_write_kbytes This file is read-only and shows the number of | |
| 483 | − kilobytes of data that have been written to this | |
| 484 | − filesystem since it was mounted. | |
| 485 | − | |
| 486 | − reserved_clusters This is RW file and contains number of reserved | |
| 487 | − clusters in the file system which will be used | |
| 488 | − in the specific situations to avoid costly | |
| 489 | − zeroout, unexpected ENOSPC, or possible data | |
| 490 | − loss. The default is 2% or 4096 clusters, | |
| 491 | − whichever is smaller and this can be changed | |
| 492 | − however it can never exceed number of clusters | |
| 493 | − in the file system. If there is not enough space | |
| 494 | − for the reserved space when mounting the file | |
| 495 | − mount will _not_ fail. | |
| 496 | −============================= ================================================= | |
| 497 | − | |
| 498 | −Ioctls | |
| 499 | −====== | |
| 500 | − | |
| 501 | −There is some Ext4 specific functionality which can be accessed by applications | |
| 502 | −through the system call interfaces. The list of all Ext4 specific ioctls are | |
| 503 | −shown in the table below. | |
| 504 | − | |
| 505 | −Table of Ext4 specific ioctls | |
| 506 | − | |
| 507 | −============================= ================================================= | |
| 508 | −Ioctl Description | |
| 509 | −============================= ================================================= | |
| 510 | − EXT4_IOC_GETFLAGS Get additional attributes associated with inode. | |
| 511 | − The ioctl argument is an integer bitfield, with | |
| 512 | − bit values described in ext4.h. This ioctl is an | |
| 513 | − alias for FS_IOC_GETFLAGS. | |
| 514 | − | |
| 515 | − EXT4_IOC_SETFLAGS Set additional attributes associated with inode. | |
| 516 | − The ioctl argument is an integer bitfield, with | |
| 517 | − bit values described in ext4.h. This ioctl is an | |
| 518 | − alias for FS_IOC_SETFLAGS. | |
| 519 | − | |
| 520 | − EXT4_IOC_GETVERSION | |
| 521 | − EXT4_IOC_GETVERSION_OLD | |
| 522 | − Get the inode i_generation number stored for | |
| 523 | − each inode. The i_generation number is normally | |
| 524 | − changed only when new inode is created and it is | |
| 525 | − particularly useful for network filesystems. The | |
| 526 | − '_OLD' version of this ioctl is an alias for | |
| 527 | − FS_IOC_GETVERSION. | |
| 528 | − | |
| 529 | − EXT4_IOC_SETVERSION | |
| 530 | − EXT4_IOC_SETVERSION_OLD | |
| 531 | − Set the inode i_generation number stored for | |
| 532 | − each inode. The '_OLD' version of this ioctl | |
| 533 | − is an alias for FS_IOC_SETVERSION. | |
| 534 | − | |
| 535 | − EXT4_IOC_GROUP_EXTEND This ioctl has the same purpose as the resize | |
| 536 | − mount option. It allows to resize filesystem | |
| 537 | − to the end of the last existing block group, | |
| 538 | − further resize has to be done with resize2fs, | |
| 539 | − either online, or offline. The argument points | |
| 540 | − to the unsigned logn number representing the | |
| 541 | − filesystem new block count. | |
| 542 | − | |
| 543 | − EXT4_IOC_MOVE_EXT Move the block extents from orig_fd (the one | |
| 544 | − this ioctl is pointing to) to the donor_fd (the | |
| 545 | − one specified in move_extent structure passed | |
| 546 | − as an argument to this ioctl). Then, exchange | |
| 547 | − inode metadata between orig_fd and donor_fd. | |
| 548 | − This is especially useful for online | |
| 549 | − defragmentation, because the allocator has the | |
| 550 | − opportunity to allocate moved blocks better, | |
| 551 | − ideally into one contiguous extent. | |
| 552 | − | |
| 553 | − EXT4_IOC_GROUP_ADD Add a new group descriptor to an existing or | |
| 554 | − new group descriptor block. The new group | |
| 555 | − descriptor is described by ext4_new_group_input | |
| 556 | − structure, which is passed as an argument to | |
| 557 | − this ioctl. This is especially useful in | |
| 558 | − conjunction with EXT4_IOC_GROUP_EXTEND, | |
| 559 | − which allows online resize of the filesystem | |
| 560 | − to the end of the last existing block group. | |
| 561 | − Those two ioctls combined is used in userspace | |
| 562 | − online resize tool (e.g. resize2fs). | |
| 563 | − | |
| 564 | − EXT4_IOC_MIGRATE This ioctl operates on the filesystem itself. | |
| 565 | − It converts (migrates) ext3 indirect block mapped | |
| 566 | − inode to ext4 extent mapped inode by walking | |
| 567 | − through indirect block mapping of the original | |
| 568 | − inode and converting contiguous block ranges | |
| 569 | − into ext4 extents of the temporary inode. Then, | |
| 570 | − inodes are swapped. This ioctl might help, when | |
| 571 | − migrating from ext3 to ext4 filesystem, however | |
| 572 | − suggestion is to create fresh ext4 filesystem | |
| 573 | − and copy data from the backup. Note, that | |
| 574 | − filesystem has to support extents for this ioctl | |
| 575 | − to work. | |
| 576 | − | |
| 577 | − EXT4_IOC_ALLOC_DA_BLKS Force all of the delay allocated blocks to be | |
| 578 | − allocated to preserve application-expected ext3 | |
| 579 | − behaviour. Note that this will also start | |
| 580 | − triggering a write of the data blocks, but this | |
| 581 | − behaviour may change in the future as it is | |
| 582 | − not necessary and has been done this way only | |
| 583 | − for sake of simplicity. | |
| 584 | − | |
| 585 | − EXT4_IOC_RESIZE_FS Resize the filesystem to a new size. The number | |
| 586 | − of blocks of resized filesystem is passed in via | |
| 587 | − 64 bit integer argument. The kernel allocates | |
| 588 | − bitmaps and inode table, the userspace tool thus | |
| 589 | − just passes the new number of blocks. | |
| 590 | − | |
| 591 | − EXT4_IOC_SWAP_BOOT Swap i_blocks and associated attributes | |
| 592 | − (like i_blocks, i_size, i_flags, ...) from | |
| 593 | − the specified inode with inode | |
| 594 | − EXT4_BOOT_LOADER_INO (#5). This is typically | |
| 595 | − used to store a boot loader in a secure part of | |
| 596 | − the filesystem, where it can't be changed by a | |
| 597 | − normal user by accident. | |
| 598 | − The data blocks of the previous boot loader | |
| 599 | − will be associated with the given inode. | |
| 600 | −============================= ================================================= | |
| 601 | − | |
| 602 | −References | |
| 603 | −========== | |
| 604 | − | |
| 605 | −kernel source: <file:fs/ext4/> | |
| 606 | − <file:fs/jbd2/> | |
| 607 | − | |
| 608 | −programs: http://e2fsprogs.sourceforge.net/ | |
| 609 | − | |
| 610 | −useful links: http://fedoraproject.org/wiki/ext3-devel | |
| 611 | − http://www.bullopensource.org/ext4/ | |
| 612 | − http://ext4.wiki.kernel.org/index.php/Main_Page | |
| 613 | − http://fedoraproject.org/wiki/Features/Ext4 | |
File renamed without changes.
| @@ -43,7 +43,7 @@ entire bitmap. · 42 unmodified lines | ||
| 43 | 43 | The block group descriptor is laid out in ``struct ext4_group_desc``. |
| 44 | 44 | |
| 45 | 45 | .. list-table:: |
| 46 | − :widths: 1 1 1 77 | |
| 46 | + :widths: 8 8 24 40 | |
| 47 | 47 | :header-rows: 1 |
| 48 | 48 | |
| 49 | 49 | * - Offset |
| @@ -157,7 +157,7 @@ The block group descriptor is laid out in ``struct ext4_group_desc``. · 107 unmodified lines | ||
| 157 | 157 | Block group flags can be any combination of the following: |
| 158 | 158 | |
| 159 | 159 | .. list-table:: |
| 160 | − :widths: 1 79 | |
| 160 | + :widths: 16 64 | |
| 161 | 161 | :header-rows: 1 |
| 162 | 162 | |
| 163 | 163 | * - Value |
| @@ -68,7 +68,7 @@ The extent tree header is recorded in ``struct ext4_extent_header``, · 67 unmodified lines | ||
| 68 | 68 | which is 12 bytes long: |
| 69 | 69 | |
| 70 | 70 | .. list-table:: |
| 71 | − :widths: 1 1 1 77 | |
| 71 | + :widths: 8 8 24 40 | |
| 72 | 72 | :header-rows: 1 |
| 73 | 73 | |
| 74 | 74 | * - Offset |
| @@ -104,7 +104,7 @@ Internal nodes of the extent tree, also known as index nodes, are · 29 unmodified lines | ||
| 104 | 104 | recorded as ``struct ext4_extent_idx``, and are 12 bytes long: |
| 105 | 105 | |
| 106 | 106 | .. list-table:: |
| 107 | − :widths: 1 1 1 77 | |
| 107 | + :widths: 8 8 24 40 | |
| 108 | 108 | :header-rows: 1 |
| 109 | 109 | |
| 110 | 110 | * - Offset |
| @@ -134,7 +134,7 @@ Leaf nodes of the extent tree are recorded as ``struct ext4_extent``, · 23 unmodified lines | ||
| 134 | 134 | and are also 12 bytes long: |
| 135 | 135 | |
| 136 | 136 | .. list-table:: |
| 137 | − :widths: 1 1 1 77 | |
| 137 | + :widths: 8 8 24 40 | |
| 138 | 138 | :header-rows: 1 |
| 139 | 139 | |
| 140 | 140 | * - Offset |
| @@ -174,7 +174,7 @@ including) the checksum itself. · 33 unmodified lines | ||
| 174 | 174 | ``struct ext4_extent_tail`` is 4 bytes long: |
| 175 | 175 | |
| 176 | 176 | .. list-table:: |
| 177 | − :widths: 1 1 1 77 | |
| 177 | + :widths: 8 8 24 40 | |
| 178 | 178 | :header-rows: 1 |
| 179 | 179 | |
| 180 | 180 | * - Offset |
| @@ -1,17 +1,14 @@ | ||
| 1 | 1 | .. SPDX-License-Identifier: GPL-2.0 |
| 2 | 2 | |
| 3 | −=============== | |
| 4 | −ext4 Filesystem | |
| 5 | −=============== | |
| 6 | − | |
| 7 | −General usage and on-disk artifacts writen by ext4. More documentation may | |
| 8 | −be ported from the wiki as time permits. This should be considered the | |
| 9 | −canonical source of information as the details here have been reviewed by | |
| 10 | −the ext4 community. | |
| 3 | +=================================== | |
| 4 | +ext4 Data Structures and Algorithms | |
| 5 | +=================================== | |
| 11 | 6 | |
| 12 | 7 | .. toctree:: |
| 13 | − :maxdepth: 5 | |
| 8 | + :maxdepth: 6 | |
| 14 | 9 | :numbered: |
| 15 | 10 | |
| 16 | − ext4 | |
| 17 | − ondisk/index | |
| 11 | + about.rst | |
| 12 | + overview.rst | |
| 13 | + globals.rst | |
| 14 | + dynamic.rst | |
File renamed without changes.
| @@ -29,8 +29,9 @@ and the inode structure itself. · 28 unmodified lines | ||
| 29 | 29 | The inode table entry is laid out in ``struct ext4_inode``. |
| 30 | 30 | |
| 31 | 31 | .. list-table:: |
| 32 | − :widths: 1 1 1 77 | |
| 32 | + :widths: 8 8 24 40 | |
| 33 | 33 | :header-rows: 1 |
| 34 | + :class: longtable | |
| 34 | 35 | |
| 35 | 36 | * - Offset |
| 36 | 37 | - Size |
| @@ -176,7 +177,7 @@ The inode table entry is laid out in ``struct ext4_inode``. · 139 unmodified lines | ||
| 176 | 177 | The ``i_mode`` value is a combination of the following flags: |
| 177 | 178 | |
| 178 | 179 | .. list-table:: |
| 179 | − :widths: 1 79 | |
| 180 | + :widths: 16 64 | |
| 180 | 181 | :header-rows: 1 |
| 181 | 182 | |
| 182 | 183 | * - Value |
| @@ -227,7 +228,7 @@ The ``i_mode`` value is a combination of the following flags: · 44 unmodified lines | ||
| 227 | 228 | The ``i_flags`` field is a combination of these values: |
| 228 | 229 | |
| 229 | 230 | .. list-table:: |
| 230 | − :widths: 1 79 | |
| 231 | + :widths: 16 64 | |
| 231 | 232 | :header-rows: 1 |
| 232 | 233 | |
| 233 | 234 | * - Value |
| @@ -314,7 +315,7 @@ The ``osd1`` field has multiple meanings depending on the creator: · 80 unmodified lines | ||
| 314 | 315 | Linux: |
| 315 | 316 | |
| 316 | 317 | .. list-table:: |
| 317 | − :widths: 1 1 1 77 | |
| 318 | + :widths: 8 8 24 40 | |
| 318 | 319 | :header-rows: 1 |
| 319 | 320 | |
| 320 | 321 | * - Offset |
| @@ -331,7 +332,7 @@ Linux: · 10 unmodified lines | ||
| 331 | 332 | Hurd: |
| 332 | 333 | |
| 333 | 334 | .. list-table:: |
| 334 | − :widths: 1 1 1 77 | |
| 335 | + :widths: 8 8 24 40 | |
| 335 | 336 | :header-rows: 1 |
| 336 | 337 | |
| 337 | 338 | * - Offset |
| @@ -346,7 +347,7 @@ Hurd: · 8 unmodified lines | ||
| 346 | 347 | Masix: |
| 347 | 348 | |
| 348 | 349 | .. list-table:: |
| 349 | − :widths: 1 1 1 77 | |
| 350 | + :widths: 8 8 24 40 | |
| 350 | 351 | :header-rows: 1 |
| 351 | 352 | |
| 352 | 353 | * - Offset |
| @@ -365,7 +366,7 @@ The ``osd2`` field has multiple meanings depending on the filesystem creator: · 12 unmodified lines | ||
| 365 | 366 | Linux: |
| 366 | 367 | |
| 367 | 368 | .. list-table:: |
| 368 | − :widths: 1 1 1 77 | |
| 369 | + :widths: 8 8 24 40 | |
| 369 | 370 | :header-rows: 1 |
| 370 | 371 | |
| 371 | 372 | * - Offset |
| @@ -402,7 +403,7 @@ Linux: · 30 unmodified lines | ||
| 402 | 403 | Hurd: |
| 403 | 404 | |
| 404 | 405 | .. list-table:: |
| 405 | − :widths: 1 1 1 77 | |
| 406 | + :widths: 8 8 24 40 | |
| 406 | 407 | :header-rows: 1 |
| 407 | 408 | |
| 408 | 409 | * - Offset |
| @@ -433,7 +434,7 @@ Hurd: · 24 unmodified lines | ||
| 433 | 434 | Masix: |
| 434 | 435 | |
| 435 | 436 | .. list-table:: |
| 436 | − :widths: 1 1 1 77 | |
| 437 | + :widths: 8 8 24 40 | |
| 437 | 438 | :header-rows: 1 |
| 438 | 439 | |
| 439 | 440 | * - Offset |
| @@ -48,7 +48,7 @@ Layout · 47 unmodified lines | ||
| 48 | 48 | Generally speaking, the journal has this format: |
| 49 | 49 | |
| 50 | 50 | .. list-table:: |
| 51 | − :widths: 1 1 78 | |
| 51 | + :widths: 16 48 16 | |
| 52 | 52 | :header-rows: 1 |
| 53 | 53 | |
| 54 | 54 | * - Superblock |
| @@ -76,7 +76,7 @@ The journal superblock will be in the next full block after the · 21 unmodified lines | ||
| 76 | 76 | superblock. |
| 77 | 77 | |
| 78 | 78 | .. list-table:: |
| 79 | − :widths: 1 1 1 1 76 | |
| 79 | + :widths: 12 12 12 32 12 | |
| 80 | 80 | :header-rows: 1 |
| 81 | 81 | |
| 82 | 82 | * - 1024 bytes of padding |
| @@ -98,7 +98,7 @@ Every block in the journal starts with a common 12-byte header · 15 unmodified lines | ||
| 98 | 98 | ``struct journal_header_s``: |
| 99 | 99 | |
| 100 | 100 | .. list-table:: |
| 101 | − :widths: 1 1 1 77 | |
| 101 | + :widths: 8 8 24 40 | |
| 102 | 102 | :header-rows: 1 |
| 103 | 103 | |
| 104 | 104 | * - Offset |
| @@ -124,7 +124,7 @@ Every block in the journal starts with a common 12-byte header · 19 unmodified lines | ||
| 124 | 124 | The journal block type can be any one of: |
| 125 | 125 | |
| 126 | 126 | .. list-table:: |
| 127 | − :widths: 1 79 | |
| 127 | + :widths: 16 64 | |
| 128 | 128 | :header-rows: 1 |
| 129 | 129 | |
| 130 | 130 | * - Value |
| @@ -154,7 +154,7 @@ The journal superblock is recorded as ``struct journal_superblock_s``, · 23 unmodified lines | ||
| 154 | 154 | which is 1024 bytes long: |
| 155 | 155 | |
| 156 | 156 | .. list-table:: |
| 157 | − :widths: 1 1 1 77 | |
| 157 | + :widths: 8 8 24 40 | |
| 158 | 158 | :header-rows: 1 |
| 159 | 159 | |
| 160 | 160 | * - Offset |
| @@ -264,7 +264,7 @@ which is 1024 bytes long: · 103 unmodified lines | ||
| 264 | 264 | The journal compat features are any combination of the following: |
| 265 | 265 | |
| 266 | 266 | .. list-table:: |
| 267 | − :widths: 1 79 | |
| 267 | + :widths: 16 64 | |
| 268 | 268 | :header-rows: 1 |
| 269 | 269 | |
| 270 | 270 | * - Value |
| @@ -278,7 +278,7 @@ The journal compat features are any combination of the following: · 7 unmodified lines | ||
| 278 | 278 | The journal incompat features are any combination of the following: |
| 279 | 279 | |
| 280 | 280 | .. list-table:: |
| 281 | − :widths: 1 79 | |
| 281 | + :widths: 16 64 | |
| 282 | 282 | :header-rows: 1 |
| 283 | 283 | |
| 284 | 284 | * - Value |
| @@ -306,7 +306,7 @@ Journal checksum type codes are one of the following. crc32 or crc32c are the · 21 unmodified lines | ||
| 306 | 306 | most likely choices. |
| 307 | 307 | |
| 308 | 308 | .. list-table:: |
| 309 | − :widths: 1 79 | |
| 309 | + :widths: 16 64 | |
| 310 | 310 | :header-rows: 1 |
| 311 | 311 | |
| 312 | 312 | * - Value |
| @@ -330,7 +330,7 @@ described by a data structure, but here is the block structure anyway. · 17 unmodified lines | ||
| 330 | 330 | Descriptor blocks consume at least 36 bytes, but use a full block: |
| 331 | 331 | |
| 332 | 332 | .. list-table:: |
| 333 | − :widths: 1 1 1 77 | |
| 333 | + :widths: 8 8 24 40 | |
| 334 | 334 | :header-rows: 1 |
| 335 | 335 | |
| 336 | 336 | * - Offset |
| @@ -355,7 +355,7 @@ defined as ``struct journal_block_tag3_s``, which looks like the · 18 unmodified lines | ||
| 355 | 355 | following. The size is 16 or 32 bytes. |
| 356 | 356 | |
| 357 | 357 | .. list-table:: |
| 358 | − :widths: 1 1 1 77 | |
| 358 | + :widths: 8 8 24 40 | |
| 359 | 359 | :header-rows: 1 |
| 360 | 360 | |
| 361 | 361 | * - Offset |
| @@ -400,7 +400,7 @@ following. The size is 16 or 32 bytes. · 38 unmodified lines | ||
| 400 | 400 | The journal tag flags are any combination of the following: |
| 401 | 401 | |
| 402 | 402 | .. list-table:: |
| 403 | − :widths: 1 79 | |
| 403 | + :widths: 16 64 | |
| 404 | 404 | :header-rows: 1 |
| 405 | 405 | |
| 406 | 406 | * - Value |
| @@ -421,7 +421,7 @@ is defined as ``struct journal_block_tag_s``, which looks like the · 14 unmodified lines | ||
| 421 | 421 | following. The size is 8, 12, 24, or 28 bytes: |
| 422 | 422 | |
| 423 | 423 | .. list-table:: |
| 424 | − :widths: 1 1 1 77 | |
| 424 | + :widths: 8 8 24 40 | |
| 425 | 425 | :header-rows: 1 |
| 426 | 426 | |
| 427 | 427 | * - Offset |
| @@ -471,7 +471,7 @@ JBD2\_FEATURE\_INCOMPAT\_CSUM\_V3 are set, the end of the block is a · 43 unmodified lines | ||
| 471 | 471 | ``struct jbd2_journal_block_tail``, which looks like this: |
| 472 | 472 | |
| 473 | 473 | .. list-table:: |
| 474 | − :widths: 1 1 1 77 | |
| 474 | + :widths: 8 8 24 40 | |
| 475 | 475 | :header-rows: 1 |
| 476 | 476 | |
| 477 | 477 | * - Offset |
| @@ -513,7 +513,7 @@ Revocation blocks are described in · 35 unmodified lines | ||
| 513 | 513 | length, but use a full block: |
| 514 | 514 | |
| 515 | 515 | .. list-table:: |
| 516 | − :widths: 1 1 1 77 | |
| 516 | + :widths: 8 8 24 40 | |
| 517 | 517 | :header-rows: 1 |
| 518 | 518 | |
| 519 | 519 | * - Offset |
| @@ -543,7 +543,7 @@ JBD2\_FEATURE\_INCOMPAT\_CSUM\_V3 are set, the end of the revocation · 23 unmodified lines | ||
| 543 | 543 | block is a ``struct jbd2_journal_revoke_tail``, which has this format: |
| 544 | 544 | |
| 545 | 545 | .. list-table:: |
| 546 | − :widths: 1 1 1 77 | |
| 546 | + :widths: 8 8 24 40 | |
| 547 | 547 | :header-rows: 1 |
| 548 | 548 | |
| 549 | 549 | * - Offset |
| @@ -567,7 +567,7 @@ The commit block is described by ``struct commit_header``, which is 32 · 17 unmodified lines | ||
| 567 | 567 | bytes long (but uses a full block): |
| 568 | 568 | |
| 569 | 569 | .. list-table:: |
| 570 | − :widths: 1 1 1 77 | |
| 570 | + :widths: 8 8 24 40 | |
| 571 | 571 | :header-rows: 1 |
| 572 | 572 | |
| 573 | 573 | * - Offset |
| @@ -32,7 +32,7 @@ The checksum is calculated against the FS UUID and the MMP structure. · 31 unmodified lines | ||
| 32 | 32 | The MMP structure (``struct mmp_struct``) is as follows: |
| 33 | 33 | |
| 34 | 34 | .. list-table:: |
| 35 | − :widths: 1 1 1 77 | |
| 35 | + :widths: 8 12 20 40 | |
| 36 | 36 | :header-rows: 1 |
| 37 | 37 | |
| 38 | 38 | * - Offset |
| @@ -1,9 +0,0 @@ | ||
| 1 | −.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | − | |
| 3 | −============================== | |
| 4 | −Data Structures and Algorithms | |
| 5 | −============================== | |
| 6 | −.. include:: about.rst | |
| 7 | −.. include:: overview.rst | |
| 8 | −.. include:: globals.rst | |
| 9 | −.. include:: dynamic.rst | |
File renamed without changes.
| @@ -6,7 +6,7 @@ Special inodes · 5 unmodified lines | ||
| 6 | 6 | ext4 reserves some inode for special features, as follows: |
| 7 | 7 | |
| 8 | 8 | .. list-table:: |
| 9 | − :widths: 1 79 | |
| 9 | + :widths: 6 70 | |
| 10 | 10 | :header-rows: 1 |
| 11 | 11 | |
| 12 | 12 | * - inode Number |
| @@ -19,7 +19,7 @@ The ext4 superblock is laid out as follows in · 18 unmodified lines | ||
| 19 | 19 | ``struct ext4_super_block``: |
| 20 | 20 | |
| 21 | 21 | .. list-table:: |
| 22 | − :widths: 1 1 1 77 | |
| 22 | + :widths: 8 8 24 40 | |
| 23 | 23 | :header-rows: 1 |
| 24 | 24 | |
| 25 | 25 | * - Offset |
| @@ -483,7 +483,7 @@ The ext4 superblock is laid out as follows in · 457 unmodified lines | ||
| 483 | 483 | The superblock state is some combination of the following: |
| 484 | 484 | |
| 485 | 485 | .. list-table:: |
| 486 | − :widths: 1 79 | |
| 486 | + :widths: 8 72 | |
| 487 | 487 | :header-rows: 1 |
| 488 | 488 | |
| 489 | 489 | * - Value |
| @@ -500,7 +500,7 @@ The superblock state is some combination of the following: · 10 unmodified lines | ||
| 500 | 500 | The superblock error policy is one of the following: |
| 501 | 501 | |
| 502 | 502 | .. list-table:: |
| 503 | − :widths: 1 79 | |
| 503 | + :widths: 8 72 | |
| 504 | 504 | :header-rows: 1 |
| 505 | 505 | |
| 506 | 506 | * - Value |
| @@ -517,7 +517,7 @@ The superblock error policy is one of the following: · 10 unmodified lines | ||
| 517 | 517 | The filesystem creator is one of the following: |
| 518 | 518 | |
| 519 | 519 | .. list-table:: |
| 520 | − :widths: 1 79 | |
| 520 | + :widths: 8 72 | |
| 521 | 521 | :header-rows: 1 |
| 522 | 522 | |
| 523 | 523 | * - Value |
| @@ -538,7 +538,7 @@ The filesystem creator is one of the following: · 14 unmodified lines | ||
| 538 | 538 | The superblock revision is one of the following: |
| 539 | 539 | |
| 540 | 540 | .. list-table:: |
| 541 | − :widths: 1 79 | |
| 541 | + :widths: 8 72 | |
| 542 | 542 | :header-rows: 1 |
| 543 | 543 | |
| 544 | 544 | * - Value |
| @@ -556,7 +556,7 @@ The superblock compatible features field is a combination of any of the · 11 unmodified lines | ||
| 556 | 556 | following: |
| 557 | 557 | |
| 558 | 558 | .. list-table:: |
| 559 | − :widths: 1 79 | |
| 559 | + :widths: 16 64 | |
| 560 | 560 | :header-rows: 1 |
| 561 | 561 | |
| 562 | 562 | * - Value |
| @@ -595,7 +595,7 @@ The superblock incompatible features field is a combination of any of the · 32 unmodified lines | ||
| 595 | 595 | following: |
| 596 | 596 | |
| 597 | 597 | .. list-table:: |
| 598 | − :widths: 1 79 | |
| 598 | + :widths: 16 64 | |
| 599 | 599 | :header-rows: 1 |
| 600 | 600 | |
| 601 | 601 | * - Value |
| @@ -647,7 +647,7 @@ The superblock read-only compatible features field is a combination of any of · 45 unmodified lines | ||
| 647 | 647 | the following: |
| 648 | 648 | |
| 649 | 649 | .. list-table:: |
| 650 | − :widths: 1 79 | |
| 650 | + :widths: 16 64 | |
| 651 | 651 | :header-rows: 1 |
| 652 | 652 | |
| 653 | 653 | * - Value |
| @@ -702,7 +702,7 @@ the following: · 48 unmodified lines | ||
| 702 | 702 | The ``s_def_hash_version`` field is one of the following: |
| 703 | 703 | |
| 704 | 704 | .. list-table:: |
| 705 | − :widths: 1 79 | |
| 705 | + :widths: 8 72 | |
| 706 | 706 | :header-rows: 1 |
| 707 | 707 | |
| 708 | 708 | * - Value |
| @@ -725,7 +725,7 @@ The ``s_def_hash_version`` field is one of the following: · 16 unmodified lines | ||
| 725 | 725 | The ``s_default_mount_opts`` field is any combination of the following: |
| 726 | 726 | |
| 727 | 727 | .. list-table:: |
| 728 | − :widths: 1 79 | |
| 728 | + :widths: 8 72 | |
| 729 | 729 | :header-rows: 1 |
| 730 | 730 | |
| 731 | 731 | * - Value |
| @@ -767,7 +767,7 @@ The ``s_default_mount_opts`` field is any combination of the following: · 35 unmodified lines | ||
| 767 | 767 | The ``s_flags`` field is any combination of the following: |
| 768 | 768 | |
| 769 | 769 | .. list-table:: |
| 770 | − :widths: 1 79 | |
| 770 | + :widths: 8 72 | |
| 771 | 771 | :header-rows: 1 |
| 772 | 772 | |
| 773 | 773 | * - Value |
| @@ -784,7 +784,7 @@ The ``s_flags`` field is any combination of the following: · 10 unmodified lines | ||
| 784 | 784 | The ``s_encrypt_algos`` list can contain any of the following: |
| 785 | 785 | |
| 786 | 786 | .. list-table:: |
| 787 | − :widths: 1 79 | |
| 787 | + :widths: 8 72 | |
| 788 | 788 | :header-rows: 1 |
| 789 | 789 | |
| 790 | 790 | * - Value |
| @@ -172,9 +172,10 @@ fault_type=%d Support configuring fault injection type, should be · 171 unmodified lines | ||
| 172 | 172 | FAULT_DIR_DEPTH 0x000000100 |
| 173 | 173 | FAULT_EVICT_INODE 0x000000200 |
| 174 | 174 | FAULT_TRUNCATE 0x000000400 |
| 175 | − FAULT_IO 0x000000800 | |
| 175 | + FAULT_READ_IO 0x000000800 | |
| 176 | 176 | FAULT_CHECKPOINT 0x000001000 |
| 177 | 177 | FAULT_DISCARD 0x000002000 |
| 178 | + FAULT_WRITE_IO 0x000004000 | |
| 178 | 179 | mode=%s Control block allocation mode which supports "adaptive" |
| 179 | 180 | and "lfs". In "lfs" mode, there should be no random |
| 180 | 181 | writes towards main area. |
| @@ -211,6 +212,11 @@ fsync_mode=%s Control the policy of fsync. Currently supports "posix", · 30 unmodified lines | ||
| 211 | 212 | non-atomic files likewise "nobarrier" mount option. |
| 212 | 213 | test_dummy_encryption Enable dummy encryption, which provides a fake fscrypt |
| 213 | 214 | context. The fake fscrypt context is used by xfstests. |
| 215 | +checkpoint=%s Set to "disable" to turn off checkpointing. Set to "enable" | |
| 216 | + to reenable checkpointing. Is enabled by default. While | |
| 217 | + disabled, any unmounting or unexpected shutdowns will cause | |
| 218 | + the filesystem contents to appear as they did when the | |
| 219 | + filesystem was mounted with that option. | |
| 214 | 220 | |
| 215 | 221 | ================================================================================ |
| 216 | 222 | DEBUGFS ENTRIES |
| @@ -191,21 +191,11 @@ Currently, the following pairs of encryption modes are supported: · 190 unmodified lines | ||
| 191 | 191 | |
| 192 | 192 | - AES-256-XTS for contents and AES-256-CTS-CBC for filenames |
| 193 | 193 | - AES-128-CBC for contents and AES-128-CTS-CBC for filenames |
| 194 | −- Speck128/256-XTS for contents and Speck128/256-CTS-CBC for filenames | |
| 195 | 194 | |
| 196 | 195 | It is strongly recommended to use AES-256-XTS for contents encryption. |
| 197 | 196 | AES-128-CBC was added only for low-powered embedded devices with |
| 198 | 197 | crypto accelerators such as CAAM or CESA that do not support XTS. |
| 199 | 198 | |
| 200 | −Similarly, Speck128/256 support was only added for older or low-end | |
| 201 | −CPUs which cannot do AES fast enough -- especially ARM CPUs which have | |
| 202 | −NEON instructions but not the Cryptography Extensions -- and for which | |
| 203 | −it would not otherwise be feasible to use encryption at all. It is | |
| 204 | −not recommended to use Speck on CPUs that have AES instructions. | |
| 205 | −Speck support is only available if it has been enabled in the crypto | |
| 206 | −API via CONFIG_CRYPTO_SPECK. Also, on ARM platforms, to get | |
| 207 | −acceptable performance CONFIG_CRYPTO_SPECK_NEON must be enabled. | |
| 208 | − | |
| 209 | 199 | New encryption modes can be added relatively easily, without changes |
| 210 | 200 | to individual filesystems. However, authenticated encryption (AE) |
| 211 | 201 | modes are not currently supported because of the difficulty of dealing |
| @@ -1,26 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - this file (nfs-related documentation). | |
| 3 | −Exporting | |
| 4 | − - explanation of how to make filesystems exportable. | |
| 5 | −fault_injection.txt | |
| 6 | − - information for using fault injection on the server | |
| 7 | −knfsd-stats.txt | |
| 8 | − - statistics which the NFS server makes available to user space. | |
| 9 | −nfs.txt | |
| 10 | − - nfs client, and DNS resolution for fs_locations. | |
| 11 | −nfs41-server.txt | |
| 12 | − - info on the Linux server implementation of NFSv4 minor version 1. | |
| 13 | −nfs-rdma.txt | |
| 14 | − - how to install and setup the Linux NFS/RDMA client and server software | |
| 15 | −nfsd-admin-interfaces.txt | |
| 16 | − - Administrative interfaces for nfsd. | |
| 17 | −nfsroot.txt | |
| 18 | − - short guide on setting up a diskless box with NFS root filesystem. | |
| 19 | −pnfs.txt | |
| 20 | − - short explanation of some of the internals of the pnfs client code | |
| 21 | −rpc-cache.txt | |
| 22 | − - introduction to the caching mechanisms in the sunrpc layer. | |
| 23 | −idmapper.txt | |
| 24 | − - information for configuring request-keys to be used by idmapper | |
| 25 | −rpc-server-gss.txt | |
| 26 | − - Information on GSS authentication support in the NFS Server | |
| @@ -84,7 +84,7 @@ Creating a Cache · 83 unmodified lines | ||
| 84 | 84 | A message from user space has arrived to fill out a |
| 85 | 85 | cache entry. It is in 'buf' of length 'len'. |
| 86 | 86 | cache_parse should parse this, find the item in the |
| 87 | − cache with sunrpc_cache_lookup, and update the item | |
| 87 | + cache with sunrpc_cache_lookup_rcu, and update the item | |
| 88 | 88 | with sunrpc_cache_update. |
| 89 | 89 | |
| 90 | 90 | |
| @@ -95,7 +95,7 @@ Creating a Cache · 4 unmodified lines | ||
| 95 | 95 | Using a cache |
| 96 | 96 | ------------- |
| 97 | 97 | |
| 98 | −To find a value in a cache, call sunrpc_cache_lookup passing a pointer | |
| 98 | +To find a value in a cache, call sunrpc_cache_lookup_rcu passing a pointer | |
| 99 | 99 | to the cache_head in a sample item with the 'key' fields filled in. |
| 100 | 100 | This will be passed to ->match to identify the target entry. If no |
| 101 | 101 | entry is found, a new entry will be create, added to the cache, and |
| @@ -116,7 +116,7 @@ item does become valid, the deferred copy of the request will be · 14 unmodified lines | ||
| 116 | 116 | revisited (->revisit). It is expected that this method will |
| 117 | 117 | reschedule the request for processing. |
| 118 | 118 | |
| 119 | −The value returned by sunrpc_cache_lookup can also be passed to | |
| 119 | +The value returned by sunrpc_cache_lookup_rcu can also be passed to | |
| 120 | 120 | sunrpc_cache_update to set the content for the item. A second item is |
| 121 | 121 | passed which should hold the content. If the item found by _lookup |
| 122 | 122 | has valid data, then it is discarded and a new item is created. This |
| @@ -286,6 +286,12 @@ pointed by REDIRECT. This should not be possible on local system as setting · 285 unmodified lines | ||
| 286 | 286 | "trusted." xattrs will require CAP_SYS_ADMIN. But it should be possible |
| 287 | 287 | for untrusted layers like from a pen drive. |
| 288 | 288 | |
| 289 | +Note: redirect_dir={off|nofollow|follow(*)} conflicts with metacopy=on, and | |
| 290 | +results in an error. | |
| 291 | + | |
| 292 | +(*) redirect_dir=follow only conflicts with metacopy=on if upperdir=... is | |
| 293 | +given. | |
| 294 | + | |
| 289 | 295 | Sharing and copying layers |
| 290 | 296 | -------------------------- |
| 291 | 297 | |
| @@ -1,72 +0,0 @@ | ||
| 1 | −POHMELFS: Parallel Optimized Host Message Exchange Layered File System. | |
| 2 | − | |
| 3 | − Evgeniy Polyakov <zbr@ioremap.net> | |
| 4 | − | |
| 5 | −Homepage: http://www.ioremap.net/projects/pohmelfs | |
| 6 | − | |
| 7 | −POHMELFS first began as a network filesystem with coherent local data and | |
| 8 | −metadata caches but is now evolving into a parallel distributed filesystem. | |
| 9 | − | |
| 10 | −Main features of this FS include: | |
| 11 | − * Locally coherent cache for data and metadata with (potentially) byte-range locks. | |
| 12 | − Since all Linux filesystems lock the whole inode during writing, algorithm | |
| 13 | − is very simple and does not use byte-ranges, although they are sent in | |
| 14 | − locking messages. | |
| 15 | − * Completely async processing of all events except creation of hard and symbolic | |
| 16 | − links, and rename events. | |
| 17 | − Object creation and data reading and writing are processed asynchronously. | |
| 18 | − * Flexible object architecture optimized for network processing. | |
| 19 | − Ability to create long paths to objects and remove arbitrarily huge | |
| 20 | − directories with a single network command. | |
| 21 | − (like removing the whole kernel tree via a single network command). | |
| 22 | − * Very high performance. | |
| 23 | − * Fast and scalable multithreaded userspace server. Being in userspace it works | |
| 24 | − with any underlying filesystem and still is much faster than async in-kernel NFS one. | |
| 25 | − * Client is able to switch between different servers (if one goes down, client | |
| 26 | − automatically reconnects to second and so on). | |
| 27 | − * Transactions support. Full failover for all operations. | |
| 28 | − Resending transactions to different servers on timeout or error. | |
| 29 | − * Read request (data read, directory listing, lookup requests) balancing between multiple servers. | |
| 30 | − * Write requests are replicated to multiple servers and completed only when all of them are acked. | |
| 31 | − * Ability to add and/or remove servers from the working set at run-time. | |
| 32 | − * Strong authentication and possible data encryption in network channel. | |
| 33 | − * Extended attributes support. | |
| 34 | − | |
| 35 | −POHMELFS is based on transactions, which are potentially long-standing objects that live | |
| 36 | −in the client's memory. Each transaction contains all the information needed to process a given | |
| 37 | −command (or set of commands, which is frequently used during data writing: single transactions | |
| 38 | −can contain creation and data writing commands). Transactions are committed by all the servers | |
| 39 | −to which they are sent and, in case of failures, are eventually resent or dropped with an error. | |
| 40 | −For example, reading will return an error if no servers are available. | |
| 41 | − | |
| 42 | −POHMELFS uses a asynchronous approach to data processing. Courtesy of transactions, it is | |
| 43 | −possible to detach replies from requests and, if the command requires data to be received, the | |
| 44 | −caller sleeps waiting for it. Thus, it is possible to issue multiple read commands to different | |
| 45 | −servers and async threads will pick up replies in parallel, find appropriate transactions in the | |
| 46 | −system and put the data where it belongs (like the page or inode cache). | |
| 47 | − | |
| 48 | −The main feature of POHMELFS is writeback data and the metadata cache. | |
| 49 | −Only a few non-performance critical operations use the write-through cache and | |
| 50 | −are synchronous: hard and symbolic link creation, and object rename. Creation, | |
| 51 | −removal of objects and data writing are asynchronous and are sent to | |
| 52 | −the server during system writeback. Only one writer at a time is allowed for any | |
| 53 | −given inode, which is guarded by an appropriate locking protocol. | |
| 54 | −Because of this feature, POHMELFS is extremely fast at metadata intensive | |
| 55 | −workloads and can fully utilize the bandwidth to the servers when doing bulk | |
| 56 | −data transfers. | |
| 57 | − | |
| 58 | −POHMELFS clients operate with a working set of servers and are capable of balancing read-only | |
| 59 | −operations (like lookups or directory listings) between them according to IO priorities. | |
| 60 | −Administrators can add or remove servers from the set at run-time via special commands (described | |
| 61 | −in Documentation/filesystems/pohmelfs/info.txt file). Writes are replicated to all servers, which | |
| 62 | −are connected with write permission turned on. IO priority and permissions can be changed in | |
| 63 | −run-time. | |
| 64 | − | |
| 65 | −POHMELFS is capable of full data channel encryption and/or strong crypto hashing. | |
| 66 | −One can select any kernel supported cipher, encryption mode, hash type and operation mode | |
| 67 | −(hmac or digest). It is also possible to use both or neither (default). Crypto configuration | |
| 68 | −is checked during mount time and, if the server does not support it, appropriate capabilities | |
| 69 | −will be disabled or mount will fail (if 'crypto_fail_unsupported' mount option is specified). | |
| 70 | −Crypto performance heavily depends on the number of crypto threads, which asynchronously perform | |
| 71 | −crypto operations and send the resulting data to server or submit it up the stack. This number | |
| 72 | −can be controlled via a mount option. | |
| @@ -1,99 +0,0 @@ | ||
| 1 | −POHMELFS usage information. | |
| 2 | − | |
| 3 | −Mount options. | |
| 4 | −All but index, number of crypto threads and maximum IO size can changed via remount. | |
| 5 | − | |
| 6 | −idx=%u | |
| 7 | − Each mountpoint is associated with a special index via this option. | |
| 8 | − Administrator can add or remove servers from the given index, so all mounts, | |
| 9 | − which were attached to it, are updated. | |
| 10 | − Default it is 0. | |
| 11 | − | |
| 12 | −trans_scan_timeout=%u | |
| 13 | − This timeout, expressed in milliseconds, specifies time to scan transaction | |
| 14 | − trees looking for stale requests, which have to be resent, or if number of | |
| 15 | − retries exceed specified limit, dropped with error. | |
| 16 | − Default is 5 seconds. | |
| 17 | − | |
| 18 | −drop_scan_timeout=%u | |
| 19 | − Internal timeout, expressed in milliseconds, which specifies how frequently | |
| 20 | − inodes marked to be dropped are freed. It also specifies how frequently | |
| 21 | − the system checks that servers have to be added or removed from current working set. | |
| 22 | − Default is 1 second. | |
| 23 | − | |
| 24 | −wait_on_page_timeout=%u | |
| 25 | − Number of milliseconds to wait for reply from remote server for data reading command. | |
| 26 | − If this timeout is exceeded, reading returns an error. | |
| 27 | − Default is 5 seconds. | |
| 28 | − | |
| 29 | −trans_retries=%u | |
| 30 | − This is the number of times that a transaction will be resent to a server that did | |
| 31 | − not answer for the last @trans_scan_timeout milliseconds. | |
| 32 | − When the number of resends exceeds this limit, the transaction is completed with error. | |
| 33 | − Default is 5 resends. | |
| 34 | − | |
| 35 | −crypto_thread_num=%u | |
| 36 | − Number of crypto processing threads. Threads are used both for RX and TX traffic. | |
| 37 | − Default is 2, or no threads if crypto operations are not supported. | |
| 38 | − | |
| 39 | −trans_max_pages=%u | |
| 40 | − Maximum number of pages in a single transaction. This parameter also controls | |
| 41 | − the number of pages, allocated for crypto processing (each crypto thread has | |
| 42 | − pool of pages, the number of which is equal to 'trans_max_pages'. | |
| 43 | − Default is 100 pages. | |
| 44 | − | |
| 45 | −crypto_fail_unsupported | |
| 46 | − If specified, mount will fail if the server does not support requested crypto operations. | |
| 47 | − By default mount will disable non-matching crypto operations. | |
| 48 | − | |
| 49 | −mcache_timeout=%u | |
| 50 | − Maximum number of milliseconds to wait for the mcache objects to be processed. | |
| 51 | − Mcache includes locks (given lock should be granted by server), attributes (they should be | |
| 52 | − fully received in the given timeframe). | |
| 53 | − Default is 5 seconds. | |
| 54 | − | |
| 55 | −Usage examples. | |
| 56 | − | |
| 57 | −Add server server1.net:1025 into the working set with index $idx | |
| 58 | −with appropriate hash algorithm and key file and cipher algorithm, mode and key file: | |
| 59 | −$cfg A add -a server1.net -p 1025 -i $idx -K $hash_key -k $cipher_key | |
| 60 | − | |
| 61 | −Mount filesystem with given index $idx to /mnt mountpoint. | |
| 62 | −Client will connect to all servers specified in the working set via previous command: | |
| 63 | −mount -t pohmel -o idx=$idx q /mnt | |
| 64 | − | |
| 65 | −Change permissions to read-only (-I 1 option, '-I 2' - write-only, 3 - rw): | |
| 66 | −$cfg A modify -a server1.net -p 1025 -i $idx -I 1 | |
| 67 | − | |
| 68 | −Change IO priority to 123 (node with the highest priority gets read requests). | |
| 69 | −$cfg A modify -a server1.net -p 1025 -i $idx -P 123 | |
| 70 | − | |
| 71 | −One can check currect status of all connections in the mountstats file: | |
| 72 | −# cat /proc/$PID/mountstats | |
| 73 | −... | |
| 74 | −device none mounted on /mnt with fstype pohmel | |
| 75 | −idx addr(:port) socket_type protocol active priority permissions | |
| 76 | −0 server1.net:1026 1 6 1 250 1 | |
| 77 | −0 server2.net:1025 1 6 1 123 3 | |
| 78 | − | |
| 79 | −Server installation. | |
| 80 | − | |
| 81 | −Creating a server, which listens at port 1025 and 0.0.0.0 address. | |
| 82 | −Working root directory (note, that server chroots there, so you have to have appropriate permissions) | |
| 83 | −is set to /mnt, server will negotiate hash/cipher with client, in case client requested it, there | |
| 84 | −are appropriate key files. | |
| 85 | −Number of working threads is set to 10. | |
| 86 | − | |
| 87 | −# ./fserver -a 0.0.0.0 -p 1025 -r /mnt -w 10 -K hash_key -k cipher_key | |
| 88 | − | |
| 89 | − -A 6 - listen on ipv6 address. Default: Disabled. | |
| 90 | − -r root - path to root directory. Default: /tmp. | |
| 91 | − -a addr - listen address. Default: 0.0.0.0. | |
| 92 | − -p port - listen port. Default: 1025. | |
| 93 | − -w workers - number of workers per connected client. Default: 1. | |
| 94 | − -K file - hash key size. Default: none. | |
| 95 | − -k file - cipher key size. Default: none. | |
| 96 | − -h - this help. | |
| 97 | − | |
| 98 | −Number of worker threads specifies how many workers will be created for each client. | |
| 99 | −Bulk single-client transafers usually are better handled with smaller number (like 1-3). | |
| @@ -1,227 +0,0 @@ | ||
| 1 | −POHMELFS network protocol. | |
| 2 | − | |
| 3 | −Basic structure used in network communication is following command: | |
| 4 | − | |
| 5 | −struct netfs_cmd | |
| 6 | −{ | |
| 7 | − __u16 cmd; /* Command number */ | |
| 8 | − __u16 csize; /* Attached crypto information size */ | |
| 9 | − __u16 cpad; /* Attached padding size */ | |
| 10 | − __u16 ext; /* External flags */ | |
| 11 | − __u32 size; /* Size of the attached data */ | |
| 12 | − __u32 trans; /* Transaction id */ | |
| 13 | − __u64 id; /* Object ID to operate on. Used for feedback.*/ | |
| 14 | − __u64 start; /* Start of the object. */ | |
| 15 | − __u64 iv; /* IV sequence */ | |
| 16 | − __u8 data[0]; | |
| 17 | −}; | |
| 18 | − | |
| 19 | −Commands can be embedded into transaction command (which in turn has own command), | |
| 20 | −so one can extend protocol as needed without breaking backward compatibility as long | |
| 21 | −as old commands are supported. All string lengths include tail 0 byte. | |
| 22 | − | |
| 23 | −All commands are transferred over the network in big-endian. CPU endianness is used at the end peers. | |
| 24 | − | |
| 25 | −@cmd - command number, which specifies command to be processed. Following | |
| 26 | − commands are used currently: | |
| 27 | − | |
| 28 | − NETFS_READDIR = 1, /* Read directory for given inode number */ | |
| 29 | − NETFS_READ_PAGE, /* Read data page from the server */ | |
| 30 | − NETFS_WRITE_PAGE, /* Write data page to the server */ | |
| 31 | − NETFS_CREATE, /* Create directory entry */ | |
| 32 | − NETFS_REMOVE, /* Remove directory entry */ | |
| 33 | − NETFS_LOOKUP, /* Lookup single object */ | |
| 34 | − NETFS_LINK, /* Create a link */ | |
| 35 | − NETFS_TRANS, /* Transaction */ | |
| 36 | − NETFS_OPEN, /* Open intent */ | |
| 37 | − NETFS_INODE_INFO, /* Metadata cache coherency synchronization message */ | |
| 38 | − NETFS_PAGE_CACHE, /* Page cache invalidation message */ | |
| 39 | − NETFS_READ_PAGES, /* Read multiple contiguous pages in one go */ | |
| 40 | − NETFS_RENAME, /* Rename object */ | |
| 41 | − NETFS_CAPABILITIES, /* Capabilities of the client, for example supported crypto */ | |
| 42 | − NETFS_LOCK, /* Distributed lock message */ | |
| 43 | − NETFS_XATTR_SET, /* Set extended attribute */ | |
| 44 | − NETFS_XATTR_GET, /* Get extended attribute */ | |
| 45 | − | |
| 46 | −@ext - external flags. Used by different commands to specify some extra arguments | |
| 47 | − like partial size of the embedded objects or creation flags. | |
| 48 | − | |
| 49 | −@size - size of the attached data. For NETFS_READ_PAGE and NETFS_READ_PAGES no data is attached, | |
| 50 | − but size of the requested data is incorporated here. It does not include size of the command | |
| 51 | − header (struct netfs_cmd) itself. | |
| 52 | − | |
| 53 | −@id - id of the object this command operates on. Each command can use it for own purpose. | |
| 54 | − | |
| 55 | −@start - start of the object this command operates on. Each command can use it for own purpose. | |
| 56 | − | |
| 57 | −@csize, @cpad - size and padding size of the (attached if needed) crypto information. | |
| 58 | − | |
| 59 | −Command specifications. | |
| 60 | − | |
| 61 | −@NETFS_READDIR | |
| 62 | −This command is used to sync content of the remote dir to the client. | |
| 63 | − | |
| 64 | −@ext - length of the path to object. | |
| 65 | −@size - the same. | |
| 66 | −@id - local inode number of the directory to read. | |
| 67 | −@start - zero. | |
| 68 | − | |
| 69 | − | |
| 70 | −@NETFS_READ_PAGE | |
| 71 | −This command is used to read data from remote server. | |
| 72 | −Data size does not exceed local page cache size. | |
| 73 | − | |
| 74 | −@id - inode number. | |
| 75 | −@start - first byte offset. | |
| 76 | −@size - number of bytes to read plus length of the path to object. | |
| 77 | −@ext - object path length. | |
| 78 | − | |
| 79 | − | |
| 80 | −@NETFS_CREATE | |
| 81 | −Used to create object. | |
| 82 | −It does not require that all directories on top of the object were | |
| 83 | −already created, it will create them automatically. Each object has | |
| 84 | −associated @netfs_path_entry data structure, which contains creation | |
| 85 | −mode (permissions and type) and length of the name as long as name itself. | |
| 86 | − | |
| 87 | −@start - 0 | |
| 88 | −@size - size of the all data structures needed to create a path | |
| 89 | −@id - local inode number | |
| 90 | −@ext - 0 | |
| 91 | − | |
| 92 | − | |
| 93 | −@NETFS_REMOVE | |
| 94 | −Used to remove object. | |
| 95 | − | |
| 96 | −@ext - length of the path to object. | |
| 97 | −@size - the same. | |
| 98 | −@id - local inode number. | |
| 99 | −@start - zero. | |
| 100 | − | |
| 101 | − | |
| 102 | −@NETFS_LOOKUP | |
| 103 | −Lookup information about object on server. | |
| 104 | − | |
| 105 | −@ext - length of the path to object. | |
| 106 | −@size - the same. | |
| 107 | −@id - local inode number of the directory to look object in. | |
| 108 | −@start - local inode number of the object to look at. | |
| 109 | − | |
| 110 | − | |
| 111 | −@NETFS_LINK | |
| 112 | −Create hard of symlink. | |
| 113 | −Command is sent as "object_path|target_path". | |
| 114 | − | |
| 115 | −@size - size of the above string. | |
| 116 | −@id - parent local inode number. | |
| 117 | −@start - 1 for symlink, 0 for hardlink. | |
| 118 | −@ext - size of the "object_path" above. | |
| 119 | − | |
| 120 | − | |
| 121 | −@NETFS_TRANS | |
| 122 | −Transaction header. | |
| 123 | − | |
| 124 | −@size - incorporates all embedded command sizes including theirs header sizes. | |
| 125 | −@start - transaction generation number - unique id used to find transaction. | |
| 126 | −@ext - transaction flags. Unused at the moment. | |
| 127 | −@id - 0. | |
| 128 | − | |
| 129 | − | |
| 130 | −@NETFS_OPEN | |
| 131 | −Open intent for given transaction. | |
| 132 | − | |
| 133 | −@id - local inode number. | |
| 134 | −@start - 0. | |
| 135 | −@size - path length to the object. | |
| 136 | −@ext - open flags (O_RDWR and so on). | |
| 137 | − | |
| 138 | − | |
| 139 | −@NETFS_INODE_INFO | |
| 140 | −Metadata update command. | |
| 141 | −It is sent to servers when attributes of the object are changed and received | |
| 142 | −when data or metadata were updated. It operates with the following structure: | |
| 143 | − | |
| 144 | −struct netfs_inode_info | |
| 145 | −{ | |
| 146 | − unsigned int mode; | |
| 147 | − unsigned int nlink; | |
| 148 | − unsigned int uid; | |
| 149 | − unsigned int gid; | |
| 150 | − unsigned int blocksize; | |
| 151 | − unsigned int padding; | |
| 152 | − __u64 ino; | |
| 153 | − __u64 blocks; | |
| 154 | − __u64 rdev; | |
| 155 | − __u64 size; | |
| 156 | − __u64 version; | |
| 157 | −}; | |
| 158 | − | |
| 159 | −It effectively mirrors stat(2) returned data. | |
| 160 | − | |
| 161 | − | |
| 162 | −@ext - path length to the object. | |
| 163 | −@size - the same plus size of the netfs_inode_info structure. | |
| 164 | −@id - local inode number. | |
| 165 | −@start - 0. | |
| 166 | − | |
| 167 | − | |
| 168 | −@NETFS_PAGE_CACHE | |
| 169 | −Command is only received by clients. It contains information about | |
| 170 | −page to be marked as not up-to-date. | |
| 171 | − | |
| 172 | −@id - client's inode number. | |
| 173 | −@start - last byte of the page to be invalidated. If it is not equal to | |
| 174 | − current inode size, it will be vmtruncated(). | |
| 175 | −@size - 0 | |
| 176 | −@ext - 0 | |
| 177 | − | |
| 178 | − | |
| 179 | −@NETFS_READ_PAGES | |
| 180 | −Used to read multiple contiguous pages in one go. | |
| 181 | − | |
| 182 | −@start - first byte of the contiguous region to read. | |
| 183 | −@size - contains of two fields: lower 8 bits are used to represent page cache shift | |
| 184 | − used by client, another 3 bytes are used to get number of pages. | |
| 185 | −@id - local inode number. | |
| 186 | −@ext - path length to the object. | |
| 187 | − | |
| 188 | − | |
| 189 | −@NETFS_RENAME | |
| 190 | −Used to rename object. | |
| 191 | −Attached data is formed into following string: "old_path|new_path". | |
| 192 | − | |
| 193 | −@id - local inode number. | |
| 194 | −@start - parent inode number. | |
| 195 | −@size - length of the above string. | |
| 196 | −@ext - length of the old path part. | |
| 197 | − | |
| 198 | − | |
| 199 | −@NETFS_CAPABILITIES | |
| 200 | −Used to exchange crypto capabilities with server. | |
| 201 | −If crypto capabilities are not supported by server, then client will disable it | |
| 202 | −or fail (if 'crypto_fail_unsupported' mount options was specified). | |
| 203 | − | |
| 204 | −@id - superblock index. Used to specify crypto information for group of servers. | |
| 205 | −@size - size of the attached capabilities structure. | |
| 206 | −@start - 0. | |
| 207 | −@size - 0. | |
| 208 | −@scsize - 0. | |
| 209 | − | |
| 210 | −@NETFS_LOCK | |
| 211 | −Used to send lock request/release messages. Although it sends byte range request | |
| 212 | −and is capable of flushing pages based on that, it is not used, since all Linux | |
| 213 | −filesystems lock the whole inode. | |
| 214 | − | |
| 215 | −@id - lock generation number. | |
| 216 | −@start - start of the locked range. | |
| 217 | −@size - size of the locked range. | |
| 218 | −@ext - lock type: read/write. Not used actually. 15'th bit is used to determine, | |
| 219 | − if it is lock request (1) or release (0). | |
| 220 | − | |
| 221 | −@NETFS_XATTR_SET | |
| 222 | −@NETFS_XATTR_GET | |
| 223 | −Used to set/get extended attributes for given inode. | |
| 224 | −@id - attribute generation number or xattr setting type | |
| 225 | −@start - size of the attribute (request or attached) | |
| 226 | −@size - name length, path len and data size for given attribute | |
| 227 | −@ext - path length for given object | |
| @@ -622,3 +622,19 @@ in your dentry operations instead. · 621 unmodified lines | ||
| 622 | 622 | alloc_file_clone(file, flags, ops) does not affect any caller's references. |
| 623 | 623 | On success you get a new struct file sharing the mount/dentry with the |
| 624 | 624 | original, on failure - ERR_PTR(). |
| 625 | +-- | |
| 626 | +[mandatory] | |
| 627 | + ->clone_file_range() and ->dedupe_file_range have been replaced with | |
| 628 | + ->remap_file_range(). See Documentation/filesystems/vfs.txt for more | |
| 629 | + information. | |
| 630 | +-- | |
| 631 | +[recommended] | |
| 632 | + ->lookup() instances doing an equivalent of | |
| 633 | + if (IS_ERR(inode)) | |
| 634 | + return ERR_CAST(inode); | |
| 635 | + return d_splice_alias(inode, dentry); | |
| 636 | + don't need to bother with the check - d_splice_alias() will do the | |
| 637 | + right thing when given ERR_PTR(...) as inode. Moreover, passing NULL | |
| 638 | + inode to d_splice_alias() will also do the right thing (equivalent of | |
| 639 | + d_add(dentry, NULL); return NULL;), so that kind of special cases | |
| 640 | + also doesn't need a separate treatment. | |
| @@ -858,6 +858,7 @@ Writeback: 0 kB · 857 unmodified lines | ||
| 858 | 858 | AnonPages: 861800 kB |
| 859 | 859 | Mapped: 280372 kB |
| 860 | 860 | Shmem: 644 kB |
| 861 | +KReclaimable: 168048 kB | |
| 861 | 862 | Slab: 284364 kB |
| 862 | 863 | SReclaimable: 159856 kB |
| 863 | 864 | SUnreclaim: 124508 kB |
| @@ -925,6 +926,9 @@ AnonHugePages: Non-file backed huge pages mapped into userspace page tables · 61 unmodified lines | ||
| 925 | 926 | ShmemHugePages: Memory used by shared memory (shmem) and tmpfs allocated |
| 926 | 927 | with huge pages |
| 927 | 928 | ShmemPmdMapped: Shared memory mapped into userspace with huge pages |
| 929 | +KReclaimable: Kernel allocations that the kernel will attempt to reclaim | |
| 930 | + under memory pressure. Includes SReclaimable (below), and other | |
| 931 | + direct allocations with a shrinker. | |
| 928 | 932 | Slab: in-kernel data structures cache |
| 929 | 933 | SReclaimable: Part of Slab, that might be reclaimed, such as caches |
| 930 | 934 | SUnreclaim: Part of Slab, that cannot be reclaimed on memory pressure |
| @@ -0,0 +1,426 @@ | ||
| 1 | +% UBIFS Authentication | |
| 2 | +% sigma star gmbh | |
| 3 | +% 2018 | |
| 4 | + | |
| 5 | +# Introduction | |
| 6 | + | |
| 7 | +UBIFS utilizes the fscrypt framework to provide confidentiality for file | |
| 8 | +contents and file names. This prevents attacks where an attacker is able to | |
| 9 | +read contents of the filesystem on a single point in time. A classic example | |
| 10 | +is a lost smartphone where the attacker is unable to read personal data stored | |
| 11 | +on the device without the filesystem decryption key. | |
| 12 | + | |
| 13 | +At the current state, UBIFS encryption however does not prevent attacks where | |
| 14 | +the attacker is able to modify the filesystem contents and the user uses the | |
| 15 | +device afterwards. In such a scenario an attacker can modify filesystem | |
| 16 | +contents arbitrarily without the user noticing. One example is to modify a | |
| 17 | +binary to perform a malicious action when executed [DMC-CBC-ATTACK]. Since | |
| 18 | +most of the filesystem metadata of UBIFS is stored in plain, this makes it | |
| 19 | +fairly easy to swap files and replace their contents. | |
| 20 | + | |
| 21 | +Other full disk encryption systems like dm-crypt cover all filesystem metadata, | |
| 22 | +which makes such kinds of attacks more complicated, but not impossible. | |
| 23 | +Especially, if the attacker is given access to the device multiple points in | |
| 24 | +time. For dm-crypt and other filesystems that build upon the Linux block IO | |
| 25 | +layer, the dm-integrity or dm-verity subsystems [DM-INTEGRITY, DM-VERITY] | |
| 26 | +can be used to get full data authentication at the block layer. | |
| 27 | +These can also be combined with dm-crypt [CRYPTSETUP2]. | |
| 28 | + | |
| 29 | +This document describes an approach to get file contents _and_ full metadata | |
| 30 | +authentication for UBIFS. Since UBIFS uses fscrypt for file contents and file | |
| 31 | +name encryption, the authentication system could be tied into fscrypt such that | |
| 32 | +existing features like key derivation can be utilized. It should however also | |
| 33 | +be possible to use UBIFS authentication without using encryption. | |
| 34 | + | |
| 35 | + | |
| 36 | +## MTD, UBI & UBIFS | |
| 37 | + | |
| 38 | +On Linux, the MTD (Memory Technology Devices) subsystem provides a uniform | |
| 39 | +interface to access raw flash devices. One of the more prominent subsystems that | |
| 40 | +work on top of MTD is UBI (Unsorted Block Images). It provides volume management | |
| 41 | +for flash devices and is thus somewhat similar to LVM for block devices. In | |
| 42 | +addition, it deals with flash-specific wear-leveling and transparent I/O error | |
| 43 | +handling. UBI offers logical erase blocks (LEBs) to the layers on top of it | |
| 44 | +and maps them transparently to physical erase blocks (PEBs) on the flash. | |
| 45 | + | |
| 46 | +UBIFS is a filesystem for raw flash which operates on top of UBI. Thus, wear | |
| 47 | +leveling and some flash specifics are left to UBI, while UBIFS focuses on | |
| 48 | +scalability, performance and recoverability. | |
| 49 | + | |
| 50 | + | |
| 51 | + | |
| 52 | + +------------+ +*******+ +-----------+ +-----+ | |
| 53 | + | | * UBIFS * | UBI-BLOCK | | ... | | |
| 54 | + | JFFS/JFFS2 | +*******+ +-----------+ +-----+ | |
| 55 | + | | +-----------------------------+ +-----------+ +-----+ | |
| 56 | + | | | UBI | | MTD-BLOCK | | ... | | |
| 57 | + +------------+ +-----------------------------+ +-----------+ +-----+ | |
| 58 | + +------------------------------------------------------------------+ | |
| 59 | + | MEMORY TECHNOLOGY DEVICES (MTD) | | |
| 60 | + +------------------------------------------------------------------+ | |
| 61 | + +-----------------------------+ +--------------------------+ +-----+ | |
| 62 | + | NAND DRIVERS | | NOR DRIVERS | | ... | | |
| 63 | + +-----------------------------+ +--------------------------+ +-----+ | |
| 64 | + | |
| 65 | + Figure 1: Linux kernel subsystems for dealing with raw flash | |
| 66 | + | |
| 67 | + | |
| 68 | + | |
| 69 | +Internally, UBIFS maintains multiple data structures which are persisted on | |
| 70 | +the flash: | |
| 71 | + | |
| 72 | +- *Index*: an on-flash B+ tree where the leaf nodes contain filesystem data | |
| 73 | +- *Journal*: an additional data structure to collect FS changes before updating | |
| 74 | + the on-flash index and reduce flash wear. | |
| 75 | +- *Tree Node Cache (TNC)*: an in-memory B+ tree that reflects the current FS | |
| 76 | + state to avoid frequent flash reads. It is basically the in-memory | |
| 77 | + representation of the index, but contains additional attributes. | |
| 78 | +- *LEB property tree (LPT)*: an on-flash B+ tree for free space accounting per | |
| 79 | + UBI LEB. | |
| 80 | + | |
| 81 | +In the remainder of this section we will cover the on-flash UBIFS data | |
| 82 | +structures in more detail. The TNC is of less importance here since it is never | |
| 83 | +persisted onto the flash directly. More details on UBIFS can also be found in | |
| 84 | +[UBIFS-WP]. | |
| 85 | + | |
| 86 | + | |
| 87 | +### UBIFS Index & Tree Node Cache | |
| 88 | + | |
| 89 | +Basic on-flash UBIFS entities are called *nodes*. UBIFS knows different types | |
| 90 | +of nodes. Eg. data nodes (`struct ubifs_data_node`) which store chunks of file | |
| 91 | +contents or inode nodes (`struct ubifs_ino_node`) which represent VFS inodes. | |
| 92 | +Almost all types of nodes share a common header (`ubifs_ch`) containing basic | |
| 93 | +information like node type, node length, a sequence number, etc. (see | |
| 94 | +`fs/ubifs/ubifs-media.h`in kernel source). Exceptions are entries of the LPT | |
| 95 | +and some less important node types like padding nodes which are used to pad | |
| 96 | +unusable content at the end of LEBs. | |
| 97 | + | |
| 98 | +To avoid re-writing the whole B+ tree on every single change, it is implemented | |
| 99 | +as *wandering tree*, where only the changed nodes are re-written and previous | |
| 100 | +versions of them are obsoleted without erasing them right away. As a result, | |
| 101 | +the index is not stored in a single place on the flash, but *wanders* around | |
| 102 | +and there are obsolete parts on the flash as long as the LEB containing them is | |
| 103 | +not reused by UBIFS. To find the most recent version of the index, UBIFS stores | |
| 104 | +a special node called *master node* into UBI LEB 1 which always points to the | |
| 105 | +most recent root node of the UBIFS index. For recoverability, the master node | |
| 106 | +is additionally duplicated to LEB 2. Mounting UBIFS is thus a simple read of | |
| 107 | +LEB 1 and 2 to get the current master node and from there get the location of | |
| 108 | +the most recent on-flash index. | |
| 109 | + | |
| 110 | +The TNC is the in-memory representation of the on-flash index. It contains some | |
| 111 | +additional runtime attributes per node which are not persisted. One of these is | |
| 112 | +a dirty-flag which marks nodes that have to be persisted the next time the | |
| 113 | +index is written onto the flash. The TNC acts as a write-back cache and all | |
| 114 | +modifications of the on-flash index are done through the TNC. Like other caches, | |
| 115 | +the TNC does not have to mirror the full index into memory, but reads parts of | |
| 116 | +it from flash whenever needed. A *commit* is the UBIFS operation of updating the | |
| 117 | +on-flash filesystem structures like the index. On every commit, the TNC nodes | |
| 118 | +marked as dirty are written to the flash to update the persisted index. | |
| 119 | + | |
| 120 | + | |
| 121 | +### Journal | |
| 122 | + | |
| 123 | +To avoid wearing out the flash, the index is only persisted (*commited*) when | |
| 124 | +certain conditions are met (eg. `fsync(2)`). The journal is used to record | |
| 125 | +any changes (in form of inode nodes, data nodes etc.) between commits | |
| 126 | +of the index. During mount, the journal is read from the flash and replayed | |
| 127 | +onto the TNC (which will be created on-demand from the on-flash index). | |
| 128 | + | |
| 129 | +UBIFS reserves a bunch of LEBs just for the journal called *log area*. The | |
| 130 | +amount of log area LEBs is configured on filesystem creation (using | |
| 131 | +`mkfs.ubifs`) and stored in the superblock node. The log area contains only | |
| 132 | +two types of nodes: *reference nodes* and *commit start nodes*. A commit start | |
| 133 | +node is written whenever an index commit is performed. Reference nodes are | |
| 134 | +written on every journal update. Each reference node points to the position of | |
| 135 | +other nodes (inode nodes, data nodes etc.) on the flash that are part of this | |
| 136 | +journal entry. These nodes are called *buds* and describe the actual filesystem | |
| 137 | +changes including their data. | |
| 138 | + | |
| 139 | +The log area is maintained as a ring. Whenever the journal is almost full, | |
| 140 | +a commit is initiated. This also writes a commit start node so that during | |
| 141 | +mount, UBIFS will seek for the most recent commit start node and just replay | |
| 142 | +every reference node after that. Every reference node before the commit start | |
| 143 | +node will be ignored as they are already part of the on-flash index. | |
| 144 | + | |
| 145 | +When writing a journal entry, UBIFS first ensures that enough space is | |
| 146 | +available to write the reference node and buds part of this entry. Then, the | |
| 147 | +reference node is written and afterwards the buds describing the file changes. | |
| 148 | +On replay, UBIFS will record every reference node and inspect the location of | |
| 149 | +the referenced LEBs to discover the buds. If these are corrupt or missing, | |
| 150 | +UBIFS will attempt to recover them by re-reading the LEB. This is however only | |
| 151 | +done for the last referenced LEB of the journal. Only this can become corrupt | |
| 152 | +because of a power cut. If the recovery fails, UBIFS will not mount. An error | |
| 153 | +for every other LEB will directly cause UBIFS to fail the mount operation. | |
| 154 | + | |
| 155 | + | |
| 156 | + | ---- LOG AREA ---- | ---------- MAIN AREA ------------ | | |
| 157 | + | |
| 158 | + -----+------+-----+--------+---- ------+-----+-----+--------------- | |
| 159 | + \ | | | | / / | | | \ | |
| 160 | + / CS | REF | REF | | \ \ DENT | INO | INO | / | |
| 161 | + \ | | | | / / | | | \ | |
| 162 | + ----+------+-----+--------+--- -------+-----+-----+---------------- | |
| 163 | + | | ^ ^ | |
| 164 | + | | | | | |
| 165 | + +------------------------+ | | |
| 166 | + | | | |
| 167 | + +-------------------------------+ | |
| 168 | + | |
| 169 | + | |
| 170 | + Figure 2: UBIFS flash layout of log area with commit start nodes | |
| 171 | + (CS) and reference nodes (REF) pointing to main area | |
| 172 | + containing their buds | |
| 173 | + | |
| 174 | + | |
| 175 | +### LEB Property Tree/Table | |
| 176 | + | |
| 177 | +The LEB property tree is used to store per-LEB information. This includes the | |
| 178 | +LEB type and amount of free and *dirty* (old, obsolete content) space [1] on | |
| 179 | +the LEB. The type is important, because UBIFS never mixes index nodes with data | |
| 180 | +nodes on a single LEB and thus each LEB has a specific purpose. This again is | |
| 181 | +useful for free space calculations. See [UBIFS-WP] for more details. | |
| 182 | + | |
| 183 | +The LEB property tree again is a B+ tree, but it is much smaller than the | |
| 184 | +index. Due to its smaller size it is always written as one chunk on every | |
| 185 | +commit. Thus, saving the LPT is an atomic operation. | |
| 186 | + | |
| 187 | + | |
| 188 | +[1] Since LEBs can only be appended and never overwritten, there is a | |
| 189 | +difference between free space ie. the remaining space left on the LEB to be | |
| 190 | +written to without erasing it and previously written content that is obsolete | |
| 191 | +but can't be overwritten without erasing the full LEB. | |
| 192 | + | |
| 193 | + | |
| 194 | +# UBIFS Authentication | |
| 195 | + | |
| 196 | +This chapter introduces UBIFS authentication which enables UBIFS to verify | |
| 197 | +the authenticity and integrity of metadata and file contents stored on flash. | |
| 198 | + | |
| 199 | + | |
| 200 | +## Threat Model | |
| 201 | + | |
| 202 | +UBIFS authentication enables detection of offline data modification. While it | |
| 203 | +does not prevent it, it enables (trusted) code to check the integrity and | |
| 204 | +authenticity of on-flash file contents and filesystem metadata. This covers | |
| 205 | +attacks where file contents are swapped. | |
| 206 | + | |
| 207 | +UBIFS authentication will not protect against rollback of full flash contents. | |
| 208 | +Ie. an attacker can still dump the flash and restore it at a later time without | |
| 209 | +detection. It will also not protect against partial rollback of individual | |
| 210 | +index commits. That means that an attacker is able to partially undo changes. | |
| 211 | +This is possible because UBIFS does not immediately overwrites obsolete | |
| 212 | +versions of the index tree or the journal, but instead marks them as obsolete | |
| 213 | +and garbage collection erases them at a later time. An attacker can use this by | |
| 214 | +erasing parts of the current tree and restoring old versions that are still on | |
| 215 | +the flash and have not yet been erased. This is possible, because every commit | |
| 216 | +will always write a new version of the index root node and the master node | |
| 217 | +without overwriting the previous version. This is further helped by the | |
| 218 | +wear-leveling operations of UBI which copies contents from one physical | |
| 219 | +eraseblock to another and does not atomically erase the first eraseblock. | |
| 220 | + | |
| 221 | +UBIFS authentication does not cover attacks where an attacker is able to | |
| 222 | +execute code on the device after the authentication key was provided. | |
| 223 | +Additional measures like secure boot and trusted boot have to be taken to | |
| 224 | +ensure that only trusted code is executed on a device. | |
| 225 | + | |
| 226 | + | |
| 227 | +## Authentication | |
| 228 | + | |
| 229 | +To be able to fully trust data read from flash, all UBIFS data structures | |
| 230 | +stored on flash are authenticated. That is: | |
| 231 | + | |
| 232 | +- The index which includes file contents, file metadata like extended | |
| 233 | + attributes, file length etc. | |
| 234 | +- The journal which also contains file contents and metadata by recording changes | |
| 235 | + to the filesystem | |
| 236 | +- The LPT which stores UBI LEB metadata which UBIFS uses for free space accounting | |
| 237 | + | |
| 238 | + | |
| 239 | +### Index Authentication | |
| 240 | + | |
| 241 | +Through UBIFS' concept of a wandering tree, it already takes care of only | |
| 242 | +updating and persisting changed parts from leaf node up to the root node | |
| 243 | +of the full B+ tree. This enables us to augment the index nodes of the tree | |
| 244 | +with a hash over each node's child nodes. As a result, the index basically also | |
| 245 | +a Merkle tree. Since the leaf nodes of the index contain the actual filesystem | |
| 246 | +data, the hashes of their parent index nodes thus cover all the file contents | |
| 247 | +and file metadata. When a file changes, the UBIFS index is updated accordingly | |
| 248 | +from the leaf nodes up to the root node including the master node. This process | |
| 249 | +can be hooked to recompute the hash only for each changed node at the same time. | |
| 250 | +Whenever a file is read, UBIFS can verify the hashes from each leaf node up to | |
| 251 | +the root node to ensure the node's integrity. | |
| 252 | + | |
| 253 | +To ensure the authenticity of the whole index, the UBIFS master node stores a | |
| 254 | +keyed hash (HMAC) over its own contents and a hash of the root node of the index | |
| 255 | +tree. As mentioned above, the master node is always written to the flash whenever | |
| 256 | +the index is persisted (ie. on index commit). | |
| 257 | + | |
| 258 | +Using this approach only UBIFS index nodes and the master node are changed to | |
| 259 | +include a hash. All other types of nodes will remain unchanged. This reduces | |
| 260 | +the storage overhead which is precious for users of UBIFS (ie. embedded | |
| 261 | +devices). | |
| 262 | + | |
| 263 | + | |
| 264 | + +---------------+ | |
| 265 | + | Master Node | | |
| 266 | + | (hash) | | |
| 267 | + +---------------+ | |
| 268 | + | | |
| 269 | + v | |
| 270 | + +-------------------+ | |
| 271 | + | Index Node #1 | | |
| 272 | + | | | |
| 273 | + | branch0 branchn | | |
| 274 | + | (hash) (hash) | | |
| 275 | + +-------------------+ | |
| 276 | + | ... | (fanout: 8) | |
| 277 | + | | | |
| 278 | + +-------+ +------+ | |
| 279 | + | | | |
| 280 | + v v | |
| 281 | + +-------------------+ +-------------------+ | |
| 282 | + | Index Node #2 | | Index Node #3 | | |
| 283 | + | | | | | |
| 284 | + | branch0 branchn | | branch0 branchn | | |
| 285 | + | (hash) (hash) | | (hash) (hash) | | |
| 286 | + +-------------------+ +-------------------+ | |
| 287 | + | ... | ... | | |
| 288 | + v v v | |
| 289 | + +-----------+ +----------+ +-----------+ | |
| 290 | + | Data Node | | INO Node | | DENT Node | | |
| 291 | + +-----------+ +----------+ +-----------+ | |
| 292 | + | |
| 293 | + | |
| 294 | + Figure 3: Coverage areas of index node hash and master node HMAC | |
| 295 | + | |
| 296 | + | |
| 297 | + | |
| 298 | +The most important part for robustness and power-cut safety is to atomically | |
| 299 | +persist the hash and file contents. Here the existing UBIFS logic for how | |
| 300 | +changed nodes are persisted is already designed for this purpose such that | |
| 301 | +UBIFS can safely recover if a power-cut occurs while persisting. Adding | |
| 302 | +hashes to index nodes does not change this since each hash will be persisted | |
| 303 | +atomically together with its respective node. | |
| 304 | + | |
| 305 | + | |
| 306 | +### Journal Authentication | |
| 307 | + | |
| 308 | +The journal is authenticated too. Since the journal is continuously written | |
| 309 | +it is necessary to also add authentication information frequently to the | |
| 310 | +journal so that in case of a powercut not too much data can't be authenticated. | |
| 311 | +This is done by creating a continuous hash beginning from the commit start node | |
| 312 | +over the previous reference nodes, the current reference node, and the bud | |
| 313 | +nodes. From time to time whenever it is suitable authentication nodes are added | |
| 314 | +between the bud nodes. This new node type contains a HMAC over the current state | |
| 315 | +of the hash chain. That way a journal can be authenticated up to the last | |
| 316 | +authentication node. The tail of the journal which may not have a authentication | |
| 317 | +node cannot be authenticated and is skipped during journal replay. | |
| 318 | + | |
| 319 | +We get this picture for journal authentication: | |
| 320 | + | |
| 321 | + ,,,,,,,, | |
| 322 | + ,......,........................................... | |
| 323 | + ,. CS , hash1.----. hash2.----. | |
| 324 | + ,. | , . |hmac . |hmac | |
| 325 | + ,. v , . v . v | |
| 326 | + ,.REF#0,-> bud -> bud -> bud.-> auth -> bud -> bud.-> auth ... | |
| 327 | + ,..|...,........................................... | |
| 328 | + , | , | |
| 329 | + , | ,,,,,,,,,,,,,,, | |
| 330 | + . | hash3,----. | |
| 331 | + , | , |hmac | |
| 332 | + , v , v | |
| 333 | + , REF#1 -> bud -> bud,-> auth ... | |
| 334 | + ,,,|,,,,,,,,,,,,,,,,,, | |
| 335 | + v | |
| 336 | + REF#2 -> ... | |
| 337 | + | | |
| 338 | + V | |
| 339 | + ... | |
| 340 | + | |
| 341 | +Since the hash also includes the reference nodes an attacker cannot reorder or | |
| 342 | +skip any journal heads for replay. An attacker can only remove bud nodes or | |
| 343 | +reference nodes from the end of the journal, effectively rewinding the | |
| 344 | +filesystem at maximum back to the last commit. | |
| 345 | + | |
| 346 | +The location of the log area is stored in the master node. Since the master | |
| 347 | +node is authenticated with a HMAC as described above, it is not possible to | |
| 348 | +tamper with that without detection. The size of the log area is specified when | |
| 349 | +the filesystem is created using `mkfs.ubifs` and stored in the superblock node. | |
| 350 | +To avoid tampering with this and other values stored there, a HMAC is added to | |
| 351 | +the superblock struct. The superblock node is stored in LEB 0 and is only | |
| 352 | +modified on feature flag or similar changes, but never on file changes. | |
| 353 | + | |
| 354 | + | |
| 355 | +### LPT Authentication | |
| 356 | + | |
| 357 | +The location of the LPT root node on the flash is stored in the UBIFS master | |
| 358 | +node. Since the LPT is written and read atomically on every commit, there is | |
| 359 | +no need to authenticate individual nodes of the tree. It suffices to | |
| 360 | +protect the integrity of the full LPT by a simple hash stored in the master | |
| 361 | +node. Since the master node itself is authenticated, the LPTs authenticity can | |
| 362 | +be verified by verifying the authenticity of the master node and comparing the | |
| 363 | +LTP hash stored there with the hash computed from the read on-flash LPT. | |
| 364 | + | |
| 365 | + | |
| 366 | +## Key Management | |
| 367 | + | |
| 368 | +For simplicity, UBIFS authentication uses a single key to compute the HMACs | |
| 369 | +of superblock, master, commit start and reference nodes. This key has to be | |
| 370 | +available on creation of the filesystem (`mkfs.ubifs`) to authenticate the | |
| 371 | +superblock node. Further, it has to be available on mount of the filesystem | |
| 372 | +to verify authenticated nodes and generate new HMACs for changes. | |
| 373 | + | |
| 374 | +UBIFS authentication is intended to operate side-by-side with UBIFS encryption | |
| 375 | +(fscrypt) to provide confidentiality and authenticity. Since UBIFS encryption | |
| 376 | +has a different approach of encryption policies per directory, there can be | |
| 377 | +multiple fscrypt master keys and there might be folders without encryption. | |
| 378 | +UBIFS authentication on the other hand has an all-or-nothing approach in the | |
| 379 | +sense that it either authenticates everything of the filesystem or nothing. | |
| 380 | +Because of this and because UBIFS authentication should also be usable without | |
| 381 | +encryption, it does not share the same master key with fscrypt, but manages | |
| 382 | +a dedicated authentication key. | |
| 383 | + | |
| 384 | +The API for providing the authentication key has yet to be defined, but the | |
| 385 | +key can eg. be provided by userspace through a keyring similar to the way it | |
| 386 | +is currently done in fscrypt. It should however be noted that the current | |
| 387 | +fscrypt approach has shown its flaws and the userspace API will eventually | |
| 388 | +change [FSCRYPT-POLICY2]. | |
| 389 | + | |
| 390 | +Nevertheless, it will be possible for a user to provide a single passphrase | |
| 391 | +or key in userspace that covers UBIFS authentication and encryption. This can | |
| 392 | +be solved by the corresponding userspace tools which derive a second key for | |
| 393 | +authentication in addition to the derived fscrypt master key used for | |
| 394 | +encryption. | |
| 395 | + | |
| 396 | +To be able to check if the proper key is available on mount, the UBIFS | |
| 397 | +superblock node will additionally store a hash of the authentication key. This | |
| 398 | +approach is similar to the approach proposed for fscrypt encryption policy v2 | |
| 399 | +[FSCRYPT-POLICY2]. | |
| 400 | + | |
| 401 | + | |
| 402 | +# Future Extensions | |
| 403 | + | |
| 404 | +In certain cases where a vendor wants to provide an authenticated filesystem | |
| 405 | +image to customers, it should be possible to do so without sharing the secret | |
| 406 | +UBIFS authentication key. Instead, in addition the each HMAC a digital | |
| 407 | +signature could be stored where the vendor shares the public key alongside the | |
| 408 | +filesystem image. In case this filesystem has to be modified afterwards, | |
| 409 | +UBIFS can exchange all digital signatures with HMACs on first mount similar | |
| 410 | +to the way the IMA/EVM subsystem deals with such situations. The HMAC key | |
| 411 | +will then have to be provided beforehand in the normal way. | |
| 412 | + | |
| 413 | + | |
| 414 | +# References | |
| 415 | + | |
| 416 | +[CRYPTSETUP2] http://www.saout.de/pipermail/dm-crypt/2017-November/005745.html | |
| 417 | + | |
| 418 | +[DMC-CBC-ATTACK] http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/ | |
| 419 | + | |
| 420 | +[DM-INTEGRITY] https://www.kernel.org/doc/Documentation/device-mapper/dm-integrity.txt | |
| 421 | + | |
| 422 | +[DM-VERITY] https://www.kernel.org/doc/Documentation/device-mapper/verity.txt | |
| 423 | + | |
| 424 | +[FSCRYPT-POLICY2] https://www.spinics.net/lists/linux-ext4/msg58710.html | |
| 425 | + | |
| 426 | +[UBIFS-WP] http://www.linux-mtd.infradead.org/doc/ubifs_whitepaper.pdf | |
| @@ -91,6 +91,13 @@ chk_data_crc do not skip checking CRCs on data nodes · 90 unmodified lines | ||
| 91 | 91 | compr=none override default compressor and set it to "none" |
| 92 | 92 | compr=lzo override default compressor and set it to "lzo" |
| 93 | 93 | compr=zlib override default compressor and set it to "zlib" |
| 94 | +auth_key= specify the key used for authenticating the filesystem. | |
| 95 | + Passing this option makes authentication mandatory. | |
| 96 | + The passed key must be present in the kernel keyring | |
| 97 | + and must be of type 'logon' | |
| 98 | +auth_hash_name= The hash algorithm used for authentication. Used for | |
| 99 | + both hashing and for creating HMACs. Typical values | |
| 100 | + include "sha256" or "sha512" | |
| 94 | 101 | |
| 95 | 102 | |
| 96 | 103 | Quick usage instructions |
| @@ -883,8 +883,9 @@ struct file_operations { · 882 unmodified lines | ||
| 883 | 883 | unsigned (*mmap_capabilities)(struct file *); |
| 884 | 884 | #endif |
| 885 | 885 | ssize_t (*copy_file_range)(struct file *, loff_t, struct file *, loff_t, size_t, unsigned int); |
| 886 | − int (*clone_file_range)(struct file *, loff_t, struct file *, loff_t, u64); | |
| 887 | − int (*dedupe_file_range)(struct file *, loff_t, struct file *, loff_t, u64); | |
| 886 | + loff_t (*remap_file_range)(struct file *file_in, loff_t pos_in, | |
| 887 | + struct file *file_out, loff_t pos_out, | |
| 888 | + loff_t len, unsigned int remap_flags); | |
| 888 | 889 | int (*fadvise)(struct file *, loff_t, loff_t, int); |
| 889 | 890 | }; |
| 890 | 891 | |
| @@ -960,11 +961,18 @@ otherwise noted. · 69 unmodified lines | ||
| 960 | 961 | |
| 961 | 962 | copy_file_range: called by the copy_file_range(2) system call. |
| 962 | 963 | |
| 963 | − clone_file_range: called by the ioctl(2) system call for FICLONERANGE and | |
| 964 | − FICLONE commands. | |
| 965 | − | |
| 966 | − dedupe_file_range: called by the ioctl(2) system call for FIDEDUPERANGE | |
| 967 | − command. | |
| 964 | + remap_file_range: called by the ioctl(2) system call for FICLONERANGE and | |
| 965 | + FICLONE and FIDEDUPERANGE commands to remap file ranges. An | |
| 966 | + implementation should remap len bytes at pos_in of the source file into | |
| 967 | + the dest file at pos_out. Implementations must handle callers passing | |
| 968 | + in len == 0; this means "remap to the end of the source file". The | |
| 969 | + return value should the number of bytes remapped, or the usual | |
| 970 | + negative error code if errors occurred before any bytes were remapped. | |
| 971 | + The remap_flags parameter accepts REMAP_FILE_* flags. If | |
| 972 | + REMAP_FILE_DEDUP is set then the implementation must only remap if the | |
| 973 | + requested file ranges have identical contents. If REMAP_CAN_SHORTEN is | |
| 974 | + set, the caller is ok with the implementation shortening the request | |
| 975 | + length to satisfy alignment or EOF requirements (or any other reason). | |
| 968 | 976 | |
| 969 | 977 | fadvise: possibly called by the fadvise64() system call. |
| 970 | 978 | |
| @@ -1,38 +0,0 @@ | ||
| 1 | − | |
| 2 | −Documentation in this directory comes from sections of the manual we | |
| 3 | −wrote for the externally-developed fmc-bus package. The complete | |
| 4 | −manual as of today (2013-02) is available in PDF format at | |
| 5 | −http://www.ohwr.org/projects/fmc-bus/files | |
| 6 | − | |
| 7 | −00-INDEX | |
| 8 | − - this file. | |
| 9 | − | |
| 10 | −FMC-and-SDB.txt | |
| 11 | − - What are FMC and SDB, basic concepts for this framework | |
| 12 | − | |
| 13 | −API.txt | |
| 14 | − - The functions that are exported by the bus driver | |
| 15 | − | |
| 16 | −parameters.txt | |
| 17 | − - The module parameters | |
| 18 | − | |
| 19 | −carrier.txt | |
| 20 | − - writing a carrier (a device) | |
| 21 | − | |
| 22 | −mezzanine.txt | |
| 23 | − - writing code for your mezzanine (a driver) | |
| 24 | − | |
| 25 | −identifiers.txt | |
| 26 | − - how identification and matching works | |
| 27 | − | |
| 28 | −fmc-fakedev.txt | |
| 29 | − - about drivers/fmc/fmc-fakedev.ko | |
| 30 | − | |
| 31 | −fmc-trivial.txt | |
| 32 | − - about drivers/fmc/fmc-trivial.ko | |
| 33 | − | |
| 34 | −fmc-write-eeprom.txt | |
| 35 | − - about drivers/fmc/fmc-write-eeprom.ko | |
| 36 | − | |
| 37 | −fmc-chardev.txt | |
| 38 | − - about drivers/fmc/fmc-chardev.ko | |
| @@ -1,4 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - This file | |
| 3 | −sysfs.txt | |
| 4 | − - Information about the GPIO sysfs interface | |
| @@ -0,0 +1,68 @@ | ||
| 1 | +=================================== | |
| 2 | +drm/amd/display - Display Core (DC) | |
| 3 | +=================================== | |
| 4 | + | |
| 5 | +*placeholder - general description of supported platforms, what dc is, etc.* | |
| 6 | + | |
| 7 | +Because it is partially shared with other operating systems, the Display Core | |
| 8 | +Driver is divided in two pieces. | |
| 9 | + | |
| 10 | +1. **Display Core (DC)** contains the OS-agnostic components. Things like | |
| 11 | + hardware programming and resource management are handled here. | |
| 12 | +2. **Display Manager (DM)** contains the OS-dependent components. Hooks to the | |
| 13 | + amdgpu base driver and DRM are implemented here. | |
| 14 | + | |
| 15 | +It doesn't help that the entire package is frequently referred to as DC. But | |
| 16 | +with the context in mind, it should be clear. | |
| 17 | + | |
| 18 | +When CONFIG_DRM_AMD_DC is enabled, DC will be initialized by default for | |
| 19 | +supported ASICs. To force disable, set `amdgpu.dc=0` on kernel command line. | |
| 20 | +Likewise, to force enable on unsupported ASICs, set `amdgpu.dc=1`. | |
| 21 | + | |
| 22 | +To determine if DC is loaded, search dmesg for the following entry: | |
| 23 | + | |
| 24 | +``Display Core initialized with <version number here>`` | |
| 25 | + | |
| 26 | +AMDgpu Display Manager | |
| 27 | +====================== | |
| 28 | + | |
| 29 | +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | |
| 30 | + :doc: overview | |
| 31 | + | |
| 32 | +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | |
| 33 | + :internal: | |
| 34 | + | |
| 35 | +Lifecycle | |
| 36 | +--------- | |
| 37 | + | |
| 38 | +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | |
| 39 | + :doc: DM Lifecycle | |
| 40 | + | |
| 41 | +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | |
| 42 | + :functions: dm_hw_init dm_hw_fini | |
| 43 | + | |
| 44 | +Interrupts | |
| 45 | +---------- | |
| 46 | + | |
| 47 | +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | |
| 48 | + :doc: overview | |
| 49 | + | |
| 50 | +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | |
| 51 | + :internal: | |
| 52 | + | |
| 53 | +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | |
| 54 | + :functions: register_hpd_handlers dm_crtc_high_irq dm_pflip_high_irq | |
| 55 | + | |
| 56 | +Atomic Implementation | |
| 57 | +--------------------- | |
| 58 | + | |
| 59 | +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | |
| 60 | + :doc: atomic | |
| 61 | + | |
| 62 | +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | |
| 63 | + :functions: amdgpu_dm_atomic_check amdgpu_dm_atomic_commit_tail | |
| 64 | + | |
| 65 | +Display Core | |
| 66 | +============ | |
| 67 | + | |
| 68 | +**WIP** | |
| @@ -5,6 +5,7 @@ GPU Driver Documentation · 4 unmodified lines | ||
| 5 | 5 | .. toctree:: |
| 6 | 6 | |
| 7 | 7 | amdgpu |
| 8 | + amdgpu-dc | |
| 8 | 9 | i915 |
| 9 | 10 | meson |
| 10 | 11 | pl111 |
| @@ -59,19 +59,28 @@ Implementing Asynchronous Atomic Commit · 58 unmodified lines | ||
| 59 | 59 | .. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c |
| 60 | 60 | :doc: implementing nonblocking commit |
| 61 | 61 | |
| 62 | +Helper Functions Reference | |
| 63 | +-------------------------- | |
| 64 | + | |
| 65 | +.. kernel-doc:: include/drm/drm_atomic_helper.h | |
| 66 | + :internal: | |
| 67 | + | |
| 68 | +.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c | |
| 69 | + :export: | |
| 70 | + | |
| 62 | 71 | Atomic State Reset and Initialization |
| 63 | 72 | ------------------------------------- |
| 64 | 73 | |
| 65 | −.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c | |
| 74 | +.. kernel-doc:: drivers/gpu/drm/drm_atomic_state_helper.c | |
| 66 | 75 | :doc: atomic state reset and initialization |
| 67 | 76 | |
| 68 | −Helper Functions Reference | |
| 69 | −-------------------------- | |
| 77 | +Atomic State Helper Reference | |
| 78 | +----------------------------- | |
| 70 | 79 | |
| 71 | −.. kernel-doc:: include/drm/drm_atomic_helper.h | |
| 80 | +.. kernel-doc:: include/drm/drm_atomic_state_helper.h | |
| 72 | 81 | :internal: |
| 73 | 82 | |
| 74 | −.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c | |
| 83 | +.. kernel-doc:: drivers/gpu/drm/drm_atomic_state_helper.c | |
| 75 | 84 | :export: |
| 76 | 85 | |
| 77 | 86 | Simple KMS Helper Reference |
| @@ -72,8 +72,8 @@ object TTM to provide a pool for buffer object allocation by clients and · 71 unmodified lines | ||
| 72 | 72 | the kernel itself. The type of this object should be |
| 73 | 73 | TTM_GLOBAL_TTM_BO, and its size should be sizeof(struct |
| 74 | 74 | ttm_bo_global). Again, driver-specific init and release functions may |
| 75 | −be provided, likely eventually calling ttm_bo_global_init() and | |
| 76 | −ttm_bo_global_release(), respectively. Also, like the previous | |
| 75 | +be provided, likely eventually calling ttm_bo_global_ref_init() and | |
| 76 | +ttm_bo_global_ref_release(), respectively. Also, like the previous | |
| 77 | 77 | object, ttm_global_item_ref() is used to create an initial reference |
| 78 | 78 | count for the TTM, which will call your initialization function. |
| 79 | 79 | |
| @@ -197,6 +197,9 @@ EPERM/EACCESS: · 196 unmodified lines | ||
| 197 | 197 | difference between EACCESS and EPERM. |
| 198 | 198 | |
| 199 | 199 | ENODEV: |
| 200 | + The device is not (yet) present or fully initialized. | |
| 201 | + | |
| 202 | +EOPNOTSUPP: | |
| 200 | 203 | Feature (like PRIME, modesetting, GEM) is not supported by the driver. |
| 201 | 204 | |
| 202 | 205 | ENXIO: |
| @@ -339,6 +339,16 @@ Some of these date from the very introduction of KMS in 2008 ... · 338 unmodified lines | ||
| 339 | 339 | leftovers from older (never merged into upstream) KMS designs where modes |
| 340 | 340 | where set using their ID, including support to add/remove modes. |
| 341 | 341 | |
| 342 | +- Make ->funcs and ->helper_private vtables optional. There's a bunch of empty | |
| 343 | + function tables in drivers, but before we can remove them we need to make sure | |
| 344 | + that all the users in helpers and drivers do correctly check for a NULL | |
| 345 | + vtable. | |
| 346 | + | |
| 347 | +- Cleanup up the various ->destroy callbacks. A lot of them just wrapt the | |
| 348 | + drm_*_cleanup implementations and can be removed. Some tack a kfree() at the | |
| 349 | + end, for which we could add drm_*_cleanup_kfree(). And then there's the (for | |
| 350 | + historical reasons) misnamed drm_primary_helper_destroy() function. | |
| 351 | + | |
| 342 | 352 | Better Testing |
| 343 | 353 | ============== |
| 344 | 354 | |
| @@ -10,8 +10,8 @@ · 9 unmodified lines | ||
| 10 | 10 | TODO |
| 11 | 11 | ==== |
| 12 | 12 | |
| 13 | −CRC API | |
| 14 | −------- | |
| 13 | +CRC API Improvements | |
| 14 | +-------------------- | |
| 15 | 15 | |
| 16 | 16 | - Optimize CRC computation ``compute_crc()`` and plane blending ``blend()`` |
| 17 | 17 | |
| @@ -22,3 +22,100 @@ CRC API · 4 unmodified lines | ||
| 22 | 22 | |
| 23 | 23 | - Add igt test to check extreme alpha values i.e. fully opaque and fully |
| 24 | 24 | transparent (intermediate values are affected by hw-specific rounding modes). |
| 25 | + | |
| 26 | +Vblank issues | |
| 27 | +------------- | |
| 28 | + | |
| 29 | +Some IGT test cases are failing. Need to analyze why and fix the issues: | |
| 30 | + | |
| 31 | +- plain-flip-fb-recreate | |
| 32 | +- plain-flip-ts-check | |
| 33 | +- flip-vs-blocking-wf-vblank | |
| 34 | +- plain-flip-fb-recreate-interruptible | |
| 35 | +- flip-vs-wf_vblank-interruptible | |
| 36 | + | |
| 37 | +Runtime Configuration | |
| 38 | +--------------------- | |
| 39 | + | |
| 40 | +We want to be able to reconfigure vkms instance without having to reload the | |
| 41 | +module. Use/Test-cases: | |
| 42 | + | |
| 43 | +- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling of | |
| 44 | + compositors). | |
| 45 | + | |
| 46 | +- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of | |
| 47 | + them first). | |
| 48 | + | |
| 49 | +- Change output configuration: Plug/unplug screens, change EDID, allow changing | |
| 50 | + the refresh rate. | |
| 51 | + | |
| 52 | +The currently proposed solution is to expose vkms configuration through | |
| 53 | +configfs. All existing module options should be supported through configfs too. | |
| 54 | + | |
| 55 | +Add Plane Features | |
| 56 | +------------------ | |
| 57 | + | |
| 58 | +There's lots of plane features we could add support for: | |
| 59 | + | |
| 60 | +- Real overlay planes, not just cursor. | |
| 61 | + | |
| 62 | +- Full alpha blending on all planes. | |
| 63 | + | |
| 64 | +- Rotation, scaling. | |
| 65 | + | |
| 66 | +- Additional buffer formats, especially YUV formats for video like NV12. | |
| 67 | + Low/high bpp RGB formats would also be interesting. | |
| 68 | + | |
| 69 | +- Async updates (currently only possible on cursor plane using the legacy cursor | |
| 70 | + api). | |
| 71 | + | |
| 72 | +For all of these, we also want to review the igt test coverage and make sure all | |
| 73 | +relevant igt testcases work on vkms. | |
| 74 | + | |
| 75 | +Writeback support | |
| 76 | +----------------- | |
| 77 | + | |
| 78 | +Currently vkms only computes a CRC for each frame. Once we have additional plane | |
| 79 | +features, we could write back the entire composited frame, and expose it as: | |
| 80 | + | |
| 81 | +- Writeback connector. This is useful for testing compositors if you don't have | |
| 82 | + hardware with writeback support. | |
| 83 | + | |
| 84 | +- As a v4l device. This is useful for debugging compositors on special vkms | |
| 85 | + configurations, so that developers see what's really going on. | |
| 86 | + | |
| 87 | +Prime Buffer Sharing | |
| 88 | +-------------------- | |
| 89 | + | |
| 90 | +We already have vgem, which is a gem driver for testing rendering, similar to | |
| 91 | +how vkms is for testing the modeset side. Adding buffer sharing support to vkms | |
| 92 | +allows us to test them together, to test synchronization and lots of other | |
| 93 | +features. Also, this allows compositors to test whether they work correctly on | |
| 94 | +SoC chips, where the display and rendering is very often split between 2 | |
| 95 | +drivers. | |
| 96 | + | |
| 97 | +Output Features | |
| 98 | +--------------- | |
| 99 | + | |
| 100 | +- Variable refresh rate/freesync support. This probably needs prime buffer | |
| 101 | + sharing support, so that we can use vgem fences to simulate rendering in | |
| 102 | + testing. Also needs support to specify the EDID. | |
| 103 | + | |
| 104 | +- Add support for link status, so that compositors can validate their runtime | |
| 105 | + fallbacks when e.g. a Display Port link goes bad. | |
| 106 | + | |
| 107 | +- All the hotplug handling describe under "Runtime Configuration". | |
| 108 | + | |
| 109 | +Atomic Check using eBPF | |
| 110 | +----------------------- | |
| 111 | + | |
| 112 | +Atomic drivers have lots of restrictions which are not exposed to userspace in | |
| 113 | +any explicit form through e.g. possible property values. Userspace can only | |
| 114 | +inquiry about these limits through the atomic IOCTL, possibly using the | |
| 115 | +TEST_ONLY flag. Trying to add configurable code for all these limits, to allow | |
| 116 | +compositors to be tested against them, would be rather futile exercise. Instead | |
| 117 | +we could add support for eBPF to validate any kind of atomic state, and | |
| 118 | +implement a library of different restrictions. | |
| 119 | + | |
| 120 | +This needs a bunch of features (plane compositing, multiple outputs, ...) | |
| 121 | +enabled already to make sense. | |
| @@ -21,6 +21,8 @@ and power are calculated host-side from these. · 20 unmodified lines | ||
| 21 | 21 | Sysfs entries |
| 22 | 22 | ------------- |
| 23 | 23 | |
| 24 | +in[123]_label Voltage channel labels | |
| 25 | +in[123]_enable Voltage channel enable controls | |
| 24 | 26 | in[123]_input Bus voltage(mV) channels |
| 25 | 27 | curr[123]_input Current(mA) measurement channels |
| 26 | 28 | shunt[123]_resistor Shunt resistance(uOhm) channels |
| @@ -17,8 +17,8 @@ Supported chips: · 16 unmodified lines | ||
| 17 | 17 | Addresses scanned: none |
| 18 | 18 | Datasheet: Publicly available at the Maxim website |
| 19 | 19 | http://www.maximintegrated.com/ |
| 20 | − * Maxim MAX6625, MAX6626 | |
| 21 | − Prefixes: 'max6625', 'max6626' | |
| 20 | + * Maxim MAX6625, MAX6626, MAX31725, MAX31726 | |
| 21 | + Prefixes: 'max6625', 'max6626', 'max31725', 'max31726' | |
| 22 | 22 | Addresses scanned: none |
| 23 | 23 | Datasheet: Publicly available at the Maxim website |
| 24 | 24 | http://www.maxim-ic.com/ |
| @@ -86,7 +86,7 @@ The LM75 is essentially an industry standard; there may be other · 61 unmodified lines | ||
| 86 | 86 | LM75 clones not listed here, with or without various enhancements, |
| 87 | 87 | that are supported. The clones are not detected by the driver, unless |
| 88 | 88 | they reproduce the exact register tricks of the original LM75, and must |
| 89 | −therefore be instantiated explicitly. Higher resolution up to 12-bit | |
| 89 | +therefore be instantiated explicitly. Higher resolution up to 16-bit | |
| 90 | 90 | is supported by this driver, other specific enhancements are not. |
| 91 | 91 | |
| 92 | 92 | The LM77 is not supported, contrary to what we pretended for a long time. |
| @@ -55,6 +55,10 @@ Supported chips: · 54 unmodified lines | ||
| 55 | 55 | Prefix: 'ltm4676' |
| 56 | 56 | Addresses scanned: - |
| 57 | 57 | Datasheet: http://www.linear.com/product/ltm4676 |
| 58 | + * Analog Devices LTM4686 | |
| 59 | + Prefix: 'ltm4686' | |
| 60 | + Addresses scanned: - | |
| 61 | + Datasheet: http://www.analog.com/ltm4686 | |
| 58 | 62 | |
| 59 | 63 | Author: Guenter Roeck <linux@roeck-us.net> |
| 60 | 64 | |
| @@ -76,6 +80,7 @@ additional components on a single die. The chip is instantiated and reported · 15 unmodified lines | ||
| 76 | 80 | as two separate chips on two different I2C bus addresses. |
| 77 | 81 | LTM4675 is a dual 9A or single 18A μModule regulator |
| 78 | 82 | LTM4676 is a dual 13A or single 26A uModule regulator. |
| 83 | +LTM4686 is a dual 10A or single 20A uModule regulator. | |
| 79 | 84 | |
| 80 | 85 | |
| 81 | 86 | Usage Notes |
| @@ -2,12 +2,12 @@ Kernel driver mc13783-adc · 1 unmodified line | ||
| 2 | 2 | ========================= |
| 3 | 3 | |
| 4 | 4 | Supported chips: |
| 5 | − * Freescale Atlas MC13783 | |
| 5 | + * Freescale MC13783 | |
| 6 | 6 | Prefix: 'mc13783' |
| 7 | − Datasheet: http://www.freescale.com/files/rf_if/doc/data_sheet/MC13783.pdf?fsrch=1 | |
| 8 | − * Freescale Atlas MC13892 | |
| 7 | + Datasheet: https://www.nxp.com/docs/en/data-sheet/MC13783.pdf | |
| 8 | + * Freescale MC13892 | |
| 9 | 9 | Prefix: 'mc13892' |
| 10 | − Datasheet: http://cache.freescale.com/files/analog/doc/data_sheet/MC13892.pdf?fsrch=1&sr=1 | |
| 10 | + Datasheet: https://www.nxp.com/docs/en/data-sheet/MC13892.pdf | |
| 11 | 11 | |
| 12 | 12 | Authors: |
| 13 | 13 | Sascha Hauer <s.hauer@pengutronix.de> |
| @@ -0,0 +1,18 @@ | ||
| 1 | +Kernel driver i2c-nvidia-gpu | |
| 2 | + | |
| 3 | +Datasheet: not publicly available. | |
| 4 | + | |
| 5 | +Authors: | |
| 6 | + Ajay Gupta <ajayg@nvidia.com> | |
| 7 | + | |
| 8 | +Description | |
| 9 | +----------- | |
| 10 | + | |
| 11 | +i2c-nvidia-gpu is a driver for I2C controller included in NVIDIA Turing | |
| 12 | +and later GPUs and it is used to communicate with Type-C controller on GPUs. | |
| 13 | + | |
| 14 | +If your 'lspci -v' listing shows something like the following, | |
| 15 | + | |
| 16 | +01:00.3 Serial bus controller [0c80]: NVIDIA Corporation Device 1ad9 (rev a1) | |
| 17 | + | |
| 18 | +then this driver should support the I2C controller of your GPU. | |
| @@ -1,14 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - this file | |
| 3 | −ChangeLog.ide-cd.1994-2004 | |
| 4 | − - ide-cd changelog | |
| 5 | −ChangeLog.ide-floppy.1996-2002 | |
| 6 | − - ide-floppy changelog | |
| 7 | −ChangeLog.ide-tape.1995-2002 | |
| 8 | − - ide-tape changelog | |
| 9 | −ide-tape.txt | |
| 10 | − - info on the IDE ATAPI streaming tape driver | |
| 11 | −ide.txt | |
| 12 | − - important info for users of ATA devices (IDE/EIDE disks and CD-ROMS). | |
| 13 | −warm-plug-howto.txt | |
| 14 | − - using sysfs to remove and add IDE devices. | |
| @@ -22,10 +22,7 @@ The following describes the license of the Linux kernel source code · 21 unmodified lines | ||
| 22 | 22 | (GPLv2), how to properly mark the license of individual files in the source |
| 23 | 23 | tree, as well as links to the full license text. |
| 24 | 24 | |
| 25 | −.. toctree:: | |
| 26 | − :maxdepth: 2 | |
| 27 | − | |
| 28 | − process/license-rules.rst | |
| 25 | +* :ref:`kernel_licensing` | |
| 29 | 26 | |
| 30 | 27 | User-oriented documentation |
| 31 | 28 | --------------------------- |
| @@ -190,7 +190,16 @@ A few EV_REL codes have special meanings: · 189 unmodified lines | ||
| 190 | 190 | * REL_WHEEL, REL_HWHEEL: |
| 191 | 191 | |
| 192 | 192 | - These codes are used for vertical and horizontal scroll wheels, |
| 193 | − respectively. | |
| 193 | + respectively. The value is the number of "notches" moved on the wheel, the | |
| 194 | + physical size of which varies by device. For high-resolution wheels (which | |
| 195 | + report multiple events for each notch of movement, or do not have notches) | |
| 196 | + this may be an approximation based on the high-resolution scroll events. | |
| 197 | + | |
| 198 | +* REL_WHEEL_HI_RES: | |
| 199 | + | |
| 200 | + - If a vertical scroll wheel supports high-resolution scrolling, this code | |
| 201 | + will be emitted in addition to REL_WHEEL. The value is the (approximate) | |
| 202 | + distance travelled by the user's finger, in microns. | |
| 194 | 203 | |
| 195 | 204 | EV_ABS |
| 196 | 205 | ------ |
| @@ -1,12 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - this file | |
| 3 | −botching-up-ioctls.txt | |
| 4 | − - how to avoid botching up ioctls | |
| 5 | −cdrom.txt | |
| 6 | − - summary of CDROM ioctl calls | |
| 7 | −hdio.txt | |
| 8 | − - summary of HDIO_ ioctl calls | |
| 9 | −ioctl-decoding.txt | |
| 10 | − - how to decode the bits of an IOCTL code | |
| 11 | −ioctl-number.txt | |
| 12 | − - how to implement and register device/driver ioctl calls | |
| @@ -201,7 +201,7 @@ Code Seq#(hex) Include File Comments · 200 unmodified lines | ||
| 201 | 201 | 'X' 01 linux/pktcdvd.h conflict! |
| 202 | 202 | 'Y' all linux/cyclades.h |
| 203 | 203 | 'Z' 14-15 drivers/message/fusion/mptctl.h |
| 204 | −'[' 00-07 linux/usb/tmc.h USB Test and Measurement Devices | |
| 204 | +'[' 00-3F linux/usb/tmc.h USB Test and Measurement Devices | |
| 205 | 205 | <mailto:gregkh@linuxfoundation.org> |
| 206 | 206 | 'a' all linux/atm*.h, linux/sonet.h ATM on linux |
| 207 | 207 | <http://lrcwww.epfl.ch/> |
| @@ -1,42 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - this file (info on ISDN implementation for Linux) | |
| 3 | −CREDITS | |
| 4 | − - list of the kind folks that brought you this stuff. | |
| 5 | −HiSax.cert | |
| 6 | − - information about the ITU approval certification of the HiSax driver. | |
| 7 | −INTERFACE | |
| 8 | − - description of isdn4linux Link Level and Hardware Level interfaces. | |
| 9 | −INTERFACE.fax | |
| 10 | − - description of the fax subinterface of isdn4linux. | |
| 11 | −INTERFACE.CAPI | |
| 12 | − - description of kernel CAPI Link Level to Hardware Level interface. | |
| 13 | −README | |
| 14 | − - general info on what you need and what to do for Linux ISDN. | |
| 15 | −README.FAQ | |
| 16 | − - general info for FAQ. | |
| 17 | −README.HiSax | |
| 18 | − - info on the HiSax driver which replaces the old teles. | |
| 19 | −README.audio | |
| 20 | − - info for running audio over ISDN. | |
| 21 | −README.avmb1 | |
| 22 | − - info on driver for AVM-B1 ISDN card. | |
| 23 | −README.concap | |
| 24 | − - info on "CONCAP" encapsulation protocol interface used for X.25. | |
| 25 | −README.diversion | |
| 26 | − - info on module for isdn diversion services. | |
| 27 | −README.fax | |
| 28 | − - info for using Fax over ISDN. | |
| 29 | −README.gigaset | |
| 30 | − - info on the drivers for Siemens Gigaset ISDN adapters | |
| 31 | −README.hfc-pci | |
| 32 | − - info on hfc-pci based cards. | |
| 33 | −README.hysdn | |
| 34 | − - info on driver for Hypercope active HYSDN cards | |
| 35 | −README.mISDN | |
| 36 | − - info on the Modular ISDN subsystem (mISDN) | |
| 37 | −README.syncppp | |
| 38 | − - info on running Sync PPP over ISDN. | |
| 39 | −README.x25 | |
| 40 | − - info for running X.25 over ISDN. | |
| 41 | −syncPPP.FAQ | |
| 42 | − - frequently asked questions about running PPP over ISDN. | |
| @@ -1,14 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - this file: info on the kernel build process | |
| 3 | −headers_install.txt | |
| 4 | − - how to export Linux headers for use by userspace | |
| 5 | −kbuild.txt | |
| 6 | − - developer information on kbuild | |
| 7 | −kconfig.txt | |
| 8 | − - usage help for make *config | |
| 9 | −kconfig-language.txt | |
| 10 | − - specification of Config Language, the language in Kconfig files | |
| 11 | −makefiles.txt | |
| 12 | − - developer information for linux kernel makefiles | |
| 13 | −modules.txt | |
| 14 | − - how to build modules and to install them | |
| @@ -537,21 +537,6 @@ more details, with real examples. · 536 unmodified lines | ||
| 537 | 537 | The third parameter may be a text as in this example, but it may also |
| 538 | 538 | be an expanded variable or a macro. |
| 539 | 539 | |
| 540 | − cc-fullversion | |
| 541 | − cc-fullversion is useful when the exact version of gcc is needed. | |
| 542 | − One typical use-case is when a specific GCC version is broken. | |
| 543 | − cc-fullversion points out a more specific version than cc-version does. | |
| 544 | − | |
| 545 | − Example: | |
| 546 | − #arch/powerpc/Makefile | |
| 547 | − $(Q)if test "$(cc-fullversion)" = "040200" ; then \ | |
| 548 | − echo -n '*** GCC-4.2.0 cannot compile the 64-bit powerpc ' ; \ | |
| 549 | − false ; \ | |
| 550 | − fi | |
| 551 | − | |
| 552 | − In this example for a specific GCC version the build will error out | |
| 553 | − explaining to the user why it stops. | |
| 554 | − | |
| 555 | 540 | cc-cross-prefix |
| 556 | 541 | cc-cross-prefix is used to check if there exists a $(CC) in path with |
| 557 | 542 | one of the listed prefixes. The first prefix where there exist a |
| @@ -321,7 +321,7 @@ To reduce its OS jitter, do at least one of the following: · 320 unmodified lines | ||
| 321 | 321 | to do. |
| 322 | 322 | |
| 323 | 323 | Name: |
| 324 | − rcuob/%d, rcuop/%d, and rcuos/%d | |
| 324 | + rcuop/%d and rcuos/%d | |
| 325 | 325 | |
| 326 | 326 | Purpose: |
| 327 | 327 | Offload RCU callbacks from the corresponding CPU. |
| @@ -1,16 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - This file | |
| 3 | −asus-laptop.txt | |
| 4 | − - information on the Asus Laptop Extras driver. | |
| 5 | −disk-shock-protection.txt | |
| 6 | − - information on hard disk shock protection. | |
| 7 | −laptop-mode.txt | |
| 8 | − - how to conserve battery power using laptop-mode. | |
| 9 | −sony-laptop.txt | |
| 10 | − - Sony Notebook Control Driver (SNC) Readme. | |
| 11 | −sonypi.txt | |
| 12 | − - info on Linux Sony Programmable I/O Device support. | |
| 13 | −thinkpad-acpi.txt | |
| 14 | − - information on the (IBM and Lenovo) ThinkPad ACPI Extras driver. | |
| 15 | −toshiba_haps.txt | |
| 16 | − - information on the Toshiba HDD Active Protection Sensor driver. | |
| @@ -0,0 +1,81 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0+ | |
| 2 | +LG Gram laptop extra features | |
| 3 | +============================= | |
| 4 | + | |
| 5 | +By Matan Ziv-Av <matan@svgalib.org> | |
| 6 | + | |
| 7 | + | |
| 8 | +Hotkeys | |
| 9 | +------- | |
| 10 | + | |
| 11 | +The following FN keys are ignored by the kernel without this driver: | |
| 12 | +- FN-F1 (LG control panel) - Generates F15 | |
| 13 | +- FN-F5 (Touchpad toggle) - Generates F13 | |
| 14 | +- FN-F6 (Airplane mode) - Generates RFKILL | |
| 15 | +- FN-F8 (Keyboard backlight) - Generates F16. | |
| 16 | + This key also changes keyboard backlight mode. | |
| 17 | +- FN-F9 (Reader mode) - Generates F14 | |
| 18 | + | |
| 19 | +The rest of the FN key work without a need for a special driver. | |
| 20 | + | |
| 21 | + | |
| 22 | +Reader mode | |
| 23 | +----------- | |
| 24 | + | |
| 25 | +Writing 0/1 to /sys/devices/platform/lg-laptop/reader_mode disables/enables | |
| 26 | +reader mode. In this mode the screen colors change (blue color reduced), | |
| 27 | +and the reader mode indicator LED (on F9 key) turns on. | |
| 28 | + | |
| 29 | + | |
| 30 | +FN Lock | |
| 31 | +------- | |
| 32 | + | |
| 33 | +Writing 0/1 to /sys/devices/platform/lg-laptop/fn_lock disables/enables | |
| 34 | +FN lock. | |
| 35 | + | |
| 36 | + | |
| 37 | +Battery care limit | |
| 38 | +------------------ | |
| 39 | + | |
| 40 | +Writing 80/100 to /sys/devices/platform/lg-laptop/battery_care_limit | |
| 41 | +sets the maximum capacity to charge the battery. Limiting the charge | |
| 42 | +reduces battery capacity loss over time. | |
| 43 | + | |
| 44 | +This value is reset to 100 when the kernel boots. | |
| 45 | + | |
| 46 | + | |
| 47 | +Fan mode | |
| 48 | +-------- | |
| 49 | + | |
| 50 | +Writing 1/0 to /sys/devices/platform/lg-laptop/fan_mode disables/enables | |
| 51 | +the fan silent mode. | |
| 52 | + | |
| 53 | + | |
| 54 | +USB charge | |
| 55 | +---------- | |
| 56 | + | |
| 57 | +Writing 0/1 to /sys/devices/platform/lg-laptop/usb_charge disables/enables | |
| 58 | +charging another device from the USB port while the device is turned off. | |
| 59 | + | |
| 60 | +This value is reset to 0 when the kernel boots. | |
| 61 | + | |
| 62 | + | |
| 63 | +LEDs | |
| 64 | +~~~~ | |
| 65 | + | |
| 66 | +The are two LED devices supported by the driver: | |
| 67 | + | |
| 68 | +Keyboard backlight | |
| 69 | +------------------ | |
| 70 | + | |
| 71 | +A led device named kbd_led controls the keyboard backlight. There are three | |
| 72 | +lighting level: off (0), low (127) and high (255). | |
| 73 | + | |
| 74 | +The keyboard backlight is also controlled by the key combination FN-F8 | |
| 75 | +which cycles through those levels. | |
| 76 | + | |
| 77 | + | |
| 78 | +Touchpad indicator LED | |
| 79 | +---------------------- | |
| 80 | + | |
| 81 | +On the F5 key. Controlled by led device names tpad_led. | |
| @@ -1,32 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - This file | |
| 3 | −leds-blinkm.txt | |
| 4 | − - Driver for BlinkM LED-devices. | |
| 5 | −leds-class.txt | |
| 6 | − - documents LED handling under Linux. | |
| 7 | −leds-class-flash.txt | |
| 8 | − - documents flash LED handling under Linux. | |
| 9 | −leds-lm3556.txt | |
| 10 | − - notes on how to use the leds-lm3556 driver. | |
| 11 | −leds-lp3944.txt | |
| 12 | − - notes on how to use the leds-lp3944 driver. | |
| 13 | −leds-lp5521.txt | |
| 14 | − - notes on how to use the leds-lp5521 driver. | |
| 15 | −leds-lp5523.txt | |
| 16 | − - notes on how to use the leds-lp5523 driver. | |
| 17 | −leds-lp5562.txt | |
| 18 | − - notes on how to use the leds-lp5562 driver. | |
| 19 | −leds-lp55xx.txt | |
| 20 | − - description about lp55xx common driver. | |
| 21 | −leds-lm3556.txt | |
| 22 | − - notes on how to use the leds-lm3556 driver. | |
| 23 | −leds-mlxcpld.txt | |
| 24 | − - notes on how to use the leds-mlxcpld driver. | |
| 25 | −ledtrig-oneshot.txt | |
| 26 | − - One-shot LED trigger for both sporadic and dense events. | |
| 27 | −ledtrig-transient.txt | |
| 28 | − - LED Transient Trigger, one shot timer activation. | |
| 29 | −ledtrig-usbport.txt | |
| 30 | − - notes on how to use the drivers/usb/core/ledtrig-usbport.c trigger. | |
| 31 | −uleds.txt | |
| 32 | − - notes on how to use the uleds driver. | |
| @@ -1,16 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - this file. | |
| 3 | −lockdep-design.txt | |
| 4 | − - documentation on the runtime locking correctness validator. | |
| 5 | −lockstat.txt | |
| 6 | − - info on collecting statistics on locks (and contention). | |
| 7 | −mutex-design.txt | |
| 8 | − - info on the generic mutex subsystem. | |
| 9 | −rt-mutex-design.txt | |
| 10 | − - description of the RealTime mutex implementation design. | |
| 11 | −rt-mutex.txt | |
| 12 | − - desc. of RT-mutex subsystem with PI (Priority Inheritance) support. | |
| 13 | −spinlocks.txt | |
| 14 | − - info on using spinlocks to provide exclusive access in kernel. | |
| 15 | −ww-mutex-design.txt | |
| 16 | − - Intro to Mutex wait/would deadlock handling.s | |
| @@ -91,7 +91,7 @@ Look at the current lock statistics: · 90 unmodified lines | ||
| 91 | 91 | 07 &mm->mmap_sem-R: 37 100 1.31 299502.61 325629.52 3256.30 212344 34316685 0.10 7744.91 95016910.20 2.77 |
| 92 | 92 | 08 --------------- |
| 93 | 93 | 09 &mm->mmap_sem 1 [<ffffffff811502a7>] khugepaged_scan_mm_slot+0x57/0x280 |
| 94 | −19 &mm->mmap_sem 96 [<ffffffff815351c4>] __do_page_fault+0x1d4/0x510 | |
| 94 | +10 &mm->mmap_sem 96 [<ffffffff815351c4>] __do_page_fault+0x1d4/0x510 | |
| 95 | 95 | 11 &mm->mmap_sem 34 [<ffffffff81113d77>] vm_mmap_pgoff+0x87/0xd0 |
| 96 | 96 | 12 &mm->mmap_sem 17 [<ffffffff81127e71>] vm_munmap+0x41/0x80 |
| 97 | 97 | 13 --------------- |
| @@ -1,7 +0,0 @@ | ||
| 1 | −00-INDEX | |
| 2 | − - this file | |
| 3 | −README.buddha | |
| 4 | − - Amiga Buddha and Catweasel IDE Driver | |
| 5 | −kernel-options.txt | |
| 6 | − - command line options for Linux/m68k | |
| 7 | − | |
| @@ -268,6 +268,10 @@ to 1, if the hardware does support retry then either set these counters to · 267 unmodified lines | ||
| 268 | 268 | 0 if the hardware provides no feedback of which errors occurred and how many |
| 269 | 269 | times, or fill in the correct values as reported by the hardware. |
| 270 | 270 | |
| 271 | +Be aware that calling these functions can immediately start a new transmit | |
| 272 | +if there is one pending in the queue. So make sure that the hardware is in | |
| 273 | +a state where new transmits can be started *before* calling these functions. | |
| 274 | + | |
| 271 | 275 | The cec_transmit_attempt_done() function is a helper for cases where the |
| 272 | 276 | hardware never retries, so the transmit is always for just a single |
| 273 | 277 | attempt. It will call cec_transmit_done() in turn, filling in 1 for the |
| @@ -262,3 +262,5 @@ in the end provide a way to use driver-specific callbacks. · 261 unmodified lines | ||
| 262 | 262 | .. kernel-doc:: include/media/media-devnode.h |
| 263 | 263 | |
| 264 | 264 | .. kernel-doc:: include/media/media-entity.h |
| 265 | + | |
| 266 | +.. kernel-doc:: include/media/media-request.h | |
| @@ -247,20 +247,28 @@ performed using the :c:func:`v4l2_async_unregister_subdev` call. Subdevices · 246 unmodified lines | ||
| 247 | 247 | registered this way are stored in a global list of subdevices, ready to be |
| 248 | 248 | picked up by bridge drivers. |
| 249 | 249 | |
| 250 | −Bridge drivers in turn have to register a notifier object with an array of | |
| 251 | −subdevice descriptors that the bridge device needs for its operation. This is | |
| 250 | +Bridge drivers in turn have to register a notifier object. This is | |
| 252 | 251 | performed using the :c:func:`v4l2_async_notifier_register` call. To |
| 253 | 252 | unregister the notifier the driver has to call |
| 254 | 253 | :c:func:`v4l2_async_notifier_unregister`. The former of the two functions |
| 255 | −takes two arguments: a pointer to struct :c:type:`v4l2_device` and a pointer to | |
| 256 | −struct :c:type:`v4l2_async_notifier`. The latter contains a pointer to an array | |
| 257 | −of pointers to subdevice descriptors of type struct :c:type:`v4l2_async_subdev` | |
| 258 | −type. The V4L2 core will then use these descriptors to match asynchronously | |
| 259 | −registered | |
| 260 | −subdevices to them. If a match is detected the ``.bound()`` notifier callback | |
| 261 | −is called. After all subdevices have been located the .complete() callback is | |
| 262 | −called. When a subdevice is removed from the system the .unbind() method is | |
| 263 | −called. All three callbacks are optional. | |
| 254 | +takes two arguments: a pointer to struct :c:type:`v4l2_device` and a | |
| 255 | +pointer to struct :c:type:`v4l2_async_notifier`. | |
| 256 | + | |
| 257 | +Before registering the notifier, bridge drivers must do two things: | |
| 258 | +first, the notifier must be initialized using the | |
| 259 | +:c:func:`v4l2_async_notifier_init`. Second, bridge drivers can then | |
| 260 | +begin to form a list of subdevice descriptors that the bridge device | |
| 261 | +needs for its operation. Subdevice descriptors are added to the notifier | |
| 262 | +using the :c:func:`v4l2_async_notifier_add_subdev` call. This function | |
| 263 | +takes two arguments: a pointer to struct :c:type:`v4l2_async_notifier`, | |
| 264 | +and a pointer to the subdevice descripter, which is of type struct | |
| 265 | +:c:type:`v4l2_async_subdev`. | |
| 266 | + | |
| 267 | +The V4L2 core will then use these descriptors to match asynchronously | |
| 268 | +registered subdevices to them. If a match is detected the ``.bound()`` | |
| 269 | +notifier callback is called. After all subdevices have been located the | |
| 270 | +.complete() callback is called. When a subdevice is removed from the | |
| 271 | +system the .unbind() method is called. All three callbacks are optional. | |
| 264 | 272 | |
| 265 | 273 | V4L2 sub-device userspace API |
| 266 | 274 | ----------------------------- |
| @@ -74,4 +74,5 @@ is returned, and the ``errno`` variable is set appropriately: · 73 unmodified lines | ||
| 74 | 74 | The call was interrupted by a signal. |
| 75 | 75 | |
| 76 | 76 | ``EINVAL`` |
| 77 | − The ``nfds`` argument is greater than ``OPEN_MAX``. | |
| 77 | + The ``nfds`` value exceeds the ``RLIMIT_NOFILE`` value. Use | |
| 78 | + ``getrlimit()`` to obtain this value. | |
| @@ -16,10 +16,10 @@ CEC_RECEIVE, CEC_TRANSMIT - Receive or transmit a CEC message · 15 unmodified lines | ||
| 16 | 16 | Synopsis |
| 17 | 17 | ======== |
| 18 | 18 | |
| 19 | −.. c:function:: int ioctl( int fd, CEC_RECEIVE, struct cec_msg *argp ) | |
| 19 | +.. c:function:: int ioctl( int fd, CEC_RECEIVE, struct cec_msg \*argp ) | |
| 20 | 20 | :name: CEC_RECEIVE |
| 21 | 21 | |
| 22 | −.. c:function:: int ioctl( int fd, CEC_TRANSMIT, struct cec_msg *argp ) | |
| 22 | +.. c:function:: int ioctl( int fd, CEC_TRANSMIT, struct cec_msg \*argp ) | |
| 23 | 23 | :name: CEC_TRANSMIT |
| 24 | 24 | |
| 25 | 25 | Arguments |
| @@ -272,6 +272,19 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV'). · 246 unmodified lines | ||
| 272 | 272 | - The transmit failed after one or more retries. This status bit is |
| 273 | 273 | mutually exclusive with :ref:`CEC_TX_STATUS_OK <CEC-TX-STATUS-OK>`. |
| 274 | 274 | Other bits can still be set to explain which failures were seen. |
| 275 | + * .. _`CEC-TX-STATUS-ABORTED`: | |
| 276 | + | |
| 277 | + - ``CEC_TX_STATUS_ABORTED`` | |
| 278 | + - 0x40 | |
| 279 | + - The transmit was aborted due to an HDMI disconnect, or the adapter | |
| 280 | + was unconfigured, or a transmit was interrupted, or the driver | |
| 281 | + returned an error when attempting to start a transmit. | |
| 282 | + * .. _`CEC-TX-STATUS-TIMEOUT`: | |
| 283 | + | |
| 284 | + - ``CEC_TX_STATUS_TIMEOUT`` | |
| 285 | + - 0x80 | |
| 286 | + - The transmit timed out. This should not normally happen and this | |
| 287 | + indicates a driver problem. | |
| 275 | 288 | |
| 276 | 289 | |
| 277 | 290 | .. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}| |
| @@ -300,6 +313,14 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV'). · 22 unmodified lines | ||
| 300 | 313 | - The message was received successfully but the reply was |
| 301 | 314 | ``CEC_MSG_FEATURE_ABORT``. This status is only set if this message |
| 302 | 315 | was the reply to an earlier transmitted message. |
| 316 | + * .. _`CEC-RX-STATUS-ABORTED`: | |
| 317 | + | |
| 318 | + - ``CEC_RX_STATUS_ABORTED`` | |
| 319 | + - 0x08 | |
| 320 | + - The wait for a reply to an earlier transmitted message was aborted | |
| 321 | + because the HDMI cable was disconnected, the adapter was unconfigured | |
| 322 | + or the :ref:`CEC_TRANSMIT <CEC_RECEIVE>` that waited for a | |
| 323 | + reply was interrupted. | |
| 303 | 324 | |
| 304 | 325 | |
| 305 | 326 | |
| @@ -21,6 +21,7 @@ Part IV - Media Controller API · 20 unmodified lines | ||
| 21 | 21 | media-controller-intro |
| 22 | 22 | media-controller-model |
| 23 | 23 | media-types |
| 24 | + request-api | |
| 24 | 25 | media-funcs |
| 25 | 26 | media-header |
| 26 | 27 | |
| @@ -16,3 +16,9 @@ Function Reference · 15 unmodified lines | ||
| 16 | 16 | media-ioc-enum-entities |
| 17 | 17 | media-ioc-enum-links |
| 18 | 18 | media-ioc-setup-link |
| 19 | + media-ioc-request-alloc | |
| 20 | + request-func-close | |
| 21 | + request-func-ioctl | |
| 22 | + request-func-poll | |
| 23 | + media-request-ioc-queue | |
| 24 | + media-request-ioc-reinit | |
| @@ -26,6 +26,7 @@ Arguments · 25 unmodified lines | ||
| 26 | 26 | File descriptor returned by :ref:`open() <media-func-open>`. |
| 27 | 27 | |
| 28 | 28 | ``argp`` |
| 29 | + Pointer to struct :c:type:`media_device_info`. | |
| 29 | 30 | |
| 30 | 31 | |
| 31 | 32 | Description |
| @@ -26,6 +26,7 @@ Arguments · 25 unmodified lines | ||
| 26 | 26 | File descriptor returned by :ref:`open() <media-func-open>`. |
| 27 | 27 | |
| 28 | 28 | ``argp`` |
| 29 | + Pointer to struct :c:type:`media_entity_desc`. | |
| 29 | 30 | |
| 30 | 31 | |
| 31 | 32 | Description |
| @@ -26,6 +26,7 @@ Arguments · 25 unmodified lines | ||
| 26 | 26 | File descriptor returned by :ref:`open() <media-func-open>`. |
| 27 | 27 | |
| 28 | 28 | ``argp`` |
| 29 | + Pointer to struct :c:type:`media_links_enum`. | |
| 29 | 30 | |
| 30 | 31 | |
| 31 | 32 | Description |
| @@ -26,6 +26,7 @@ Arguments · 25 unmodified lines | ||
| 26 | 26 | File descriptor returned by :ref:`open() <media-func-open>`. |
| 27 | 27 | |
| 28 | 28 | ``argp`` |
| 29 | + Pointer to struct :c:type:`media_v2_topology`. | |
| 29 | 30 | |
| 30 | 31 | |
| 31 | 32 | Description |
| @@ -0,0 +1,66 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later WITH no-invariant-sections | |
| 2 | + | |
| 3 | +.. _media_ioc_request_alloc: | |
| 4 | + | |
| 5 | +***************************** | |
| 6 | +ioctl MEDIA_IOC_REQUEST_ALLOC | |
| 7 | +***************************** | |
| 8 | + | |
| 9 | +Name | |
| 10 | +==== | |
| 11 | + | |
| 12 | +MEDIA_IOC_REQUEST_ALLOC - Allocate a request | |
| 13 | + | |
| 14 | + | |
| 15 | +Synopsis | |
| 16 | +======== | |
| 17 | + | |
| 18 | +.. c:function:: int ioctl( int fd, MEDIA_IOC_REQUEST_ALLOC, int *argp ) | |
| 19 | + :name: MEDIA_IOC_REQUEST_ALLOC | |
| 20 | + | |
| 21 | + | |
| 22 | +Arguments | |
| 23 | +========= | |
| 24 | + | |
| 25 | +``fd`` | |
| 26 | + File descriptor returned by :ref:`open() <media-func-open>`. | |
| 27 | + | |
| 28 | +``argp`` | |
| 29 | + Pointer to an integer. | |
| 30 | + | |
| 31 | + | |
| 32 | +Description | |
| 33 | +=========== | |
| 34 | + | |
| 35 | +If the media device supports :ref:`requests <media-request-api>`, then | |
| 36 | +this ioctl can be used to allocate a request. If it is not supported, then | |
| 37 | +``errno`` is set to ``ENOTTY``. A request is accessed through a file descriptor | |
| 38 | +that is returned in ``*argp``. | |
| 39 | + | |
| 40 | +If the request was successfully allocated, then the request file descriptor | |
| 41 | +can be passed to the :ref:`VIDIOC_QBUF <VIDIOC_QBUF>`, | |
| 42 | +:ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`, | |
| 43 | +:ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` and | |
| 44 | +:ref:`VIDIOC_TRY_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` ioctls. | |
| 45 | + | |
| 46 | +In addition, the request can be queued by calling | |
| 47 | +:ref:`MEDIA_REQUEST_IOC_QUEUE` and re-initialized by calling | |
| 48 | +:ref:`MEDIA_REQUEST_IOC_REINIT`. | |
| 49 | + | |
| 50 | +Finally, the file descriptor can be :ref:`polled <request-func-poll>` to wait | |
| 51 | +for the request to complete. | |
| 52 | + | |
| 53 | +The request will remain allocated until all the file descriptors associated | |
| 54 | +with it are closed by :ref:`close() <request-func-close>` and the driver no | |
| 55 | +longer uses the request internally. See also | |
| 56 | +:ref:`here <media-request-life-time>` for more information. | |
| 57 | + | |
| 58 | +Return Value | |
| 59 | +============ | |
| 60 | + | |
| 61 | +On success 0 is returned, on error -1 and the ``errno`` variable is set | |
| 62 | +appropriately. The generic error codes are described at the | |
| 63 | +:ref:`Generic Error Codes <gen-errors>` chapter. | |
| 64 | + | |
| 65 | +ENOTTY | |
| 66 | + The driver has no support for requests. | |
| @@ -26,6 +26,7 @@ Arguments · 25 unmodified lines | ||
| 26 | 26 | File descriptor returned by :ref:`open() <media-func-open>`. |
| 27 | 27 | |
| 28 | 28 | ``argp`` |
| 29 | + Pointer to struct :c:type:`media_link_desc`. | |
| 29 | 30 | |
| 30 | 31 | |
| 31 | 32 | Description |
| @@ -0,0 +1,78 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later WITH no-invariant-sections | |
| 2 | + | |
| 3 | +.. _media_request_ioc_queue: | |
| 4 | + | |
| 5 | +***************************** | |
| 6 | +ioctl MEDIA_REQUEST_IOC_QUEUE | |
| 7 | +***************************** | |
| 8 | + | |
| 9 | +Name | |
| 10 | +==== | |
| 11 | + | |
| 12 | +MEDIA_REQUEST_IOC_QUEUE - Queue a request | |
| 13 | + | |
| 14 | + | |
| 15 | +Synopsis | |
| 16 | +======== | |
| 17 | + | |
| 18 | +.. c:function:: int ioctl( int request_fd, MEDIA_REQUEST_IOC_QUEUE ) | |
| 19 | + :name: MEDIA_REQUEST_IOC_QUEUE | |
| 20 | + | |
| 21 | + | |
| 22 | +Arguments | |
| 23 | +========= | |
| 24 | + | |
| 25 | +``request_fd`` | |
| 26 | + File descriptor returned by :ref:`MEDIA_IOC_REQUEST_ALLOC`. | |
| 27 | + | |
| 28 | + | |
| 29 | +Description | |
| 30 | +=========== | |
| 31 | + | |
| 32 | +If the media device supports :ref:`requests <media-request-api>`, then | |
| 33 | +this request ioctl can be used to queue a previously allocated request. | |
| 34 | + | |
| 35 | +If the request was successfully queued, then the file descriptor can be | |
| 36 | +:ref:`polled <request-func-poll>` to wait for the request to complete. | |
| 37 | + | |
| 38 | +If the request was already queued before, then ``EBUSY`` is returned. | |
| 39 | +Other errors can be returned if the contents of the request contained | |
| 40 | +invalid or inconsistent data, see the next section for a list of | |
| 41 | +common error codes. On error both the request and driver state are unchanged. | |
| 42 | + | |
| 43 | +Once a request is queued, then the driver is required to gracefully handle | |
| 44 | +errors that occur when the request is applied to the hardware. The | |
| 45 | +exception is the ``EIO`` error which signals a fatal error that requires | |
| 46 | +the application to stop streaming to reset the hardware state. | |
| 47 | + | |
| 48 | +It is not allowed to mix queuing requests with queuing buffers directly | |
| 49 | +(without a request). ``EBUSY`` will be returned if the first buffer was | |
| 50 | +queued directly and you next try to queue a request, or vice versa. | |
| 51 | + | |
| 52 | +A request must contain at least one buffer, otherwise this ioctl will | |
| 53 | +return an ``ENOENT`` error. | |
| 54 | + | |
| 55 | +Return Value | |
| 56 | +============ | |
| 57 | + | |
| 58 | +On success 0 is returned, on error -1 and the ``errno`` variable is set | |
| 59 | +appropriately. The generic error codes are described at the | |
| 60 | +:ref:`Generic Error Codes <gen-errors>` chapter. | |
| 61 | + | |
| 62 | +EBUSY | |
| 63 | + The request was already queued or the application queued the first | |
| 64 | + buffer directly, but later attempted to use a request. It is not permitted | |
| 65 | + to mix the two APIs. | |
| 66 | +ENOENT | |
| 67 | + The request did not contain any buffers. All requests are required | |
| 68 | + to have at least one buffer. This can also be returned if some required | |
| 69 | + configuration is missing in the request. | |
| 70 | +ENOMEM | |
| 71 | + Out of memory when allocating internal data structures for this | |
| 72 | + request. | |
| 73 | +EINVAL | |
| 74 | + The request has invalid data. | |
| 75 | +EIO | |
| 76 | + The hardware is in a bad state. To recover, the application needs to | |
| 77 | + stop streaming to reset the hardware state and then try to restart | |
| 78 | + streaming. | |
| @@ -0,0 +1,51 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later WITH no-invariant-sections | |
| 2 | + | |
| 3 | +.. _media_request_ioc_reinit: | |
| 4 | + | |
| 5 | +****************************** | |
| 6 | +ioctl MEDIA_REQUEST_IOC_REINIT | |
| 7 | +****************************** | |
| 8 | + | |
| 9 | +Name | |
| 10 | +==== | |
| 11 | + | |
| 12 | +MEDIA_REQUEST_IOC_REINIT - Re-initialize a request | |
| 13 | + | |
| 14 | + | |
| 15 | +Synopsis | |
| 16 | +======== | |
| 17 | + | |
| 18 | +.. c:function:: int ioctl( int request_fd, MEDIA_REQUEST_IOC_REINIT ) | |
| 19 | + :name: MEDIA_REQUEST_IOC_REINIT | |
| 20 | + | |
| 21 | + | |
| 22 | +Arguments | |
| 23 | +========= | |
| 24 | + | |
| 25 | +``request_fd`` | |
| 26 | + File descriptor returned by :ref:`MEDIA_IOC_REQUEST_ALLOC`. | |
| 27 | + | |
| 28 | +Description | |
| 29 | +=========== | |
| 30 | + | |
| 31 | +If the media device supports :ref:`requests <media-request-api>`, then | |
| 32 | +this request ioctl can be used to re-initialize a previously allocated | |
| 33 | +request. | |
| 34 | + | |
| 35 | +Re-initializing a request will clear any existing data from the request. | |
| 36 | +This avoids having to :ref:`close() <request-func-close>` a completed | |
| 37 | +request and allocate a new request. Instead the completed request can just | |
| 38 | +be re-initialized and it is ready to be used again. | |
| 39 | + | |
| 40 | +A request can only be re-initialized if it either has not been queued | |
| 41 | +yet, or if it was queued and completed. Otherwise it will set ``errno`` | |
| 42 | +to ``EBUSY``. No other error codes can be returned. | |
| 43 | + | |
| 44 | +Return Value | |
| 45 | +============ | |
| 46 | + | |
| 47 | +On success 0 is returned, on error -1 and the ``errno`` variable is set | |
| 48 | +appropriately. | |
| 49 | + | |
| 50 | +EBUSY | |
| 51 | + The request is queued but not yet completed. | |
| @@ -0,0 +1,252 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later WITH no-invariant-sections | |
| 2 | + | |
| 3 | +.. _media-request-api: | |
| 4 | + | |
| 5 | +Request API | |
| 6 | +=========== | |
| 7 | + | |
| 8 | +The Request API has been designed to allow V4L2 to deal with requirements of | |
| 9 | +modern devices (stateless codecs, complex camera pipelines, ...) and APIs | |
| 10 | +(Android Codec v2). One such requirement is the ability for devices belonging to | |
| 11 | +the same pipeline to reconfigure and collaborate closely on a per-frame basis. | |
| 12 | +Another is support of stateless codecs, which require controls to be applied | |
| 13 | +to specific frames (aka 'per-frame controls') in order to be used efficiently. | |
| 14 | + | |
| 15 | +While the initial use-case was V4L2, it can be extended to other subsystems | |
| 16 | +as well, as long as they use the media controller. | |
| 17 | + | |
| 18 | +Supporting these features without the Request API is not always possible and if | |
| 19 | +it is, it is terribly inefficient: user-space would have to flush all activity | |
| 20 | +on the media pipeline, reconfigure it for the next frame, queue the buffers to | |
| 21 | +be processed with that configuration, and wait until they are all available for | |
| 22 | +dequeuing before considering the next frame. This defeats the purpose of having | |
| 23 | +buffer queues since in practice only one buffer would be queued at a time. | |
| 24 | + | |
| 25 | +The Request API allows a specific configuration of the pipeline (media | |
| 26 | +controller topology + configuration for each media entity) to be associated with | |
| 27 | +specific buffers. This allows user-space to schedule several tasks ("requests") | |
| 28 | +with different configurations in advance, knowing that the configuration will be | |
| 29 | +applied when needed to get the expected result. Configuration values at the time | |
| 30 | +of request completion are also available for reading. | |
| 31 | + | |
| 32 | +Usage | |
| 33 | +===== | |
| 34 | + | |
| 35 | +The Request API extends the Media Controller API and cooperates with | |
| 36 | +subsystem-specific APIs to support request usage. At the Media Controller | |
| 37 | +level, requests are allocated from the supporting Media Controller device | |
| 38 | +node. Their life cycle is then managed through the request file descriptors in | |
| 39 | +an opaque way. Configuration data, buffer handles and processing results | |
| 40 | +stored in requests are accessed through subsystem-specific APIs extended for | |
| 41 | +request support, such as V4L2 APIs that take an explicit ``request_fd`` | |
| 42 | +parameter. | |
| 43 | + | |
| 44 | +Request Allocation | |
| 45 | +------------------ | |
| 46 | + | |
| 47 | +User-space allocates requests using :ref:`MEDIA_IOC_REQUEST_ALLOC` | |
| 48 | +for the media device node. This returns a file descriptor representing the | |
| 49 | +request. Typically, several such requests will be allocated. | |
| 50 | + | |
| 51 | +Request Preparation | |
| 52 | +------------------- | |
| 53 | + | |
| 54 | +Standard V4L2 ioctls can then receive a request file descriptor to express the | |
| 55 | +fact that the ioctl is part of said request, and is not to be applied | |
| 56 | +immediately. See :ref:`MEDIA_IOC_REQUEST_ALLOC` for a list of ioctls that | |
| 57 | +support this. Configurations set with a ``request_fd`` parameter are stored | |
| 58 | +instead of being immediately applied, and buffers queued to a request do not | |
| 59 | +enter the regular buffer queue until the request itself is queued. | |
| 60 | + | |
| 61 | +Request Submission | |
| 62 | +------------------ | |
| 63 | + | |
| 64 | +Once the configuration and buffers of the request are specified, it can be | |
| 65 | +queued by calling :ref:`MEDIA_REQUEST_IOC_QUEUE` on the request file descriptor. | |
| 66 | +A request must contain at least one buffer, otherwise ``ENOENT`` is returned. | |
| 67 | +A queued request cannot be modified anymore. | |
| 68 | + | |
| 69 | +.. caution:: | |
| 70 | + For :ref:`memory-to-memory devices <codec>` you can use requests only for | |
| 71 | + output buffers, not for capture buffers. Attempting to add a capture buffer | |
| 72 | + to a request will result in an ``EACCES`` error. | |
| 73 | + | |
| 74 | +If the request contains configurations for multiple entities, individual drivers | |
| 75 | +may synchronize so the requested pipeline's topology is applied before the | |
| 76 | +buffers are processed. Media controller drivers do a best effort implementation | |
| 77 | +since perfect atomicity may not be possible due to hardware limitations. | |
| 78 | + | |
| 79 | +.. caution:: | |
| 80 | + | |
| 81 | + It is not allowed to mix queuing requests with directly queuing buffers: | |
| 82 | + whichever method is used first locks this in place until | |
| 83 | + :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` is called or the device is | |
| 84 | + :ref:`closed <func-close>`. Attempts to directly queue a buffer when earlier | |
| 85 | + a buffer was queued via a request or vice versa will result in an ``EBUSY`` | |
| 86 | + error. | |
| 87 | + | |
| 88 | +Controls can still be set without a request and are applied immediately, | |
| 89 | +regardless of whether a request is in use or not. | |
| 90 | + | |
| 91 | +.. caution:: | |
| 92 | + | |
| 93 | + Setting the same control through a request and also directly can lead to | |
| 94 | + undefined behavior! | |
| 95 | + | |
| 96 | +User-space can :ref:`poll() <request-func-poll>` a request file descriptor in | |
| 97 | +order to wait until the request completes. A request is considered complete | |
| 98 | +once all its associated buffers are available for dequeuing and all the | |
| 99 | +associated controls have been updated with the values at the time of completion. | |
| 100 | +Note that user-space does not need to wait for the request to complete to | |
| 101 | +dequeue its buffers: buffers that are available halfway through a request can | |
| 102 | +be dequeued independently of the request's state. | |
| 103 | + | |
| 104 | +A completed request contains the state of the device after the request was | |
| 105 | +executed. User-space can query that state by calling | |
| 106 | +:ref:`ioctl VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` with the request file | |
| 107 | +descriptor. Calling :ref:`ioctl VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` for a | |
| 108 | +request that has been queued but not yet completed will return ``EBUSY`` | |
| 109 | +since the control values might be changed at any time by the driver while the | |
| 110 | +request is in flight. | |
| 111 | + | |
| 112 | +.. _media-request-life-time: | |
| 113 | + | |
| 114 | +Recycling and Destruction | |
| 115 | +------------------------- | |
| 116 | + | |
| 117 | +Finally, a completed request can either be discarded or be reused. Calling | |
| 118 | +:ref:`close() <request-func-close>` on a request file descriptor will make | |
| 119 | +that file descriptor unusable and the request will be freed once it is no | |
| 120 | +longer in use by the kernel. That is, if the request is queued and then the | |
| 121 | +file descriptor is closed, then it won't be freed until the driver completed | |
| 122 | +the request. | |
| 123 | + | |
| 124 | +The :ref:`MEDIA_REQUEST_IOC_REINIT` will clear a request's state and make it | |
| 125 | +available again. No state is retained by this operation: the request is as | |
| 126 | +if it had just been allocated. | |
| 127 | + | |
| 128 | +Example for a Codec Device | |
| 129 | +-------------------------- | |
| 130 | + | |
| 131 | +For use-cases such as :ref:`codecs <codec>`, the request API can be used | |
| 132 | +to associate specific controls to | |
| 133 | +be applied by the driver for the OUTPUT buffer, allowing user-space | |
| 134 | +to queue many such buffers in advance. It can also take advantage of requests' | |
| 135 | +ability to capture the state of controls when the request completes to read back | |
| 136 | +information that may be subject to change. | |
| 137 | + | |
| 138 | +Put into code, after obtaining a request, user-space can assign controls and one | |
| 139 | +OUTPUT buffer to it: | |
| 140 | + | |
| 141 | +.. code-block:: c | |
| 142 | + | |
| 143 | + struct v4l2_buffer buf; | |
| 144 | + struct v4l2_ext_controls ctrls; | |
| 145 | + int req_fd; | |
| 146 | + ... | |
| 147 | + if (ioctl(media_fd, MEDIA_IOC_REQUEST_ALLOC, &req_fd)) | |
| 148 | + return errno; | |
| 149 | + ... | |
| 150 | + ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL; | |
| 151 | + ctrls.request_fd = req_fd; | |
| 152 | + if (ioctl(codec_fd, VIDIOC_S_EXT_CTRLS, &ctrls)) | |
| 153 | + return errno; | |
| 154 | + ... | |
| 155 | + buf.type = V4L2_BUF_TYPE_VIDEO_OUTPUT; | |
| 156 | + buf.flags |= V4L2_BUF_FLAG_REQUEST_FD; | |
| 157 | + buf.request_fd = req_fd; | |
| 158 | + if (ioctl(codec_fd, VIDIOC_QBUF, &buf)) | |
| 159 | + return errno; | |
| 160 | + | |
| 161 | +Note that it is not allowed to use the Request API for CAPTURE buffers | |
| 162 | +since there are no per-frame settings to report there. | |
| 163 | + | |
| 164 | +Once the request is fully prepared, it can be queued to the driver: | |
| 165 | + | |
| 166 | +.. code-block:: c | |
| 167 | + | |
| 168 | + if (ioctl(req_fd, MEDIA_REQUEST_IOC_QUEUE)) | |
| 169 | + return errno; | |
| 170 | + | |
| 171 | +User-space can then either wait for the request to complete by calling poll() on | |
| 172 | +its file descriptor, or start dequeuing CAPTURE buffers. Most likely, it will | |
| 173 | +want to get CAPTURE buffers as soon as possible and this can be done using a | |
| 174 | +regular :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>`: | |
| 175 | + | |
| 176 | +.. code-block:: c | |
| 177 | + | |
| 178 | + struct v4l2_buffer buf; | |
| 179 | + | |
| 180 | + memset(&buf, 0, sizeof(buf)); | |
| 181 | + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; | |
| 182 | + if (ioctl(codec_fd, VIDIOC_DQBUF, &buf)) | |
| 183 | + return errno; | |
| 184 | + | |
| 185 | +Note that this example assumes for simplicity that for every OUTPUT buffer | |
| 186 | +there will be one CAPTURE buffer, but this does not have to be the case. | |
| 187 | + | |
| 188 | +We can then, after ensuring that the request is completed via polling the | |
| 189 | +request file descriptor, query control values at the time of its completion via | |
| 190 | +a call to :ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`. | |
| 191 | +This is particularly useful for volatile controls for which we want to | |
| 192 | +query values as soon as the capture buffer is produced. | |
| 193 | + | |
| 194 | +.. code-block:: c | |
| 195 | + | |
| 196 | + struct pollfd pfd = { .events = POLLPRI, .fd = req_fd }; | |
| 197 | + poll(&pfd, 1, -1); | |
| 198 | + ... | |
| 199 | + ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL; | |
| 200 | + ctrls.request_fd = req_fd; | |
| 201 | + if (ioctl(codec_fd, VIDIOC_G_EXT_CTRLS, &ctrls)) | |
| 202 | + return errno; | |
| 203 | + | |
| 204 | +Once we don't need the request anymore, we can either recycle it for reuse with | |
| 205 | +:ref:`MEDIA_REQUEST_IOC_REINIT`... | |
| 206 | + | |
| 207 | +.. code-block:: c | |
| 208 | + | |
| 209 | + if (ioctl(req_fd, MEDIA_REQUEST_IOC_REINIT)) | |
| 210 | + return errno; | |
| 211 | + | |
| 212 | +... or close its file descriptor to completely dispose of it. | |
| 213 | + | |
| 214 | +.. code-block:: c | |
| 215 | + | |
| 216 | + close(req_fd); | |
| 217 | + | |
| 218 | +Example for a Simple Capture Device | |
| 219 | +----------------------------------- | |
| 220 | + | |
| 221 | +With a simple capture device, requests can be used to specify controls to apply | |
| 222 | +for a given CAPTURE buffer. | |
| 223 | + | |
| 224 | +.. code-block:: c | |
| 225 | + | |
| 226 | + struct v4l2_buffer buf; | |
| 227 | + struct v4l2_ext_controls ctrls; | |
| 228 | + int req_fd; | |
| 229 | + ... | |
| 230 | + if (ioctl(media_fd, MEDIA_IOC_REQUEST_ALLOC, &req_fd)) | |
| 231 | + return errno; | |
| 232 | + ... | |
| 233 | + ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL; | |
| 234 | + ctrls.request_fd = req_fd; | |
| 235 | + if (ioctl(camera_fd, VIDIOC_S_EXT_CTRLS, &ctrls)) | |
| 236 | + return errno; | |
| 237 | + ... | |
| 238 | + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; | |
| 239 | + buf.flags |= V4L2_BUF_FLAG_REQUEST_FD; | |
| 240 | + buf.request_fd = req_fd; | |
| 241 | + if (ioctl(camera_fd, VIDIOC_QBUF, &buf)) | |
| 242 | + return errno; | |
| 243 | + | |
| 244 | +Once the request is fully prepared, it can be queued to the driver: | |
| 245 | + | |
| 246 | +.. code-block:: c | |
| 247 | + | |
| 248 | + if (ioctl(req_fd, MEDIA_REQUEST_IOC_QUEUE)) | |
| 249 | + return errno; | |
| 250 | + | |
| 251 | +User-space can then dequeue buffers, wait for the request completion, query | |
| 252 | +controls and recycle the request as in the M2M example above. | |
| @@ -0,0 +1,49 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later WITH no-invariant-sections | |
| 2 | + | |
| 3 | +.. _request-func-close: | |
| 4 | + | |
| 5 | +*************** | |
| 6 | +request close() | |
| 7 | +*************** | |
| 8 | + | |
| 9 | +Name | |
| 10 | +==== | |
| 11 | + | |
| 12 | +request-close - Close a request file descriptor | |
| 13 | + | |
| 14 | + | |
| 15 | +Synopsis | |
| 16 | +======== | |
| 17 | + | |
| 18 | +.. code-block:: c | |
| 19 | + | |
| 20 | + #include <unistd.h> | |
| 21 | + | |
| 22 | + | |
| 23 | +.. c:function:: int close( int fd ) | |
| 24 | + :name: req-close | |
| 25 | + | |
| 26 | +Arguments | |
| 27 | +========= | |
| 28 | + | |
| 29 | +``fd`` | |
| 30 | + File descriptor returned by :ref:`MEDIA_IOC_REQUEST_ALLOC`. | |
| 31 | + | |
| 32 | + | |
| 33 | +Description | |
| 34 | +=========== | |
| 35 | + | |
| 36 | +Closes the request file descriptor. Resources associated with the request | |
| 37 | +are freed once all file descriptors associated with the request are closed | |
| 38 | +and the driver has completed the request. | |
| 39 | +See :ref:`here <media-request-life-time>` for more information. | |
| 40 | + | |
| 41 | + | |
| 42 | +Return Value | |
| 43 | +============ | |
| 44 | + | |
| 45 | +:ref:`close() <request-func-close>` returns 0 on success. On error, -1 is | |
| 46 | +returned, and ``errno`` is set appropriately. Possible error codes are: | |
| 47 | + | |
| 48 | +EBADF | |
| 49 | + ``fd`` is not a valid open file descriptor. | |
| @@ -0,0 +1,67 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later WITH no-invariant-sections | |
| 2 | + | |
| 3 | +.. _request-func-ioctl: | |
| 4 | + | |
| 5 | +*************** | |
| 6 | +request ioctl() | |
| 7 | +*************** | |
| 8 | + | |
| 9 | +Name | |
| 10 | +==== | |
| 11 | + | |
| 12 | +request-ioctl - Control a request file descriptor | |
| 13 | + | |
| 14 | + | |
| 15 | +Synopsis | |
| 16 | +======== | |
| 17 | + | |
| 18 | +.. code-block:: c | |
| 19 | + | |
| 20 | + #include <sys/ioctl.h> | |
| 21 | + | |
| 22 | + | |
| 23 | +.. c:function:: int ioctl( int fd, int cmd, void *argp ) | |
| 24 | + :name: req-ioctl | |
| 25 | + | |
| 26 | +Arguments | |
| 27 | +========= | |
| 28 | + | |
| 29 | +``fd`` | |
| 30 | + File descriptor returned by :ref:`MEDIA_IOC_REQUEST_ALLOC`. | |
| 31 | + | |
| 32 | +``cmd`` | |
| 33 | + The request ioctl command code as defined in the media.h header file, for | |
| 34 | + example :ref:`MEDIA_REQUEST_IOC_QUEUE`. | |
| 35 | + | |
| 36 | +``argp`` | |
| 37 | + Pointer to a request-specific structure. | |
| 38 | + | |
| 39 | + | |
| 40 | +Description | |
| 41 | +=========== | |
| 42 | + | |
| 43 | +The :ref:`ioctl() <request-func-ioctl>` function manipulates request | |
| 44 | +parameters. The argument ``fd`` must be an open file descriptor. | |
| 45 | + | |
| 46 | +The ioctl ``cmd`` code specifies the request function to be called. It | |
| 47 | +has encoded in it whether the argument is an input, output or read/write | |
| 48 | +parameter, and the size of the argument ``argp`` in bytes. | |
| 49 | + | |
| 50 | +Macros and structures definitions specifying request ioctl commands and | |
| 51 | +their parameters are located in the media.h header file. All request ioctl | |
| 52 | +commands, their respective function and parameters are specified in | |
| 53 | +:ref:`media-user-func`. | |
| 54 | + | |
| 55 | + | |
| 56 | +Return Value | |
| 57 | +============ | |
| 58 | + | |
| 59 | +On success 0 is returned, on error -1 and the ``errno`` variable is set | |
| 60 | +appropriately. The generic error codes are described at the | |
| 61 | +:ref:`Generic Error Codes <gen-errors>` chapter. | |
| 62 | + | |
| 63 | +Command-specific error codes are listed in the individual command | |
| 64 | +descriptions. | |
| 65 | + | |
| 66 | +When an ioctl that takes an output or read/write parameter fails, the | |
| 67 | +parameter remains unmodified. | |
| @@ -0,0 +1,77 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later WITH no-invariant-sections | |
| 2 | + | |
| 3 | +.. _request-func-poll: | |
| 4 | + | |
| 5 | +************** | |
| 6 | +request poll() | |
| 7 | +************** | |
| 8 | + | |
| 9 | +Name | |
| 10 | +==== | |
| 11 | + | |
| 12 | +request-poll - Wait for some event on a file descriptor | |
| 13 | + | |
| 14 | + | |
| 15 | +Synopsis | |
| 16 | +======== | |
| 17 | + | |
| 18 | +.. code-block:: c | |
| 19 | + | |
| 20 | + #include <sys/poll.h> | |
| 21 | + | |
| 22 | + | |
| 23 | +.. c:function:: int poll( struct pollfd *ufds, unsigned int nfds, int timeout ) | |
| 24 | + :name: request-poll | |
| 25 | + | |
| 26 | +Arguments | |
| 27 | +========= | |
| 28 | + | |
| 29 | +``ufds`` | |
| 30 | + List of file descriptor events to be watched | |
| 31 | + | |
| 32 | +``nfds`` | |
| 33 | + Number of file descriptor events at the \*ufds array | |
| 34 | + | |
| 35 | +``timeout`` | |
| 36 | + Timeout to wait for events | |
| 37 | + | |
| 38 | + | |
| 39 | +Description | |
| 40 | +=========== | |
| 41 | + | |
| 42 | +With the :c:func:`poll() <request-func-poll>` function applications can wait | |
| 43 | +for a request to complete. | |
| 44 | + | |
| 45 | +On success :c:func:`poll() <request-func-poll>` returns the number of file | |
| 46 | +descriptors that have been selected (that is, file descriptors for which the | |
| 47 | +``revents`` field of the respective struct :c:type:`pollfd` | |
| 48 | +is non-zero). Request file descriptor set the ``POLLPRI`` flag in ``revents`` | |
| 49 | +when the request was completed. When the function times out it returns | |
| 50 | +a value of zero, on failure it returns -1 and the ``errno`` variable is | |
| 51 | +set appropriately. | |
| 52 | + | |
| 53 | +Attempting to poll for a request that is not yet queued will | |
| 54 | +set the ``POLLERR`` flag in ``revents``. | |
| 55 | + | |
| 56 | + | |
| 57 | +Return Value | |
| 58 | +============ | |
| 59 | + | |
| 60 | +On success, :c:func:`poll() <request-func-poll>` returns the number of | |
| 61 | +structures which have non-zero ``revents`` fields, or zero if the call | |
| 62 | +timed out. On error -1 is returned, and the ``errno`` variable is set | |
| 63 | +appropriately: | |
| 64 | + | |
| 65 | +``EBADF`` | |
| 66 | + One or more of the ``ufds`` members specify an invalid file | |
| 67 | + descriptor. | |
| 68 | + | |
| 69 | +``EFAULT`` | |
| 70 | + ``ufds`` references an inaccessible memory area. | |
| 71 | + | |
| 72 | +``EINTR`` | |
| 73 | + The call was interrupted by a signal. | |
| 74 | + | |
| 75 | +``EINVAL`` | |
| 76 | + The ``nfds`` value exceeds the ``RLIMIT_NOFILE`` value. Use | |
| 77 | + ``getrlimit()`` to obtain this value. | |
| @@ -226,16 +226,6 @@ xvYCC · 225 unmodified lines | ||
| 226 | 226 | |
| 227 | 227 | :author: International Electrotechnical Commission (http://www.iec.ch) |
| 228 | 228 | |
| 229 | −.. _adobergb: | |
| 230 | − | |
| 231 | −AdobeRGB | |
| 232 | −======== | |
| 233 | − | |
| 234 | − | |
| 235 | −:title: Adobe© RGB (1998) Color Image Encoding Version 2005-05 | |
| 236 | − | |
| 237 | −:author: Adobe Systems Incorporated (http://www.adobe.com) | |
| 238 | − | |
| 239 | 229 | .. _oprgb: |
| 240 | 230 | |
| 241 | 231 | opRGB |
| @@ -306,10 +306,23 @@ struct v4l2_buffer · 305 unmodified lines | ||
| 306 | 306 | - A place holder for future extensions. Drivers and applications |
| 307 | 307 | must set this to 0. |
| 308 | 308 | * - __u32 |
| 309 | − - ``reserved`` | |
| 309 | + - ``request_fd`` | |
| 310 | 310 | - |
| 311 | − - A place holder for future extensions. Drivers and applications | |
| 312 | − must set this to 0. | |
| 311 | + - The file descriptor of the request to queue the buffer to. If the flag | |
| 312 | + ``V4L2_BUF_FLAG_REQUEST_FD`` is set, then the buffer will be | |
| 313 | + queued to this request. If the flag is not set, then this field will | |
| 314 | + be ignored. | |
| 315 | + | |
| 316 | + The ``V4L2_BUF_FLAG_REQUEST_FD`` flag and this field are only used by | |
| 317 | + :ref:`ioctl VIDIOC_QBUF <VIDIOC_QBUF>` and ignored by other ioctls that | |
| 318 | + take a :c:type:`v4l2_buffer` as argument. | |
| 319 | + | |
| 320 | + Applications should not set ``V4L2_BUF_FLAG_REQUEST_FD`` for any ioctls | |
| 321 | + other than :ref:`VIDIOC_QBUF <VIDIOC_QBUF>`. | |
| 322 | + | |
| 323 | + If the device does not support requests, then ``EACCES`` will be returned. | |
| 324 | + If requests are supported but an invalid request file descriptor is | |
| 325 | + given, then ``EINVAL`` will be returned. | |
| 313 | 326 | |
| 314 | 327 | |
| 315 | 328 | |
| @@ -514,6 +527,11 @@ Buffer Flags · 198 unmodified lines | ||
| 514 | 527 | streaming may continue as normal and the buffer may be reused |
| 515 | 528 | normally. Drivers set this flag when the ``VIDIOC_DQBUF`` ioctl is |
| 516 | 529 | called. |
| 530 | + * .. _`V4L2-BUF-FLAG-IN-REQUEST`: | |
| 531 | + | |
| 532 | + - ``V4L2_BUF_FLAG_IN_REQUEST`` | |
| 533 | + - 0x00000080 | |
| 534 | + - This buffer is part of a request that hasn't been queued yet. | |
| 517 | 535 | * .. _`V4L2-BUF-FLAG-KEYFRAME`: |
| 518 | 536 | |
| 519 | 537 | - ``V4L2_BUF_FLAG_KEYFRAME`` |
| @@ -589,6 +607,11 @@ Buffer Flags · 69 unmodified lines | ||
| 589 | 607 | the format. Any Any subsequent call to the |
| 590 | 608 | :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl will not block anymore, |
| 591 | 609 | but return an ``EPIPE`` error code. |
| 610 | + * .. _`V4L2-BUF-FLAG-REQUEST-FD`: | |
| 611 | + | |
| 612 | + - ``V4L2_BUF_FLAG_REQUEST_FD`` | |
| 613 | + - 0x00800000 | |
| 614 | + - The ``request_fd`` field contains a valid file descriptor. | |
| 592 | 615 | * .. _`V4L2-BUF-FLAG-TIMESTAMP-MASK`: |
| 593 | 616 | |
| 594 | 617 | - ``V4L2_BUF_FLAG_TIMESTAMP_MASK`` |
| @@ -51,8 +51,8 @@ whole range, 0-255, dividing the angular value by 1.41. The enum · 50 unmodified lines | ||
| 51 | 51 | - See :ref:`col-rec709`. |
| 52 | 52 | * - ``V4L2_COLORSPACE_SRGB`` |
| 53 | 53 | - See :ref:`col-srgb`. |
| 54 | − * - ``V4L2_COLORSPACE_ADOBERGB`` | |
| 55 | − - See :ref:`col-adobergb`. | |
| 54 | + * - ``V4L2_COLORSPACE_OPRGB`` | |
| 55 | + - See :ref:`col-oprgb`. | |
| 56 | 56 | * - ``V4L2_COLORSPACE_BT2020`` |
| 57 | 57 | - See :ref:`col-bt2020`. |
| 58 | 58 | * - ``V4L2_COLORSPACE_DCI_P3`` |
| @@ -90,8 +90,8 @@ whole range, 0-255, dividing the angular value by 1.41. The enum · 31 unmodified lines | ||
| 90 | 90 | - Use the Rec. 709 transfer function. |
| 91 | 91 | * - ``V4L2_XFER_FUNC_SRGB`` |
| 92 | 92 | - Use the sRGB transfer function. |
| 93 | − * - ``V4L2_XFER_FUNC_ADOBERGB`` | |
| 94 | − - Use the AdobeRGB transfer function. | |
| 93 | + * - ``V4L2_XFER_FUNC_OPRGB`` | |
| 94 | + - Use the opRGB transfer function. | |
| 95 | 95 | * - ``V4L2_XFER_FUNC_SMPTE240M`` |
| 96 | 96 | - Use the SMPTE 240M transfer function. |
| 97 | 97 | * - ``V4L2_XFER_FUNC_NONE`` |
| @@ -290,15 +290,14 @@ Y' is clamped to the range [0…1] and Cb and Cr are clamped to the range · 289 unmodified lines | ||
| 290 | 290 | 170M/BT.601. The Y'CbCr quantization is limited range. |
| 291 | 291 | |
| 292 | 292 | |
| 293 | −.. _col-adobergb: | |
| 293 | +.. _col-oprgb: | |
| 294 | 294 | |
| 295 | −Colorspace Adobe RGB (V4L2_COLORSPACE_ADOBERGB) | |
| 295 | +Colorspace opRGB (V4L2_COLORSPACE_OPRGB) | |
| 296 | 296 | =============================================== |
| 297 | 297 | |
| 298 | −The :ref:`adobergb` standard defines the colorspace used by computer | |
| 299 | −graphics that use the AdobeRGB colorspace. This is also known as the | |
| 300 | −:ref:`oprgb` standard. The default transfer function is | |
| 301 | −``V4L2_XFER_FUNC_ADOBERGB``. The default Y'CbCr encoding is | |
| 298 | +The :ref:`oprgb` standard defines the colorspace used by computer | |
| 299 | +graphics that use the opRGB colorspace. The default transfer function is | |
| 300 | +``V4L2_XFER_FUNC_OPRGB``. The default Y'CbCr encoding is | |
| 302 | 301 | ``V4L2_YCBCR_ENC_601``. The default Y'CbCr quantization is limited |
| 303 | 302 | range. |
| 304 | 303 | |
| @@ -312,7 +311,7 @@ The chromaticities of the primary colors and the white reference are: · 7 unmodified lines | ||
| 312 | 311 | |
| 313 | 312 | .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}| |
| 314 | 313 | |
| 315 | −.. flat-table:: Adobe RGB Chromaticities | |
| 314 | +.. flat-table:: opRGB Chromaticities | |
| 316 | 315 | :header-rows: 1 |
| 317 | 316 | :stub-columns: 0 |
| 318 | 317 | :widths: 1 1 2 |
| @@ -1497,6 +1497,182 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - · 1496 unmodified lines | ||
| 1497 | 1497 | |
| 1498 | 1498 | |
| 1499 | 1499 | |
| 1500 | +.. _v4l2-mpeg-mpeg2: | |
| 1501 | + | |
| 1502 | +``V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS (struct)`` | |
| 1503 | + Specifies the slice parameters (as extracted from the bitstream) for the | |
| 1504 | + associated MPEG-2 slice data. This includes the necessary parameters for | |
| 1505 | + configuring a stateless hardware decoding pipeline for MPEG-2. | |
| 1506 | + The bitstream parameters are defined according to :ref:`mpeg2part2`. | |
| 1507 | + | |
| 1508 | +.. c:type:: v4l2_ctrl_mpeg2_slice_params | |
| 1509 | + | |
| 1510 | +.. cssclass:: longtable | |
| 1511 | + | |
| 1512 | +.. flat-table:: struct v4l2_ctrl_mpeg2_slice_params | |
| 1513 | + :header-rows: 0 | |
| 1514 | + :stub-columns: 0 | |
| 1515 | + :widths: 1 1 2 | |
| 1516 | + | |
| 1517 | + * - __u32 | |
| 1518 | + - ``bit_size`` | |
| 1519 | + - Size (in bits) of the current slice data. | |
| 1520 | + * - __u32 | |
| 1521 | + - ``data_bit_offset`` | |
| 1522 | + - Offset (in bits) to the video data in the current slice data. | |
| 1523 | + * - struct :c:type:`v4l2_mpeg2_sequence` | |
| 1524 | + - ``sequence`` | |
| 1525 | + - Structure with MPEG-2 sequence metadata, merging relevant fields from | |
| 1526 | + the sequence header and sequence extension parts of the bitstream. | |
| 1527 | + * - struct :c:type:`v4l2_mpeg2_picture` | |
| 1528 | + - ``picture`` | |
| 1529 | + - Structure with MPEG-2 picture metadata, merging relevant fields from | |
| 1530 | + the picture header and picture coding extension parts of the bitstream. | |
| 1531 | + * - __u8 | |
| 1532 | + - ``quantiser_scale_code`` | |
| 1533 | + - Code used to determine the quantization scale to use for the IDCT. | |
| 1534 | + * - __u8 | |
| 1535 | + - ``backward_ref_index`` | |
| 1536 | + - Index for the V4L2 buffer to use as backward reference, used with | |
| 1537 | + B-coded and P-coded frames. | |
| 1538 | + * - __u8 | |
| 1539 | + - ``forward_ref_index`` | |
| 1540 | + - Index for the V4L2 buffer to use as forward reference, used with | |
| 1541 | + B-coded frames. | |
| 1542 | + | |
| 1543 | +.. c:type:: v4l2_mpeg2_sequence | |
| 1544 | + | |
| 1545 | +.. cssclass:: longtable | |
| 1546 | + | |
| 1547 | +.. flat-table:: struct v4l2_mpeg2_sequence | |
| 1548 | + :header-rows: 0 | |
| 1549 | + :stub-columns: 0 | |
| 1550 | + :widths: 1 1 2 | |
| 1551 | + | |
| 1552 | + * - __u16 | |
| 1553 | + - ``horizontal_size`` | |
| 1554 | + - The width of the displayable part of the frame's luminance component. | |
| 1555 | + * - __u16 | |
| 1556 | + - ``vertical_size`` | |
| 1557 | + - The height of the displayable part of the frame's luminance component. | |
| 1558 | + * - __u32 | |
| 1559 | + - ``vbv_buffer_size`` | |
| 1560 | + - Used to calculate the required size of the video buffering verifier, | |
| 1561 | + defined (in bits) as: 16 * 1024 * vbv_buffer_size. | |
| 1562 | + * - __u8 | |
| 1563 | + - ``profile_and_level_indication`` | |
| 1564 | + - The current profile and level indication as extracted from the | |
| 1565 | + bitstream. | |
| 1566 | + * - __u8 | |
| 1567 | + - ``progressive_sequence`` | |
| 1568 | + - Indication that all the frames for the sequence are progressive instead | |
| 1569 | + of interlaced. | |
| 1570 | + * - __u8 | |
| 1571 | + - ``chroma_format`` | |
| 1572 | + - The chrominance sub-sampling format (1: 4:2:0, 2: 4:2:2, 3: 4:4:4). | |
| 1573 | + | |
| 1574 | +.. c:type:: v4l2_mpeg2_picture | |
| 1575 | + | |
| 1576 | +.. cssclass:: longtable | |
| 1577 | + | |
| 1578 | +.. flat-table:: struct v4l2_mpeg2_picture | |
| 1579 | + :header-rows: 0 | |
| 1580 | + :stub-columns: 0 | |
| 1581 | + :widths: 1 1 2 | |
| 1582 | + | |
| 1583 | + * - __u8 | |
| 1584 | + - ``picture_coding_type`` | |
| 1585 | + - Picture coding type for the frame covered by the current slice | |
| 1586 | + (V4L2_MPEG2_PICTURE_CODING_TYPE_I, V4L2_MPEG2_PICTURE_CODING_TYPE_P or | |
| 1587 | + V4L2_MPEG2_PICTURE_CODING_TYPE_B). | |
| 1588 | + * - __u8 | |
| 1589 | + - ``f_code[2][2]`` | |
| 1590 | + - Motion vector codes. | |
| 1591 | + * - __u8 | |
| 1592 | + - ``intra_dc_precision`` | |
| 1593 | + - Precision of Discrete Cosine transform (0: 8 bits precision, | |
| 1594 | + 1: 9 bits precision, 2: 10 bits precision, 3: 11 bits precision). | |
| 1595 | + * - __u8 | |
| 1596 | + - ``picture_structure`` | |
| 1597 | + - Picture structure (1: interlaced top field, 2: interlaced bottom field, | |
| 1598 | + 3: progressive frame). | |
| 1599 | + * - __u8 | |
| 1600 | + - ``top_field_first`` | |
| 1601 | + - If set to 1 and interlaced stream, top field is output first. | |
| 1602 | + * - __u8 | |
| 1603 | + - ``frame_pred_frame_dct`` | |
| 1604 | + - If set to 1, only frame-DCT and frame prediction are used. | |
| 1605 | + * - __u8 | |
| 1606 | + - ``concealment_motion_vectors`` | |
| 1607 | + - If set to 1, motion vectors are coded for intra macroblocks. | |
| 1608 | + * - __u8 | |
| 1609 | + - ``q_scale_type`` | |
| 1610 | + - This flag affects the inverse quantization process. | |
| 1611 | + * - __u8 | |
| 1612 | + - ``intra_vlc_format`` | |
| 1613 | + - This flag affects the decoding of transform coefficient data. | |
| 1614 | + * - __u8 | |
| 1615 | + - ``alternate_scan`` | |
| 1616 | + - This flag affects the decoding of transform coefficient data. | |
| 1617 | + * - __u8 | |
| 1618 | + - ``repeat_first_field`` | |
| 1619 | + - This flag affects the decoding process of progressive frames. | |
| 1620 | + * - __u8 | |
| 1621 | + - ``progressive_frame`` | |
| 1622 | + - Indicates whether the current frame is progressive. | |
| 1623 | + | |
| 1624 | +``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION (struct)`` | |
| 1625 | + Specifies quantization matrices (as extracted from the bitstream) for the | |
| 1626 | + associated MPEG-2 slice data. | |
| 1627 | + | |
| 1628 | +.. c:type:: v4l2_ctrl_mpeg2_quantization | |
| 1629 | + | |
| 1630 | +.. cssclass:: longtable | |
| 1631 | + | |
| 1632 | +.. flat-table:: struct v4l2_ctrl_mpeg2_quantization | |
| 1633 | + :header-rows: 0 | |
| 1634 | + :stub-columns: 0 | |
| 1635 | + :widths: 1 1 2 | |
| 1636 | + | |
| 1637 | + * - __u8 | |
| 1638 | + - ``load_intra_quantiser_matrix`` | |
| 1639 | + - One bit to indicate whether to load the ``intra_quantiser_matrix`` data. | |
| 1640 | + * - __u8 | |
| 1641 | + - ``load_non_intra_quantiser_matrix`` | |
| 1642 | + - One bit to indicate whether to load the ``non_intra_quantiser_matrix`` | |
| 1643 | + data. | |
| 1644 | + * - __u8 | |
| 1645 | + - ``load_chroma_intra_quantiser_matrix`` | |
| 1646 | + - One bit to indicate whether to load the | |
| 1647 | + ``chroma_intra_quantiser_matrix`` data, only relevant for non-4:2:0 YUV | |
| 1648 | + formats. | |
| 1649 | + * - __u8 | |
| 1650 | + - ``load_chroma_non_intra_quantiser_matrix`` | |
| 1651 | + - One bit to indicate whether to load the | |
| 1652 | + ``chroma_non_intra_quantiser_matrix`` data, only relevant for non-4:2:0 | |
| 1653 | + YUV formats. | |
| 1654 | + * - __u8 | |
| 1655 | + - ``intra_quantiser_matrix[64]`` | |
| 1656 | + - The quantization matrix coefficients for intra-coded frames, in zigzag | |
| 1657 | + scanning order. It is relevant for both luma and chroma components, | |
| 1658 | + although it can be superseded by the chroma-specific matrix for | |
| 1659 | + non-4:2:0 YUV formats. | |
| 1660 | + * - __u8 | |
| 1661 | + - ``non_intra_quantiser_matrix[64]`` | |
| 1662 | + - The quantization matrix coefficients for non-intra-coded frames, in | |
| 1663 | + zigzag scanning order. It is relevant for both luma and chroma | |
| 1664 | + components, although it can be superseded by the chroma-specific matrix | |
| 1665 | + for non-4:2:0 YUV formats. | |
| 1666 | + * - __u8 | |
| 1667 | + - ``chroma_intra_quantiser_matrix[64]`` | |
| 1668 | + - The quantization matrix coefficients for the chominance component of | |
| 1669 | + intra-coded frames, in zigzag scanning order. Only relevant for | |
| 1670 | + non-4:2:0 YUV formats. | |
| 1671 | + * - __u8 | |
| 1672 | + - ``chroma_non_intra_quantiser_matrix[64]`` | |
| 1673 | + - The quantization matrix coefficients for the chrominance component of | |
| 1674 | + non-intra-coded frames, in zigzag scanning order. Only relevant for | |
| 1675 | + non-4:2:0 YUV formats. | |
| 1500 | 1676 | |
| 1501 | 1677 | MFC 5.1 MPEG Controls |
| 1502 | 1678 | --------------------- |
| @@ -113,4 +113,5 @@ EINTR · 112 unmodified lines | ||
| 113 | 113 | The call was interrupted by a signal. |
| 114 | 114 | |
| 115 | 115 | EINVAL |
| 116 | − The ``nfds`` argument is greater than ``OPEN_MAX``. | |
| 116 | + The ``nfds`` value exceeds the ``RLIMIT_NOFILE`` value. Use | |
| 117 | + ``getrlimit()`` to obtain this value. | |
| @@ -12,6 +12,7 @@ These formats are used for the :ref:`metadata` interface only. · 11 unmodified lines | ||
| 12 | 12 | .. toctree:: |
| 13 | 13 | :maxdepth: 1 |
| 14 | 14 | |
| 15 | + pixfmt-meta-d4xx | |
| 15 | 16 | pixfmt-meta-uvc |
| 16 | 17 | pixfmt-meta-vsp1-hgo |
| 17 | 18 | pixfmt-meta-vsp1-hgt |
| @@ -60,6 +60,22 @@ Compressed Formats · 59 unmodified lines | ||
| 60 | 60 | - ``V4L2_PIX_FMT_MPEG2`` |
| 61 | 61 | - 'MPG2' |
| 62 | 62 | - MPEG2 video elementary stream. |
| 63 | + * .. _V4L2-PIX-FMT-MPEG2-SLICE: | |
| 64 | + | |
| 65 | + - ``V4L2_PIX_FMT_MPEG2_SLICE`` | |
| 66 | + - 'MG2S' | |
| 67 | + - MPEG-2 parsed slice data, as extracted from the MPEG-2 bitstream. | |
| 68 | + This format is adapted for stateless video decoders that implement a | |
| 69 | + MPEG-2 pipeline (using the :ref:`codec` and :ref:`media-request-api`). | |
| 70 | + Metadata associated with the frame to decode is required to be passed | |
| 71 | + through the ``V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS`` control and | |
| 72 | + quantization matrices can optionally be specified through the | |
| 73 | + ``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION`` control. | |
| 74 | + See the :ref:`associated Codec Control IDs <v4l2-mpeg-mpeg2>`. | |
| 75 | + Exactly one output and one capture buffer must be provided for use with | |
| 76 | + this pixel format. The output buffer must contain the appropriate number | |
| 77 | + of macroblocks to decode a full corresponding frame to the matching | |
| 78 | + capture buffer. | |
| 63 | 79 | * .. _V4L2-PIX-FMT-MPEG4: |
| 64 | 80 | |
| 65 | 81 | - ``V4L2_PIX_FMT_MPEG4`` |
| @@ -101,4 +117,4 @@ Compressed Formats · 35 unmodified lines | ||
| 101 | 117 | - 'FWHT' |
| 102 | 118 | - Video elementary stream using a codec based on the Fast Walsh Hadamard |
| 103 | 119 | Transform. This codec is implemented by the vicodec ('Virtual Codec') |
| 104 | − driver. See the vicodec-codec.h header for more details. | |
| 120 | + driver. See the codec-fwht.h header for more details. | |
| @@ -0,0 +1,210 @@ | ||
| 1 | +.. -*- coding: utf-8; mode: rst -*- | |
| 2 | + | |
| 3 | +.. _v4l2-meta-fmt-d4xx: | |
| 4 | + | |
| 5 | +******************************* | |
| 6 | +V4L2_META_FMT_D4XX ('D4XX') | |
| 7 | +******************************* | |
| 8 | + | |
| 9 | +Intel D4xx UVC Cameras Metadata | |
| 10 | + | |
| 11 | + | |
| 12 | +Description | |
| 13 | +=========== | |
| 14 | + | |
| 15 | +Intel D4xx (D435 and other) cameras include per-frame metadata in their UVC | |
| 16 | +payload headers, following the Microsoft(R) UVC extension proposal [1_]. That | |
| 17 | +means, that the private D4XX metadata, following the standard UVC header, is | |
| 18 | +organised in blocks. D4XX cameras implement several standard block types, | |
| 19 | +proposed by Microsoft, and several proprietary ones. Supported standard metadata | |
| 20 | +types are MetadataId_CaptureStats (ID 3), MetadataId_CameraExtrinsics (ID 4), | |
| 21 | +and MetadataId_CameraIntrinsics (ID 5). For their description see [1_]. This | |
| 22 | +document describes proprietary metadata types, used by D4xx cameras. | |
| 23 | + | |
| 24 | +V4L2_META_FMT_D4XX buffers follow the metadata buffer layout of | |
| 25 | +V4L2_META_FMT_UVC with the only difference, that it also includes proprietary | |
| 26 | +payload header data. D4xx cameras use bulk transfers and only send one payload | |
| 27 | +per frame, therefore their headers cannot be larger than 255 bytes. | |
| 28 | + | |
| 29 | +Below are proprietary Microsoft style metadata types, used by D4xx cameras, | |
| 30 | +where all fields are in little endian order: | |
| 31 | + | |
| 32 | +.. flat-table:: D4xx metadata | |
| 33 | + :widths: 1 4 | |
| 34 | + :header-rows: 1 | |
| 35 | + :stub-columns: 0 | |
| 36 | + | |
| 37 | + * - Field | |
| 38 | + - Description | |
| 39 | + * - :cspan:`1` *Depth Control* | |
| 40 | + * - __u32 ID | |
| 41 | + - 0x80000000 | |
| 42 | + * - __u32 Size | |
| 43 | + - Size in bytes (currently 56) | |
| 44 | + * - __u32 Version | |
| 45 | + - Version of this structure. The documentation herein corresponds to | |
| 46 | + version xxx. The version number will be incremented when new fields are | |
| 47 | + added. | |
| 48 | + * - __u32 Flags | |
| 49 | + - A bitmask of flags: see [2_] below | |
| 50 | + * - __u32 Gain | |
| 51 | + - Gain value in internal units, same as the V4L2_CID_GAIN control, used to | |
| 52 | + capture the frame | |
| 53 | + * - __u32 Exposure | |
| 54 | + - Exposure time (in microseconds) used to capture the frame | |
| 55 | + * - __u32 Laser power | |
| 56 | + - Power of the laser LED 0-360, used for depth measurement | |
| 57 | + * - __u32 AE mode | |
| 58 | + - 0: manual; 1: automatic exposure | |
| 59 | + * - __u32 Exposure priority | |
| 60 | + - Exposure priority value: 0 - constant frame rate | |
| 61 | + * - __u32 AE ROI left | |
| 62 | + - Left border of the AE Region of Interest (all ROI values are in pixels | |
| 63 | + and lie between 0 and maximum width or height respectively) | |
| 64 | + * - __u32 AE ROI right | |
| 65 | + - Right border of the AE Region of Interest | |
| 66 | + * - __u32 AE ROI top | |
| 67 | + - Top border of the AE Region of Interest | |
| 68 | + * - __u32 AE ROI bottom | |
| 69 | + - Bottom border of the AE Region of Interest | |
| 70 | + * - __u32 Preset | |
| 71 | + - Preset selector value, default: 0, unless changed by the user | |
| 72 | + * - __u32 Laser mode | |
| 73 | + - 0: off, 1: on | |
| 74 | + * - :cspan:`1` *Capture Timing* | |
| 75 | + * - __u32 ID | |
| 76 | + - 0x80000001 | |
| 77 | + * - __u32 Size | |
| 78 | + - Size in bytes (currently 40) | |
| 79 | + * - __u32 Version | |
| 80 | + - Version of this structure. The documentation herein corresponds to | |
| 81 | + version xxx. The version number will be incremented when new fields are | |
| 82 | + added. | |
| 83 | + * - __u32 Flags | |
| 84 | + - A bitmask of flags: see [3_] below | |
| 85 | + * - __u32 Frame counter | |
| 86 | + - Monotonically increasing counter | |
| 87 | + * - __u32 Optical time | |
| 88 | + - Time in microseconds from the beginning of a frame till its middle | |
| 89 | + * - __u32 Readout time | |
| 90 | + - Time, used to read out a frame in microseconds | |
| 91 | + * - __u32 Exposure time | |
| 92 | + - Frame exposure time in microseconds | |
| 93 | + * - __u32 Frame interval | |
| 94 | + - In microseconds = 1000000 / framerate | |
| 95 | + * - __u32 Pipe latency | |
| 96 | + - Time in microseconds from start of frame to data in USB buffer | |
| 97 | + * - :cspan:`1` *Configuration* | |
| 98 | + * - __u32 ID | |
| 99 | + - 0x80000002 | |
| 100 | + * - __u32 Size | |
| 101 | + - Size in bytes (currently 40) | |
| 102 | + * - __u32 Version | |
| 103 | + - Version of this structure. The documentation herein corresponds to | |
| 104 | + version xxx. The version number will be incremented when new fields are | |
| 105 | + added. | |
| 106 | + * - __u32 Flags | |
| 107 | + - A bitmask of flags: see [4_] below | |
| 108 | + * - __u8 Hardware type | |
| 109 | + - Camera hardware version [5_] | |
| 110 | + * - __u8 SKU ID | |
| 111 | + - Camera hardware configuration [6_] | |
| 112 | + * - __u32 Cookie | |
| 113 | + - Internal synchronisation | |
| 114 | + * - __u16 Format | |
| 115 | + - Image format code [7_] | |
| 116 | + * - __u16 Width | |
| 117 | + - Width in pixels | |
| 118 | + * - __u16 Height | |
| 119 | + - Height in pixels | |
| 120 | + * - __u16 Framerate | |
| 121 | + - Requested frame rate per second | |
| 122 | + * - __u16 Trigger | |
| 123 | + - Byte 0: bit 0: depth and RGB are synchronised, bit 1: external trigger | |
| 124 | + | |
| 125 | +.. _1: | |
| 126 | + | |
| 127 | +[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/stream/uvc-extensions-1-5 | |
| 128 | + | |
| 129 | +.. _2: | |
| 130 | + | |
| 131 | +[2] Depth Control flags specify which fields are valid: :: | |
| 132 | + | |
| 133 | + 0x00000001 Gain | |
| 134 | + 0x00000002 Exposure | |
| 135 | + 0x00000004 Laser power | |
| 136 | + 0x00000008 AE mode | |
| 137 | + 0x00000010 Exposure priority | |
| 138 | + 0x00000020 AE ROI | |
| 139 | + 0x00000040 Preset | |
| 140 | + | |
| 141 | +.. _3: | |
| 142 | + | |
| 143 | +[3] Capture Timing flags specify which fields are valid: :: | |
| 144 | + | |
| 145 | + 0x00000001 Frame counter | |
| 146 | + 0x00000002 Optical time | |
| 147 | + 0x00000004 Readout time | |
| 148 | + 0x00000008 Exposure time | |
| 149 | + 0x00000010 Frame interval | |
| 150 | + 0x00000020 Pipe latency | |
| 151 | + | |
| 152 | +.. _4: | |
| 153 | + | |
| 154 | +[4] Configuration flags specify which fields are valid: :: | |
| 155 | + | |
| 156 | + 0x00000001 Hardware type | |
| 157 | + 0x00000002 SKU ID | |
| 158 | + 0x00000004 Cookie | |
| 159 | + 0x00000008 Format | |
| 160 | + 0x00000010 Width | |
| 161 | + 0x00000020 Height | |
| 162 | + 0x00000040 Framerate | |
| 163 | + 0x00000080 Trigger | |
| 164 | + 0x00000100 Cal count | |
| 165 | + | |
| 166 | +.. _5: | |
| 167 | + | |
| 168 | +[5] Camera model: :: | |
| 169 | + | |
| 170 | + 0 DS5 | |
| 171 | + 1 IVCAM2 | |
| 172 | + | |
| 173 | +.. _6: | |
| 174 | + | |
| 175 | +[6] 8-bit camera hardware configuration bitfield: :: | |
| 176 | + | |
| 177 | + [1:0] depthCamera | |
| 178 | + 00: no depth | |
| 179 | + 01: standard depth | |
| 180 | + 10: wide depth | |
| 181 | + 11: reserved | |
| 182 | + [2] depthIsActive - has a laser projector | |
| 183 | + [3] RGB presence | |
| 184 | + [4] Inertial Measurement Unit (IMU) presence | |
| 185 | + [5] projectorType | |
| 186 | + 0: HPTG | |
| 187 | + 1: Princeton | |
| 188 | + [6] 0: a projector, 1: an LED | |
| 189 | + [7] reserved | |
| 190 | + | |
| 191 | +.. _7: | |
| 192 | + | |
| 193 | +[7] Image format codes per video streaming interface: | |
| 194 | + | |
| 195 | +Depth: :: | |
| 196 | + | |
| 197 | + 1 Z16 | |
| 198 | + 2 Z | |
| 199 | + | |
| 200 | +Left sensor: :: | |
| 201 | + | |
| 202 | + 1 Y8 | |
| 203 | + 2 UYVY | |
| 204 | + 3 R8L8 | |
| 205 | + 4 Calibration | |
| 206 | + 5 W10 | |
| 207 | + | |
| 208 | +Fish Eye sensor: :: | |
| 209 | + | |
| 210 | + 1 RAW8 | |
| @@ -243,7 +243,20 @@ please make a proposal on the linux-media mailing list. · 242 unmodified lines | ||
| 243 | 243 | It is an opaque intermediate format and the MDP hardware must be |
| 244 | 244 | used to convert ``V4L2_PIX_FMT_MT21C`` to ``V4L2_PIX_FMT_NV12M``, |
| 245 | 245 | ``V4L2_PIX_FMT_YUV420M`` or ``V4L2_PIX_FMT_YVU420``. |
| 246 | − | |
| 246 | + * .. _V4L2-PIX-FMT-SUNXI-TILED-NV12: | |
| 247 | + | |
| 248 | + - ``V4L2_PIX_FMT_SUNXI_TILED_NV12`` | |
| 249 | + - 'ST12' | |
| 250 | + - Two-planar NV12-based format used by the video engine found on Allwinner | |
| 251 | + (codenamed sunxi) platforms, with 32x32 tiles for the luminance plane | |
| 252 | + and 32x64 tiles for the chrominance plane. The data in each tile is | |
| 253 | + stored in linear order, within the tile bounds. Each tile follows the | |
| 254 | + previous one linearly in memory (from left to right, top to bottom). | |
| 255 | + | |
| 256 | + The associated buffer dimensions are aligned to match an integer number | |
| 257 | + of tiles, resulting in 32-aligned resolutions for the luminance plane | |
| 258 | + and 16-aligned resolutions for the chrominance plane (with 2x2 | |
| 259 | + subsampling). | |
| 247 | 260 | |
| 248 | 261 | .. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}| |
| 249 | 262 | |
| @@ -102,7 +102,19 @@ than the number requested. · 101 unmodified lines | ||
| 102 | 102 | - ``format`` |
| 103 | 103 | - Filled in by the application, preserved by the driver. |
| 104 | 104 | * - __u32 |
| 105 | − - ``reserved``\ [8] | |
| 105 | + - ``capabilities`` | |
| 106 | + - Set by the driver. If 0, then the driver doesn't support | |
| 107 | + capabilities. In that case all you know is that the driver is | |
| 108 | + guaranteed to support ``V4L2_MEMORY_MMAP`` and *might* support | |
| 109 | + other :c:type:`v4l2_memory` types. It will not support any others | |
| 110 | + capabilities. See :ref:`here <v4l2-buf-capabilities>` for a list of the | |
| 111 | + capabilities. | |
| 112 | + | |
| 113 | + If you want to just query the capabilities without making any | |
| 114 | + other changes, then set ``count`` to 0, ``memory`` to | |
| 115 | + ``V4L2_MEMORY_MMAP`` and ``format.type`` to the buffer type. | |
| 116 | + * - __u32 | |
| 117 | + - ``reserved``\ [7] | |
| 106 | 118 | - A place holder for future extensions. Drivers and applications |
| 107 | 119 | must set the array to zero. |
| 108 | 120 | |
| @@ -58,7 +58,7 @@ overlay devices. · 57 unmodified lines | ||
| 58 | 58 | - Type of the data stream, set by the application. Only these types |
| 59 | 59 | are valid here: ``V4L2_BUF_TYPE_VIDEO_CAPTURE``, ``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE``, |
| 60 | 60 | ``V4L2_BUF_TYPE_VIDEO_OUTPUT``, ``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE`` and |
| 61 | − ``V4L2_BUF_TYPE_VIDEO_OVERLAY``. See :c:type:`v4l2_buf_type` and the note above. | |
| 61 | + ``V4L2_BUF_TYPE_VIDEO_OVERLAY``. See :c:type:`v4l2_buf_type` and the note below. | |
| 62 | 62 | * - struct :ref:`v4l2_rect <v4l2-rect-crop>` |
| 63 | 63 | - ``bounds`` |
| 64 | 64 | - Defines the window within capturing or output is possible, this |
| @@ -379,7 +379,17 @@ call. · 378 unmodified lines | ||
| 379 | 379 | - 0x0001 |
| 380 | 380 | - This event gets triggered when a resolution change is detected at |
| 381 | 381 | an input. This can come from an input connector or from a video |
| 382 | − decoder. | |
| 382 | + decoder. Applications will have to query the new resolution (if | |
| 383 | + any, the signal may also have been lost). | |
| 384 | + | |
| 385 | + *Important*: even if the new video timings appear identical to the old | |
| 386 | + ones, receiving this event indicates that there was an issue with the | |
| 387 | + video signal and you must stop and restart streaming | |
| 388 | + (:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` | |
| 389 | + followed by :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>`). The reason is | |
| 390 | + that many devices are not able to recover from a temporary loss of | |
| 391 | + signal and so restarting streaming I/O is required in order for the | |
| 392 | + hardware to synchronize to the video signal. | |
| 383 | 393 | |
| 384 | 394 | |
| 385 | 395 | Return Value |
| @@ -84,7 +84,7 @@ When cropping is not supported then no parameters are changed and · 83 unmodified lines | ||
| 84 | 84 | - Type of the data stream, set by the application. Only these types |
| 85 | 85 | are valid here: ``V4L2_BUF_TYPE_VIDEO_CAPTURE``, ``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE``, |
| 86 | 86 | ``V4L2_BUF_TYPE_VIDEO_OUTPUT``, ``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE`` and |
| 87 | − ``V4L2_BUF_TYPE_VIDEO_OVERLAY``. See :c:type:`v4l2_buf_type` and the note above. | |
| 87 | + ``V4L2_BUF_TYPE_VIDEO_OVERLAY``. See :c:type:`v4l2_buf_type` and the note below. | |
| 88 | 88 | * - struct :c:type:`v4l2_rect` |
| 89 | 89 | - ``c`` |
| 90 | 90 | - Cropping rectangle. The same co-ordinate system as for struct |
| @@ -257,14 +257,19 @@ EBUSY · 256 unmodified lines | ||
| 257 | 257 | will also be cleared. This is a read-only flag, applications must |
| 258 | 258 | not set this. |
| 259 | 259 | * - ``V4L2_DV_FL_REDUCED_FPS`` |
| 260 | − - CEA-861 specific: only valid for video transmitters, the flag is | |
| 261 | − cleared by receivers. It is also only valid for formats with the | |
| 262 | − ``V4L2_DV_FL_CAN_REDUCE_FPS`` flag set, for other formats the | |
| 263 | − flag will be cleared by the driver. If the application sets this | |
| 264 | − flag, then the pixelclock used to set up the transmitter is | |
| 265 | − divided by 1.001 to make it compatible with NTSC framerates. If | |
| 266 | − the transmitter can't generate such frequencies, then the flag | |
| 267 | − will also be cleared. | |
| 260 | + - CEA-861 specific: only valid for video transmitters or video | |
| 261 | + receivers that have the ``V4L2_DV_FL_CAN_DETECT_REDUCED_FPS`` | |
| 262 | + set. This flag is cleared otherwise. It is also only valid for | |
| 263 | + formats with the ``V4L2_DV_FL_CAN_REDUCE_FPS`` flag set, for other | |
| 264 | + formats the flag will be cleared by the driver. | |
| 265 | + | |
| 266 | + If the application sets this flag for a transmitter, then the | |
| 267 | + pixelclock used to set up the transmitter is divided by 1.001 to | |
| 268 | + make it compatible with NTSC framerates. If the transmitter can't | |
| 269 | + generate such frequencies, then the flag will be cleared. | |
| 270 | + | |
| 271 | + If a video receiver detects that the format uses a reduced framerate, | |
| 272 | + then it will set this flag to signal this to the application. | |
| 268 | 273 | * - ``V4L2_DV_FL_HALF_LINE`` |
| 269 | 274 | - Specific to interlaced formats: if set, then the vertical |
| 270 | 275 | backporch of field 1 (aka the odd field) is really one half-line |
| @@ -294,3 +299,9 @@ EBUSY · 23 unmodified lines | ||
| 294 | 299 | - If set, then the hdmi_vic field is valid and contains the Video |
| 295 | 300 | Identification Code as per the HDMI standard (HDMI Vendor Specific |
| 296 | 301 | InfoFrame). |
| 302 | + * - ``V4L2_DV_FL_CAN_DETECT_REDUCED_FPS`` | |
| 303 | + - CEA-861 specific: only valid for video receivers, the flag is | |
| 304 | + cleared by transmitters. | |
| 305 | + If set, then the hardware can detect the difference between | |
| 306 | + regular framerates and framerates reduced by 1000/1001. E.g.: | |
| 307 | + 60 vs 59.94 Hz, 30 vs 29.97 Hz or 24 vs 23.976 Hz. | |
| @@ -95,6 +95,25 @@ appropriate. In the first case the new value is set in struct · 94 unmodified lines | ||
| 95 | 95 | is inappropriate (e.g. the given menu index is not supported by the menu |
| 96 | 96 | control), then this will also result in an ``EINVAL`` error code error. |
| 97 | 97 | |
| 98 | +If ``request_fd`` is set to a not-yet-queued :ref:`request <media-request-api>` | |
| 99 | +file descriptor and ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``, | |
| 100 | +then the controls are not applied immediately when calling | |
| 101 | +:ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`, but instead are applied by | |
| 102 | +the driver for the buffer associated with the same request. | |
| 103 | +If the device does not support requests, then ``EACCES`` will be returned. | |
| 104 | +If requests are supported but an invalid request file descriptor is given, | |
| 105 | +then ``EINVAL`` will be returned. | |
| 106 | + | |
| 107 | +An attempt to call :ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` for a | |
| 108 | +request that has already been queued will result in an ``EBUSY`` error. | |
| 109 | + | |
| 110 | +If ``request_fd`` is specified and ``which`` is set to | |
| 111 | +``V4L2_CTRL_WHICH_REQUEST_VAL`` during a call to | |
| 112 | +:ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`, then it will return the | |
| 113 | +values of the controls at the time of request completion. | |
| 114 | +If the request is not yet completed, then this will result in an | |
| 115 | +``EACCES`` error. | |
| 116 | + | |
| 98 | 117 | The driver will only set/get these controls if all control values are |
| 99 | 118 | correct. This prevents the situation where only some of the controls |
| 100 | 119 | were set/get. Only low-level errors (e. g. a failed i2c command) can |
| @@ -209,13 +228,17 @@ still cause this situation. · 108 unmodified lines | ||
| 209 | 228 | - ``which`` |
| 210 | 229 | - Which value of the control to get/set/try. |
| 211 | 230 | ``V4L2_CTRL_WHICH_CUR_VAL`` will return the current value of the |
| 212 | − control and ``V4L2_CTRL_WHICH_DEF_VAL`` will return the default | |
| 213 | − value of the control. | |
| 231 | + control, ``V4L2_CTRL_WHICH_DEF_VAL`` will return the default | |
| 232 | + value of the control and ``V4L2_CTRL_WHICH_REQUEST_VAL`` indicates that | |
| 233 | + these controls have to be retrieved from a request or tried/set for | |
| 234 | + a request. In the latter case the ``request_fd`` field contains the | |
| 235 | + file descriptor of the request that should be used. If the device | |
| 236 | + does not support requests, then ``EACCES`` will be returned. | |
| 214 | 237 | |
| 215 | 238 | .. note:: |
| 216 | 239 | |
| 217 | − You can only get the default value of the control, | |
| 218 | − you cannot set or try it. | |
| 240 | + When using ``V4L2_CTRL_WHICH_DEF_VAL`` be aware that you can only | |
| 241 | + get the default value of the control, you cannot set or try it. | |
| 219 | 242 | |
| 220 | 243 | For backwards compatibility you can also use a control class here |
| 221 | 244 | (see :ref:`ctrl-class`). In that case all controls have to |
| @@ -272,8 +295,15 @@ still cause this situation. · 50 unmodified lines | ||
| 272 | 295 | then you can call :ref:`VIDIOC_TRY_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` to try to discover the |
| 273 | 296 | actual control that failed the validation step. Unfortunately, |
| 274 | 297 | there is no ``TRY`` equivalent for :ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`. |
| 298 | + * - __s32 | |
| 299 | + - ``request_fd`` | |
| 300 | + - File descriptor of the request to be used by this operation. Only | |
| 301 | + valid if ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``. | |
| 302 | + If the device does not support requests, then ``EACCES`` will be returned. | |
| 303 | + If requests are supported but an invalid request file descriptor is | |
| 304 | + given, then ``EINVAL`` will be returned. | |
| 275 | 305 | * - __u32 |
| 276 | − - ``reserved``\ [2] | |
| 306 | + - ``reserved``\ [1] | |
| 277 | 307 | - Reserved for future extensions. |
| 278 | 308 | |
| 279 | 309 | Drivers and applications must set the array to zero. |
| @@ -347,11 +377,14 @@ appropriately. The generic error codes are described at the · 67 unmodified lines | ||
| 347 | 377 | |
| 348 | 378 | EINVAL |
| 349 | 379 | The struct :c:type:`v4l2_ext_control` ``id`` is |
36 more lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 52 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 5 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 114 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 235 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
File renamed without changes.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 383 lines aren’t shown here.
This diff is large: its 313 lines aren’t shown here.
This diff is large: its 146 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 771 lines aren’t shown here.
This diff is large: its 191 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 282 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 194 lines aren’t shown here.
This diff is large: its 130 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 81 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 468 lines aren’t shown here.
This diff is large: its 434 lines aren’t shown here.
This diff is large: its 528 lines aren’t shown here.
This diff is large: its 350 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 32 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 38 lines aren’t shown here.
This diff is large: its 7 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 35 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 157 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 120 lines aren’t shown here.
This diff is large: its 20 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 46 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 838 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 397 lines aren’t shown here.
This diff is large: its 109 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 238 lines aren’t shown here.
This diff is large: its 28 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 84 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 657 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 58 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 15 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 27 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 63 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 207 lines aren’t shown here.
This diff is large: its 51 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 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 122 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 67 lines aren’t shown here.
This diff is large: its 33 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 185 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 398 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 1786 lines aren’t shown here.
This diff is large: its 219 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 17 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 8 lines aren’t shown here.
This diff is large: its 38 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 28 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 14 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 26 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 95 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 42 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 434 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 183 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 56 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 27 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 8 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 58 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 24 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 64 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 116 lines aren’t shown here.
This diff is large: its 20 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 16 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 27 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 250 lines aren’t shown here.
This diff is large: its 70 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 29 lines aren’t shown here.
This diff is large: its 36 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 8 lines aren’t shown here.
This diff is large: its 221 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 16 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 16 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 8 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 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 156 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 7 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 26 lines aren’t shown here.
This diff is large: its 208 lines aren’t shown here.
This diff is large: its 147 lines aren’t shown here.
This diff is large: its 93 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 12 lines aren’t shown here.
This diff is large: its 152 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 46 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 35 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 88 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 35 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 13 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 13 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 28 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 28 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 34 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 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 23 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 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 156 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 180 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 202 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 33 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 730 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 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 18 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 18 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 18 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 18 lines aren’t shown here.
This diff is large: its 25 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 18 lines aren’t shown here.
This diff is large: its 9 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 18 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 9 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 36 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 18 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 6 lines aren’t shown here.
This diff is large: its 45 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 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 19 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 45 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 11 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 63 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 11 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 391 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 123 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 62 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 39 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 280 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 18 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 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 249 lines aren’t shown here.
This diff is large: its 158 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 166 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 31 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 466 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 142 lines aren’t shown here.
This diff is large: its 115 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 11 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 11 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 163 lines aren’t shown here.
This diff is large: its 212 lines aren’t shown here.
This diff is large: its 108 lines aren’t shown here.
This diff is large: its 128 lines aren’t shown here.
This diff is large: its 308 lines aren’t shown here.
This diff is large: its 97 lines aren’t shown here.
This diff is large: its 545 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 26 lines aren’t shown here.
This diff is large: its 299 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 17 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 26 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 8 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 119 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 103 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 506 lines aren’t shown here.
This diff is large: its 503 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 186 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 74 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 15 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 23 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 17 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 33 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 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 101 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 10 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 40 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 14 lines aren’t shown here.
This diff is large: its 198 lines aren’t shown here.
This diff is large: its 141 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 30 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 32 lines aren’t shown here.
This diff is large: its 232 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 131 lines aren’t shown here.
This diff is large: its 1610 lines aren’t shown here.
This diff is large: its 1607 lines aren’t shown here.
This diff is large: its 263 lines aren’t shown here.
This diff is large: its 276 lines aren’t shown here.
This diff is large: its 893 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 278 lines aren’t shown here.
This diff is large: its 267 lines aren’t shown here.
This diff is large: its 1190 lines aren’t shown here.
This diff is large: its 1144 lines aren’t shown here.
This diff is large: its 232 lines aren’t shown here.
This diff is large: its 1074 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 37 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 23 lines aren’t shown here.
This diff is large: its 238 lines aren’t shown here.
This diff is large: its 75 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 267 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 69 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 47 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 101 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 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 49 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 128 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 65 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 47 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 397 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 140 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 435 lines aren’t shown here.
This diff is large: its 289 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 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 44 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 29 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 25 lines aren’t shown here.
This diff is large: its 46 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 85 lines aren’t shown here.
This diff is large: its 13 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 10 lines aren’t shown here.
This diff is large: its 84 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 11 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 98 lines aren’t shown here.
This diff is large: its 86 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 18 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 138 lines aren’t shown here.
This diff is large: its 59 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 13 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 9 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 17 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 15 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 16 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 8 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 47 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 57 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 40 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 289 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 18 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 18 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 124 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 164 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 45 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 65 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 276 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 57 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 17 lines aren’t shown here.
This diff is large: its 41 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 17 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 213 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 16 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 44 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 277 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 36 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 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 56 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 5 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 118 lines aren’t shown here.
This diff is large: its 119 lines aren’t shown here.
This diff is large: its 53 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 88 lines aren’t shown here.
This diff is large: its 243 lines aren’t shown here.
This diff is large: its 191 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 65 lines aren’t shown here.
This diff is large: its 133 lines aren’t shown here.
This diff is large: its 155 lines aren’t shown here.
This diff is large: its 236 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 49 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 9 lines aren’t shown here.
This diff is large: its 278 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 50 lines aren’t shown here.
This diff is large: its 151 lines aren’t shown here.
This diff is large: its 30 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 18 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 464 lines aren’t shown here.
This diff is large: its 1994 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 173 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 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 324 lines aren’t shown here.
This diff is large: its 94 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 3 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 44 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 16 lines aren’t shown here.
This diff is large: its 39 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 30 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 7 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 364 lines aren’t shown here.
This diff is large: its 56 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 9 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 442 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 139 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 369 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 531 lines aren’t shown here.
This diff is large: its 217 lines aren’t shown here.
This diff is large: its 104 lines aren’t shown here.
This diff is large: its 120 lines aren’t shown here.
This diff is large: its 72 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 99 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 21 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 224 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 244 lines aren’t shown here.
This diff is large: its 691 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 403 lines aren’t shown here.
This diff is large: its 338 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 1664 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 13 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 416 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 306 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 684 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 185 lines aren’t shown here.
This diff is large: its 220 lines aren’t shown here.
This diff is large: its 162 lines aren’t shown here.
This diff is large: its 783 lines aren’t shown here.
This diff is large: its 314 lines aren’t shown here.
This diff is large: its 850 lines aren’t shown here.
This diff is large: its 471 lines aren’t shown here.
This diff is large: its 151 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 25 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 236 lines aren’t shown here.
This diff is large: its 2048 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 576 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 681 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 543 lines aren’t shown here.
This diff is large: its 693 lines aren’t shown here.
This diff is large: its 146 lines aren’t shown here.
This diff is large: its 88 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 290 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 318 lines aren’t shown here.
This diff is large: its 174 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 141 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 357 lines aren’t shown here.
This diff is large: its 646 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 288 lines aren’t shown here.
This diff is large: its 245 lines aren’t shown here.
This diff is large: its 463 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 353 lines aren’t shown here.
This diff is large: its 283 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 51 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 16 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 203 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 77 lines aren’t shown here.
This diff is large: its 16 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 10 lines aren’t shown here.
This diff is large: its 19 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 90 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 43 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 292 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 105 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 184 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 13 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 7 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 7 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 26 lines aren’t shown here.
This diff is large: its 170 lines aren’t shown here.
This diff is large: its 299 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 25 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 97 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 21 lines aren’t shown here.
This diff is large: its 64 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 32 lines aren’t shown here.
This diff is large: its 115 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 64 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 401 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 112 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 8 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 91 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 18 lines aren’t shown here.
This diff is large: its 146 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 61 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 46 lines aren’t shown here.
This diff is large: its 449 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 289 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 32 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 23 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 18 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 93 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 28 lines aren’t shown here.
This diff is large: its 204 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 327 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 53 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 161 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 28 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 348 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 67 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 61 lines aren’t shown here.
This diff is large: its 276 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 157 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 15 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 27 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 153 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 84 lines aren’t shown here.
This diff is large: its 169 lines aren’t shown here.
This diff is large: its 124 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 62 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 213 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 27 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.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 151 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 116 lines aren’t shown here.
This diff is large: its 307 lines aren’t shown here.
This diff is large: its 116 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 12 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 257 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 76 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 45 lines aren’t shown here.
This diff is large: its 417 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 33 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 105 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 9 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 397 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 93 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 137 lines aren’t shown here.
This diff is large: its 315 lines aren’t shown here.
This diff is large: its 162 lines aren’t shown here.
This diff is large: its 348 lines aren’t shown here.
This diff is large: its 238 lines aren’t shown here.
This diff is large: its 44 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 170 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 263 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 127 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 255 lines aren’t shown here.
This diff is large: its 213 lines aren’t shown here.
This diff is large: its 199 lines aren’t shown here.
This diff is large: its 122 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 220 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 13 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 8 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 41 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 178 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 10 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 18 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 16 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 16 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 9 lines aren’t shown here.
This diff is large: its 58 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 9 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 9 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 112 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 268 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 21 lines aren’t shown here.
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 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 42 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 28 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 12 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 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 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 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 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 13 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 10 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 132 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 36 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 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 27 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 26 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 26 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 30 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 313 lines aren’t shown here.
This diff is large: its 70 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 9 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 9 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 22 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 95 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 108 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 51 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 28 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 9 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 45 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 130 lines aren’t shown here.
This diff is large: its 61 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 18 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 258 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 45 lines aren’t shown here.
This diff is large: its 152 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 181 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 19 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 18 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 35 lines aren’t shown here.
This diff is large: its 35 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 53 lines aren’t shown here.
This diff is large: its 218 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 46 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 342 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 173 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 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 8 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 11 lines aren’t shown here.
This diff is large: its 228 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 205 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 6 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 12 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 76 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 125 lines aren’t shown here.
This diff is large: its 55 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 9 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 22 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 23 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 19 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 9 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 9 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 97 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 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 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 11 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 17 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 28 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 13 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 32 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 15 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 12 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 32 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 25 lines aren’t shown here.
This diff is large: its 151 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 48 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 54 lines aren’t shown here.
This diff is large: its 72 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 95 lines aren’t shown here.
This diff is large: its 110 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 10 lines aren’t shown here.
This diff is large: its 21 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 10 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 133 lines aren’t shown here.
This diff is large: its 119 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 30 lines aren’t shown here.
This diff is large: its 526 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 21 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 52 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 178 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 156 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 112 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 5 lines aren’t shown here.
This diff is large: its 15 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 19 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 15 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 5 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 43 lines aren’t shown here.
This diff is large: its 234 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 8 lines aren’t shown here.
This diff is large: its 176 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 451 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 12 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 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 39 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 83 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 115 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 18 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 153 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 77 lines aren’t shown here.
This diff is large: its 43 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 77 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 15 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 171 lines aren’t shown here.
This diff is large: its 49 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 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 8 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 220 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 56 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 18 lines aren’t shown here.
This diff is large: its 39 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 27 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 5 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 13 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 29 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 60 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 18 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 405 lines aren’t shown here.
This diff is large: its 250 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 356 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 232 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 26 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 15 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 26 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 265 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 429 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 139 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 338 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 214 lines aren’t shown here.
This diff is large: its 196 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 333 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 352 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 46 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 1028 lines aren’t shown here.
This diff is large: its 168 lines aren’t shown here.
This diff is large: its 223 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 1219 lines aren’t shown here.
This diff is large: its 124 lines aren’t shown here.
This diff is large: its 106 lines aren’t shown here.
This diff is large: its 1292 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 1100 lines aren’t shown here.
This diff is large: its 27 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 49 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 36 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 29 lines aren’t shown here.
This diff is large: its 396 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 21 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 18 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 17 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 82 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 83 lines aren’t shown here.
This diff is large: its 121 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 201 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 113 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 48 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 45 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 23 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 68 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 28 lines aren’t shown here.
This diff is large: its 116 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 153 lines aren’t shown here.
This diff is large: its 135 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 974 lines aren’t shown here.
This diff is large: its 336 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 10 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 63 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 8 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 183 lines aren’t shown here.
This diff is large: its 20 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 8 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 129 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 24 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 51 lines aren’t shown here.
This diff is large: its 51 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 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 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 187 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 125 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 366 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 9 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 73 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 18 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 17 lines aren’t shown here.
This diff is large: its 117 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 56 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 218 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 364 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 346 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 165 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 356 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 32 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 16 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 6 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 5 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 24 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 51 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 10 lines aren’t shown here.
This diff is large: its 129 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 68 lines aren’t shown here.
This diff is large: its 33 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 5 lines aren’t shown here.
This diff is large: its 11 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 14 lines aren’t shown here.
This diff is large: its 113 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 102 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 30 lines aren’t shown here.
This diff is large: its 8 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 73 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 89 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 9 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 48 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 117 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 183 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 183 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 139 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 146 lines aren’t shown here.
This diff is large: its 171 lines aren’t shown here.
This diff is large: its 146 lines aren’t shown here.
This diff is large: its 64 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 44 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 58 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 83 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 8 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 17 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 27 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 5 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 18 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 9 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 33 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 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 20 lines aren’t shown here.
This diff is large: its 170 lines aren’t shown here.
This diff is large: its 37 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 32 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 71 lines aren’t shown here.
This diff is large: its 349 lines aren’t shown here.
This diff is large: its 212 lines aren’t shown here.
This diff is large: its 23 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 39 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 75 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 322 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 286 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 15 lines aren’t shown here.
This diff is large: its 120 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 66 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 388 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 63 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 17 lines aren’t shown here.
This diff is large: its 25 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 9 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 62 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 83 lines aren’t shown here.
This diff is large: its 13 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 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 15 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 9 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 16 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 10 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 24 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 19 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 33 lines aren’t shown here.
This diff is large: its 117 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 9 lines aren’t shown here.
This diff is large: its 19 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 13 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 334 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 20 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 286 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 9 lines aren’t shown here.
This diff is large: its 367 lines aren’t shown here.
This diff is large: its 40 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 29 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 61 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 21 lines aren’t shown here.
This diff is large: its 391 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 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 13 lines aren’t shown here.
This diff is large: its 6 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 26 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 150 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 31 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 58 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 18 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 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 14 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 8 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 105 lines aren’t shown here.
This diff is large: its 208 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 1012 lines aren’t shown here.
This diff is large: its 135 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 288 lines aren’t shown here.
This diff is large: its 305 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 210 lines aren’t shown here.
This diff is large: its 493 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 1014 lines aren’t shown here.
This diff is large: its 135 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 305 lines aren’t shown here.
This diff is large: its 308 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 215 lines aren’t shown here.
This diff is large: its 599 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 1048 lines aren’t shown here.
This diff is large: its 129 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 282 lines aren’t shown here.
This diff is large: its 298 lines aren’t shown here.
This diff is large: its 225 lines aren’t shown here.
This diff is large: its 532 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 231 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 314 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 70 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 99 lines aren’t shown here.
This diff is large: its 566 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 12 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 156 lines aren’t shown here.
This diff is large: its 32 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 7 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 89 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 31 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 84 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 122 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 17 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 102 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 8 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 18 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 20 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 60 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 117 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 178 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 15 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 8 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 43 lines aren’t shown here.
This diff is large: its 932 lines aren’t shown here.
This diff is large: its 303 lines aren’t shown here.
This diff is large: its 27 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 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 9 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 127 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 134 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 27 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 31 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 116 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 7 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 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 36 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 27 lines aren’t shown here.
This diff is large: its 96 lines aren’t shown here.
This diff is large: its 30 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 19 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 83 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 115 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 180 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 409 lines aren’t shown here.
This diff is large: its 47 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 532 lines aren’t shown here.
This diff is large: its 340 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 10 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 53 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 24 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 26 lines aren’t shown here.
This diff is large: its 82 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 71 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 9 lines aren’t shown here.
This diff is large: its 93 lines aren’t shown here.
This diff is large: its 66 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 16 lines aren’t shown here.
This diff is large: its 107 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 34 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 448 lines aren’t shown here.
This diff is large: its 125 lines aren’t shown here.
This diff is large: its 138 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 242 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 41 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 40 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 365 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 21 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 121 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 412 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 1019 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 139 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 3612 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 683 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 117 lines aren’t shown here.
This diff is large: its 21 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 154 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 61 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 205 lines aren’t shown here.
This diff is large: its 800 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 8 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 88 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 8 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 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 28 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 880 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 7 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 314 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 21 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 29 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 124 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 295 lines aren’t shown here.
This diff is large: its 17 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 6 lines aren’t shown here.
This diff is large: its 249 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 242 lines aren’t shown here.
This diff is large: its 76 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 19 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 23 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 80 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 8 lines aren’t shown here.
This diff is large: its 206 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 245 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 18 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 30 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 9 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 11 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 11 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 59 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 22 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 9 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 64 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 497 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 106 lines aren’t shown here.
This diff is large: its 397 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 376 lines aren’t shown here.
This diff is large: its 123 lines aren’t shown here.
This diff is large: its 210 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 124 lines aren’t shown here.
This diff is large: its 363 lines aren’t shown here.
This diff is large: its 217 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 20 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 454 lines aren’t shown here.
This diff is large: its 138 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 766 lines aren’t shown here.
This diff is large: its 143 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 9 lines aren’t shown here.
This diff is large: its 52 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 44 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 43 lines aren’t shown here.
This diff is large: its 989 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 64 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 185 lines aren’t shown here.
This diff is large: its 226 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 6 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 30 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 485 lines aren’t shown here.
This diff is large: its 12 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 428 lines aren’t shown here.
This diff is large: its 676 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 226 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 308 lines aren’t shown here.
This diff is large: its 69 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 911 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 338 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 193 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 255 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 24 lines aren’t shown here.
This diff is large: its 215 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 37 lines aren’t shown here.
This diff is large: its 11 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 31 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 470 lines aren’t shown here.
This diff is large: its 361 lines aren’t shown here.
This diff is large: its 38 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 30 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 9 lines aren’t shown here.
This diff is large: its 537 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 57 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 46 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 20 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 171 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 25 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 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 783 lines aren’t shown here.
This diff is large: its 50 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 36 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 117 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 36 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 748 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 138 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 61 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 33 lines aren’t shown here.
This diff is large: its 60 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 68 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 34 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 31 lines aren’t shown here.
This diff is large: its 162 lines aren’t shown here.
This diff is large: its 7230 lines aren’t shown here.
This diff is large: its 4415 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 423 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 141 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 491 lines aren’t shown here.
This diff is large: its 43 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 36 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 141 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 134 lines aren’t shown here.
This diff is large: its 181 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 47 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 239 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 169 lines aren’t shown here.
This diff is large: its 185 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 187 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 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 110 lines aren’t shown here.
This diff is large: its 146 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 178 lines aren’t shown here.
This diff is large: its 346 lines aren’t shown here.
This diff is large: its 363 lines aren’t shown here.
This diff is large: its 108 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 183 lines aren’t shown here.
This diff is large: its 135 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 33 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 28 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 23 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 166 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 83 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 242 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 58 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 13 lines aren’t shown here.
This diff is large: its 172 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 190 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 199 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 123 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 96 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 610 lines aren’t shown here.
This diff is large: its 212 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 10 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 236 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 11 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 15 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 8 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 114 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 495 lines aren’t shown here.
This diff is large: its 172 lines aren’t shown here.
This diff is large: its 310 lines aren’t shown here.
This diff is large: its 157 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 172 lines aren’t shown here.
This diff is large: its 129 lines aren’t shown here.
This diff is large: its 106 lines aren’t shown here.
This diff is large: its 234 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 120 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 126 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 962 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 176 lines aren’t shown here.
This diff is large: its 337 lines aren’t shown here.
This diff is large: its 265 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 96 lines aren’t shown here.
This diff is large: its 39 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 8 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 31 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 11 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 76 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 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 29 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 25 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 1017 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 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 8 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 226 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 12 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 552 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 274 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 724 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 427 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 23 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 104 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 1746 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 245 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 127 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 213 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 207 lines aren’t shown here.
This diff is large: its 201 lines aren’t shown here.
This diff is large: its 2745 lines aren’t shown here.
This diff is large: its 2481 lines aren’t shown here.
This diff is large: its 484 lines aren’t shown here.
This diff is large: its 97 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 398 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 24 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 25 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 218 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 324 lines aren’t shown here.
This diff is large: its 287 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 116 lines aren’t shown here.
This diff is large: its 116 lines aren’t shown here.
This diff is large: its 114 lines aren’t shown here.
This diff is large: its 146 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 56 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 14 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 374 lines aren’t shown here.
This diff is large: its 104 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 48 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 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 310 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 120 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 71 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 94 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 56 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 18 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 66 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 14 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 55 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 34 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 219 lines aren’t shown here.
This diff is large: its 310 lines aren’t shown here.
This diff is large: its 226 lines aren’t shown here.
This diff is large: its 322 lines aren’t shown here.
This diff is large: its 824 lines aren’t shown here.
This diff is large: its 779 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 119 lines aren’t shown here.
This diff is large: its 144 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 131 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 15 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 58 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 5 lines aren’t shown here.
This diff is large: its 145 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 717 lines aren’t shown here.
This diff is large: its 218 lines aren’t shown here.
This diff is large: its 336 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 62 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 28 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 37 lines aren’t shown here.
This diff is large: its 232 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.
File renamed without changes.
This diff is large: its 9 lines aren’t shown here.
File renamed without changes.
File renamed without changes.
This diff is large: its 155 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 174 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
File renamed without changes.
File renamed without changes.
File renamed without changes.
This diff is large: its 9 lines aren’t shown here.
File renamed without changes.
File renamed without changes.
File renamed without changes.
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 10 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 101 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 larger than a page shows: the files after these aren’t listed. Clone the repository to see all of it.