Backmerging required to pull topic/phy-compliance.
Unified · Split
| @@ -86,6 +86,8 @@ ForEachMacros: · 85 unmodified lines | ||
| 86 | 86 | - 'bio_for_each_segment_all' |
| 87 | 87 | - 'bio_list_for_each' |
| 88 | 88 | - 'bip_for_each_vec' |
| 89 | + - 'bitmap_for_each_clear_region' | |
| 90 | + - 'bitmap_for_each_set_region' | |
| 89 | 91 | - 'blkg_for_each_descendant_post' |
| 90 | 92 | - 'blkg_for_each_descendant_pre' |
| 91 | 93 | - 'blk_queue_for_each_rl' |
| @@ -115,6 +117,7 @@ ForEachMacros: · 23 unmodified lines | ||
| 115 | 117 | - 'drm_client_for_each_connector_iter' |
| 116 | 118 | - 'drm_client_for_each_modeset' |
| 117 | 119 | - 'drm_connector_for_each_possible_encoder' |
| 120 | + - 'drm_for_each_bridge_in_chain' | |
| 118 | 121 | - 'drm_for_each_connector_iter' |
| 119 | 122 | - 'drm_for_each_crtc' |
| 120 | 123 | - 'drm_for_each_encoder' |
| @@ -136,9 +139,10 @@ ForEachMacros: · 15 unmodified lines | ||
| 136 | 139 | - 'for_each_bio' |
| 137 | 140 | - 'for_each_board_func_rsrc' |
| 138 | 141 | - 'for_each_bvec' |
| 142 | + - 'for_each_card_auxs' | |
| 143 | + - 'for_each_card_auxs_safe' | |
| 139 | 144 | - 'for_each_card_components' |
| 140 | − - 'for_each_card_links' | |
| 141 | − - 'for_each_card_links_safe' | |
| 145 | + - 'for_each_card_pre_auxs' | |
| 142 | 146 | - 'for_each_card_prelinks' |
| 143 | 147 | - 'for_each_card_rtds' |
| 144 | 148 | - 'for_each_card_rtds_safe' |
| @@ -166,6 +170,7 @@ ForEachMacros: · 21 unmodified lines | ||
| 166 | 170 | - 'for_each_dpcm_fe' |
| 167 | 171 | - 'for_each_drhd_unit' |
| 168 | 172 | - 'for_each_dss_dev' |
| 173 | + - 'for_each_efi_handle' | |
| 169 | 174 | - 'for_each_efi_memory_desc' |
| 170 | 175 | - 'for_each_efi_memory_desc_in_map' |
| 171 | 176 | - 'for_each_element' |
| @@ -190,6 +195,7 @@ ForEachMacros: · 18 unmodified lines | ||
| 190 | 195 | - 'for_each_lru' |
| 191 | 196 | - 'for_each_matching_node' |
| 192 | 197 | - 'for_each_matching_node_and_match' |
| 198 | + - 'for_each_member' | |
| 193 | 199 | - 'for_each_memblock' |
| 194 | 200 | - 'for_each_memblock_type' |
| 195 | 201 | - 'for_each_memcg_cache_index' |
| @@ -200,9 +206,11 @@ ForEachMacros: · 4 unmodified lines | ||
| 200 | 206 | - 'for_each_msi_entry' |
| 201 | 207 | - 'for_each_msi_entry_safe' |
| 202 | 208 | - 'for_each_net' |
| 209 | + - 'for_each_net_continue_reverse' | |
| 203 | 210 | - 'for_each_netdev' |
| 204 | 211 | - 'for_each_netdev_continue' |
| 205 | 212 | - 'for_each_netdev_continue_rcu' |
| 213 | + - 'for_each_netdev_continue_reverse' | |
| 206 | 214 | - 'for_each_netdev_feature' |
| 207 | 215 | - 'for_each_netdev_in_bond_rcu' |
| 208 | 216 | - 'for_each_netdev_rcu' |
| @@ -254,10 +262,10 @@ ForEachMacros: · 45 unmodified lines | ||
| 254 | 262 | - 'for_each_reserved_mem_region' |
| 255 | 263 | - 'for_each_rtd_codec_dai' |
| 256 | 264 | - 'for_each_rtd_codec_dai_rollback' |
| 257 | − - 'for_each_rtdcom' | |
| 258 | − - 'for_each_rtdcom_safe' | |
| 265 | + - 'for_each_rtd_components' | |
| 259 | 266 | - 'for_each_set_bit' |
| 260 | 267 | - 'for_each_set_bit_from' |
| 268 | + - 'for_each_set_clump8' | |
| 261 | 269 | - 'for_each_sg' |
| 262 | 270 | - 'for_each_sg_dma_page' |
| 263 | 271 | - 'for_each_sg_page' |
| @@ -267,6 +275,7 @@ ForEachMacros: · 3 unmodified lines | ||
| 267 | 275 | - 'for_each_subelement_id' |
| 268 | 276 | - '__for_each_thread' |
| 269 | 277 | - 'for_each_thread' |
| 278 | + - 'for_each_wakeup_source' | |
| 270 | 279 | - 'for_each_zone' |
| 271 | 280 | - 'for_each_zone_zonelist' |
| 272 | 281 | - 'for_each_zone_zonelist_nodemask' |
| @@ -330,6 +339,7 @@ ForEachMacros: · 57 unmodified lines | ||
| 330 | 339 | - 'list_for_each' |
| 331 | 340 | - 'list_for_each_codec' |
| 332 | 341 | - 'list_for_each_codec_safe' |
| 342 | + - 'list_for_each_continue' | |
| 333 | 343 | - 'list_for_each_entry' |
| 334 | 344 | - 'list_for_each_entry_continue' |
| 335 | 345 | - 'list_for_each_entry_continue_rcu' |
| @@ -351,6 +361,7 @@ ForEachMacros: · 15 unmodified lines | ||
| 351 | 361 | - 'llist_for_each_entry' |
| 352 | 362 | - 'llist_for_each_entry_safe' |
| 353 | 363 | - 'llist_for_each_safe' |
| 364 | + - 'mci_for_each_dimm' | |
| 354 | 365 | - 'media_device_for_each_entity' |
| 355 | 366 | - 'media_device_for_each_intf' |
| 356 | 367 | - 'media_device_for_each_link' |
| @@ -444,10 +455,16 @@ ForEachMacros: · 87 unmodified lines | ||
| 444 | 455 | - 'virtio_device_for_each_vq' |
| 445 | 456 | - 'xa_for_each' |
| 446 | 457 | - 'xa_for_each_marked' |
| 458 | + - 'xa_for_each_range' | |
| 447 | 459 | - 'xa_for_each_start' |
| 448 | 460 | - 'xas_for_each' |
| 449 | 461 | - 'xas_for_each_conflict' |
| 450 | 462 | - 'xas_for_each_marked' |
| 463 | + - 'xbc_array_for_each_value' | |
| 464 | + - 'xbc_for_each_key_value' | |
| 465 | + - 'xbc_node_for_each_array_value' | |
| 466 | + - 'xbc_node_for_each_child' | |
| 467 | + - 'xbc_node_for_each_key_value' | |
| 451 | 468 | - 'zorro_for_each_dev' |
| 452 | 469 | |
| 453 | 470 | #IncludeBlocks: Preserve # Unknown to clang-format-5.0 |
| @@ -1,3 +1,4 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0-only | |
| 1 | 2 | # |
| 2 | 3 | # NOTE! Don't add files that are generated in specific |
| 3 | 4 | # subdirectories here. Add them in the ".gitignore" file |
| @@ -210,6 +210,7 @@ Oleksij Rempel <linux@rempel-privat.de> <external.Oleksij.Rempel@de.bosch.com> · 209 unmodified lines | ||
| 210 | 210 | Oleksij Rempel <linux@rempel-privat.de> <fixed-term.Oleksij.Rempel@de.bosch.com> |
| 211 | 211 | Oleksij Rempel <linux@rempel-privat.de> <o.rempel@pengutronix.de> |
| 212 | 212 | Oleksij Rempel <linux@rempel-privat.de> <ore@pengutronix.de> |
| 213 | +Pali Rohár <pali@kernel.org> <pali.rohar@gmail.com> | |
| 213 | 214 | Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> |
| 214 | 215 | Patrick Mochel <mochel@digitalimplant.org> |
| 215 | 216 | Paul Burton <paulburton@kernel.org> <paul.burton@imgtec.com> |
| @@ -225,6 +226,7 @@ Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com> · 9 unmodified lines | ||
| 225 | 226 | Praveen BP <praveenbp@ti.com> |
| 226 | 227 | Punit Agrawal <punitagrawal@gmail.com> <punit.agrawal@arm.com> |
| 227 | 228 | Qais Yousef <qsyousef@gmail.com> <qais.yousef@imgtec.com> |
| 229 | +Quentin Monnet <quentin@isovalent.com> <quentin.monnet@netronome.com> | |
| 228 | 230 | Quentin Perret <qperret@qperret.net> <quentin.perret@arm.com> |
| 229 | 231 | Rafael J. Wysocki <rjw@rjwysocki.net> <rjw@sisk.pl> |
| 230 | 232 | Rajesh Shah <rajesh.shah@intel.com> |
| @@ -243,9 +245,11 @@ Santosh Shilimkar <ssantosh@kernel.org> · 12 unmodified lines | ||
| 243 | 245 | Santosh Shilimkar <santosh.shilimkar@oracle.org> |
| 244 | 246 | Sascha Hauer <s.hauer@pengutronix.de> |
| 245 | 247 | S.Çağlar Onur <caglar@pardus.org.tr> |
| 248 | +Sakari Ailus <sakari.ailus@linux.intel.com> <sakari.ailus@iki.fi> | |
| 246 | 249 | Sean Nyekjaer <sean@geanix.com> <sean.nyekjaer@prevas.dk> |
| 247 | 250 | Sebastian Reichel <sre@kernel.org> <sre@debian.org> |
| 248 | 251 | Sebastian Reichel <sre@kernel.org> <sebastian.reichel@collabora.co.uk> |
| 252 | +Sedat Dilek <sedat.dilek@gmail.com> <sedat.dilek@credativ.de> | |
| 249 | 253 | Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com> |
| 250 | 254 | Shuah Khan <shuah@kernel.org> <shuahkhan@gmail.com> |
| 251 | 255 | Shuah Khan <shuah@kernel.org> <shuah.khan@hp.com> |
| @@ -1,2 +1,3 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0-only | |
| 1 | 2 | output |
| 2 | 3 | *.pyc |
| @@ -0,0 +1,9 @@ | ||
| 1 | +This ABI is renamed and moved to a new location /sys/kernel/fadump/enabled. | |
| 2 | + | |
| 3 | +What: /sys/kernel/fadump_enabled | |
| 4 | +Date: Feb 2012 | |
| 5 | +Contact: linuxppc-dev@lists.ozlabs.org | |
| 6 | +Description: read only | |
| 7 | + Primarily used to identify whether the FADump is enabled in | |
| 8 | + the kernel or not. | |
| 9 | +User: Kdump service | |
| @@ -0,0 +1,10 @@ | ||
| 1 | +This ABI is renamed and moved to a new location /sys/kernel/fadump/registered.¬ | |
| 2 | + | |
| 3 | +What: /sys/kernel/fadump_registered | |
| 4 | +Date: Feb 2012 | |
| 5 | +Contact: linuxppc-dev@lists.ozlabs.org | |
| 6 | +Description: read/write | |
| 7 | + Helps to control the dump collect feature from userspace. | |
| 8 | + Setting 1 to this file enables the system to collect the | |
| 9 | + dump and 0 to disable it. | |
| 10 | +User: Kdump service | |
| @@ -0,0 +1,10 @@ | ||
| 1 | +This ABI is renamed and moved to a new location /sys/kernel/fadump/release_mem.¬ | |
| 2 | + | |
| 3 | +What: /sys/kernel/fadump_release_mem | |
| 4 | +Date: Feb 2012 | |
| 5 | +Contact: linuxppc-dev@lists.ozlabs.org | |
| 6 | +Description: write only | |
| 7 | + This is a special sysfs file and only available when | |
| 8 | + the system is booted to capture the vmcore using FADump. | |
| 9 | + It is used to release the memory reserved by FADump to | |
| 10 | + save the crash dump. | |
| @@ -0,0 +1,23 @@ | ||
| 1 | +What: /sys/fs/selinux/checkreqprot | |
| 2 | +Date: April 2005 (predates git) | |
| 3 | +KernelVersion: 2.6.12-rc2 (predates git) | |
| 4 | +Contact: selinux@vger.kernel.org | |
| 5 | +Description: | |
| 6 | + | |
| 7 | + The selinuxfs "checkreqprot" node allows SELinux to be configured | |
| 8 | + to check the protection requested by userspace for mmap/mprotect | |
| 9 | + calls instead of the actual protection applied by the kernel. | |
| 10 | + This was a compatibility mechanism for legacy userspace and | |
| 11 | + for the READ_IMPLIES_EXEC personality flag. However, if set to | |
| 12 | + 1, it weakens security by allowing mappings to be made executable | |
| 13 | + without authorization by policy. The default value of checkreqprot | |
| 14 | + at boot was changed starting in Linux v4.4 to 0 (i.e. check the | |
| 15 | + actual protection), and Android and Linux distributions have been | |
| 16 | + explicitly writing a "0" to /sys/fs/selinux/checkreqprot during | |
| 17 | + initialization for some time. Support for setting checkreqprot to 1 | |
| 18 | + will be removed in a future kernel release, at which point the kernel | |
| 19 | + will always cease using checkreqprot internally and will always | |
| 20 | + check the actual protections being applied upon mmap/mprotect calls. | |
| 21 | + The checkreqprot selinuxfs node will remain for backward compatibility | |
| 22 | + but will discard writes of the "0" value and will reject writes of the | |
| 23 | + "1" value when this mechanism is removed. | |
| @@ -0,0 +1,9 @@ | ||
| 1 | +This ABI is moved to /sys/firmware/opal/mpipl/release_core. | |
| 2 | + | |
| 3 | +What: /sys/kernel/fadump_release_opalcore | |
| 4 | +Date: Sep 2019 | |
| 5 | +Contact: linuxppc-dev@lists.ozlabs.org | |
| 6 | +Description: write only | |
| 7 | + The sysfs file is available when the system is booted to | |
| 8 | + collect the dump on OPAL based machine. It used to release | |
| 9 | + the memory used to collect the opalcore. | |
| @@ -1,5 +1,5 @@ | ||
| 1 | 1 | What: /sys/kernel/uids/<uid>/cpu_shares |
| 2 | −Date: December 2007 | |
| 2 | +Date: December 2007, finally removed in kernel v2.6.34-rc1 | |
| 3 | 3 | Contact: Dhaval Giani <dhaval@linux.vnet.ibm.com> |
| 4 | 4 | Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> |
| 5 | 5 | Description: |
| @@ -194,11 +194,3 @@ Description: · 193 unmodified lines | ||
| 194 | 194 | |
| 195 | 195 | destroy_link write '1' to this attribute to destroy an |
| 196 | 196 | active link |
| 197 | − | |
| 198 | −What: /sys/kernel/config/rdma_cm/<hca>/ports/<port-num>/default_roce_tos | |
| 199 | −Date: March 8, 2019 | |
| 200 | −KernelVersion: 5.2 | |
| 201 | −Description: RDMA-CM QPs from HCA <hca> at port <port-num> | |
| 202 | − will be created with this TOS as default. | |
| 203 | − This can be overridden by using the rdma_set_option API. | |
| 204 | − The possible RoCE TOS values are 0-255. | |
| @@ -43,6 +43,20 @@ Description: Allows the root user to read or write directly through the · 42 unmodified lines | ||
| 43 | 43 | If the IOMMU is disabled, it also allows the root user to read |
| 44 | 44 | or write from the host a device VA of a host mapped memory |
| 45 | 45 | |
| 46 | +What: /sys/kernel/debug/habanalabs/hl<n>/data64 | |
| 47 | +Date: Jan 2020 | |
| 48 | +KernelVersion: 5.6 | |
| 49 | +Contact: oded.gabbay@gmail.com | |
| 50 | +Description: Allows the root user to read or write 64 bit data directly | |
| 51 | + through the device's PCI bar. Writing to this file generates a | |
| 52 | + write transaction while reading from the file generates a read | |
| 53 | + transaction. This custom interface is needed (instead of using | |
| 54 | + the generic Linux user-space PCI mapping) because the DDR bar | |
| 55 | + is very small compared to the DDR memory and only the driver can | |
| 56 | + move the bar before and after the transaction. | |
| 57 | + If the IOMMU is disabled, it also allows the root user to read | |
| 58 | + or write from the host a device VA of a host mapped memory | |
| 59 | + | |
| 46 | 60 | What: /sys/kernel/debug/habanalabs/hl<n>/device |
| 47 | 61 | Date: Jan 2019 |
| 48 | 62 | KernelVersion: 5.1 |
| @@ -0,0 +1,241 @@ | ||
| 1 | +What: /sys/bus/coresight/devices/<cti-name>/enable | |
| 2 | +Date: March 2020 | |
| 3 | +KernelVersion 5.7 | |
| 4 | +Contact: Mike Leach or Mathieu Poirier | |
| 5 | +Description: (RW) Enable/Disable the CTI hardware. | |
| 6 | + | |
| 7 | +What: /sys/bus/coresight/devices/<cti-name>/powered | |
| 8 | +Date: March 2020 | |
| 9 | +KernelVersion 5.7 | |
| 10 | +Contact: Mike Leach or Mathieu Poirier | |
| 11 | +Description: (R) Indicate if the CTI hardware is powered. | |
| 12 | + | |
| 13 | +What: /sys/bus/coresight/devices/<cti-name>/ctmid | |
| 14 | +Date: March 2020 | |
| 15 | +KernelVersion 5.7 | |
| 16 | +Contact: Mike Leach or Mathieu Poirier | |
| 17 | +Description: (R) Display the associated CTM ID | |
| 18 | + | |
| 19 | +What: /sys/bus/coresight/devices/<cti-name>/nr_trigger_cons | |
| 20 | +Date: March 2020 | |
| 21 | +KernelVersion 5.7 | |
| 22 | +Contact: Mike Leach or Mathieu Poirier | |
| 23 | +Description: (R) Number of devices connected to triggers on this CTI | |
| 24 | + | |
| 25 | +What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/name | |
| 26 | +Date: March 2020 | |
| 27 | +KernelVersion 5.7 | |
| 28 | +Contact: Mike Leach or Mathieu Poirier | |
| 29 | +Description: (R) Name of connected device <N> | |
| 30 | + | |
| 31 | +What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/in_signals | |
| 32 | +Date: March 2020 | |
| 33 | +KernelVersion 5.7 | |
| 34 | +Contact: Mike Leach or Mathieu Poirier | |
| 35 | +Description: (R) Input trigger signals from connected device <N> | |
| 36 | + | |
| 37 | +What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/in_types | |
| 38 | +Date: March 2020 | |
| 39 | +KernelVersion 5.7 | |
| 40 | +Contact: Mike Leach or Mathieu Poirier | |
| 41 | +Description: (R) Functional types for the input trigger signals | |
| 42 | + from connected device <N> | |
| 43 | + | |
| 44 | +What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/out_signals | |
| 45 | +Date: March 2020 | |
| 46 | +KernelVersion 5.7 | |
| 47 | +Contact: Mike Leach or Mathieu Poirier | |
| 48 | +Description: (R) Output trigger signals to connected device <N> | |
| 49 | + | |
| 50 | +What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/out_types | |
| 51 | +Date: March 2020 | |
| 52 | +KernelVersion 5.7 | |
| 53 | +Contact: Mike Leach or Mathieu Poirier | |
| 54 | +Description: (R) Functional types for the output trigger signals | |
| 55 | + to connected device <N> | |
| 56 | + | |
| 57 | +What: /sys/bus/coresight/devices/<cti-name>/regs/inout_sel | |
| 58 | +Date: March 2020 | |
| 59 | +KernelVersion 5.7 | |
| 60 | +Contact: Mike Leach or Mathieu Poirier | |
| 61 | +Description: (RW) Select the index for inen and outen registers. | |
| 62 | + | |
| 63 | +What: /sys/bus/coresight/devices/<cti-name>/regs/inen | |
| 64 | +Date: March 2020 | |
| 65 | +KernelVersion 5.7 | |
| 66 | +Contact: Mike Leach or Mathieu Poirier | |
| 67 | +Description: (RW) Read or write the CTIINEN register selected by inout_sel. | |
| 68 | + | |
| 69 | +What: /sys/bus/coresight/devices/<cti-name>/regs/outen | |
| 70 | +Date: March 2020 | |
| 71 | +KernelVersion 5.7 | |
| 72 | +Contact: Mike Leach or Mathieu Poirier | |
| 73 | +Description: (RW) Read or write the CTIOUTEN register selected by inout_sel. | |
| 74 | + | |
| 75 | +What: /sys/bus/coresight/devices/<cti-name>/regs/gate | |
| 76 | +Date: March 2020 | |
| 77 | +KernelVersion 5.7 | |
| 78 | +Contact: Mike Leach or Mathieu Poirier | |
| 79 | +Description: (RW) Read or write CTIGATE register. | |
| 80 | + | |
| 81 | +What: /sys/bus/coresight/devices/<cti-name>/regs/asicctl | |
| 82 | +Date: March 2020 | |
| 83 | +KernelVersion 5.7 | |
| 84 | +Contact: Mike Leach or Mathieu Poirier | |
| 85 | +Description: (RW) Read or write ASICCTL register. | |
| 86 | + | |
| 87 | +What: /sys/bus/coresight/devices/<cti-name>/regs/intack | |
| 88 | +Date: March 2020 | |
| 89 | +KernelVersion 5.7 | |
| 90 | +Contact: Mike Leach or Mathieu Poirier | |
| 91 | +Description: (W) Write the INTACK register. | |
| 92 | + | |
| 93 | +What: /sys/bus/coresight/devices/<cti-name>/regs/appset | |
| 94 | +Date: March 2020 | |
| 95 | +KernelVersion 5.7 | |
| 96 | +Contact: Mike Leach or Mathieu Poirier | |
| 97 | +Description: (RW) Set CTIAPPSET register to activate channel. Read back to | |
| 98 | + determine current value of register. | |
| 99 | + | |
| 100 | +What: /sys/bus/coresight/devices/<cti-name>/regs/appclear | |
| 101 | +Date: March 2020 | |
| 102 | +KernelVersion 5.7 | |
| 103 | +Contact: Mike Leach or Mathieu Poirier | |
| 104 | +Description: (W) Write APPCLEAR register to deactivate channel. | |
| 105 | + | |
| 106 | +What: /sys/bus/coresight/devices/<cti-name>/regs/apppulse | |
| 107 | +Date: March 2020 | |
| 108 | +KernelVersion 5.7 | |
| 109 | +Contact: Mike Leach or Mathieu Poirier | |
| 110 | +Description: (W) Write APPPULSE to pulse a channel active for one clock | |
| 111 | + cycle. | |
| 112 | + | |
| 113 | +What: /sys/bus/coresight/devices/<cti-name>/regs/chinstatus | |
| 114 | +Date: March 2020 | |
| 115 | +KernelVersion 5.7 | |
| 116 | +Contact: Mike Leach or Mathieu Poirier | |
| 117 | +Description: (R) Read current status of channel inputs. | |
| 118 | + | |
| 119 | +What: /sys/bus/coresight/devices/<cti-name>/regs/choutstatus | |
| 120 | +Date: March 2020 | |
| 121 | +KernelVersion 5.7 | |
| 122 | +Contact: Mike Leach or Mathieu Poirier | |
| 123 | +Description: (R) read current status of channel outputs. | |
| 124 | + | |
| 125 | +What: /sys/bus/coresight/devices/<cti-name>/regs/triginstatus | |
| 126 | +Date: March 2020 | |
| 127 | +KernelVersion 5.7 | |
| 128 | +Contact: Mike Leach or Mathieu Poirier | |
| 129 | +Description: (R) read current status of input trigger signals | |
| 130 | + | |
| 131 | +What: /sys/bus/coresight/devices/<cti-name>/regs/trigoutstatus | |
| 132 | +Date: March 2020 | |
| 133 | +KernelVersion 5.7 | |
| 134 | +Contact: Mike Leach or Mathieu Poirier | |
| 135 | +Description: (R) read current status of output trigger signals. | |
| 136 | + | |
| 137 | +What: /sys/bus/coresight/devices/<cti-name>/channels/trigin_attach | |
| 138 | +Date: March 2020 | |
| 139 | +KernelVersion 5.7 | |
| 140 | +Contact: Mike Leach or Mathieu Poirier | |
| 141 | +Description: (W) Attach a CTI input trigger to a CTM channel. | |
| 142 | + | |
| 143 | +What: /sys/bus/coresight/devices/<cti-name>/channels/trigin_detach | |
| 144 | +Date: March 2020 | |
| 145 | +KernelVersion 5.7 | |
| 146 | +Contact: Mike Leach or Mathieu Poirier | |
| 147 | +Description: (W) Detach a CTI input trigger from a CTM channel. | |
| 148 | + | |
| 149 | +What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_attach | |
| 150 | +Date: March 2020 | |
| 151 | +KernelVersion 5.7 | |
| 152 | +Contact: Mike Leach or Mathieu Poirier | |
| 153 | +Description: (W) Attach a CTI output trigger to a CTM channel. | |
| 154 | + | |
| 155 | +What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_detach | |
| 156 | +Date: March 2020 | |
| 157 | +KernelVersion 5.7 | |
| 158 | +Contact: Mike Leach or Mathieu Poirier | |
| 159 | +Description: (W) Detach a CTI output trigger from a CTM channel. | |
| 160 | + | |
| 161 | +What: /sys/bus/coresight/devices/<cti-name>/channels/chan_gate_enable | |
| 162 | +Date: March 2020 | |
| 163 | +KernelVersion 5.7 | |
| 164 | +Contact: Mike Leach or Mathieu Poirier | |
| 165 | +Description: (RW) Enable CTIGATE for single channel (W) or list enabled | |
| 166 | + channels through the gate (R). | |
| 167 | + | |
| 168 | +What: /sys/bus/coresight/devices/<cti-name>/channels/chan_gate_disable | |
| 169 | +Date: March 2020 | |
| 170 | +KernelVersion 5.7 | |
| 171 | +Contact: Mike Leach or Mathieu Poirier | |
| 172 | +Description: (W) Disable CTIGATE for single channel. | |
| 173 | + | |
| 174 | +What: /sys/bus/coresight/devices/<cti-name>/channels/chan_set | |
| 175 | +Date: March 2020 | |
| 176 | +KernelVersion 5.7 | |
| 177 | +Contact: Mike Leach or Mathieu Poirier | |
| 178 | +Description: (W) Activate a single channel. | |
| 179 | + | |
| 180 | +What: /sys/bus/coresight/devices/<cti-name>/channels/chan_clear | |
| 181 | +Date: March 2020 | |
| 182 | +KernelVersion 5.7 | |
| 183 | +Contact: Mike Leach or Mathieu Poirier | |
| 184 | +Description: (W) Deactivate a single channel. | |
| 185 | + | |
| 186 | +What: /sys/bus/coresight/devices/<cti-name>/channels/chan_pulse | |
| 187 | +Date: March 2020 | |
| 188 | +KernelVersion 5.7 | |
| 189 | +Contact: Mike Leach or Mathieu Poirier | |
| 190 | +Description: (W) Pulse a single channel - activate for a single clock cycle. | |
| 191 | + | |
| 192 | +What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_filtered | |
| 193 | +Date: March 2020 | |
| 194 | +KernelVersion 5.7 | |
| 195 | +Contact: Mike Leach or Mathieu Poirier | |
| 196 | +Description: (R) List of output triggers filtered across all connections. | |
| 197 | + | |
| 198 | +What: /sys/bus/coresight/devices/<cti-name>/channels/trig_filter_enable | |
| 199 | +Date: March 2020 | |
| 200 | +KernelVersion 5.7 | |
| 201 | +Contact: Mike Leach or Mathieu Poirier | |
| 202 | +Description: (RW) Enable or disable trigger output signal filtering. | |
| 203 | + | |
| 204 | +What: /sys/bus/coresight/devices/<cti-name>/channels/chan_inuse | |
| 205 | +Date: March 2020 | |
| 206 | +KernelVersion 5.7 | |
| 207 | +Contact: Mike Leach or Mathieu Poirier | |
| 208 | +Description: (R) show channels with at least one attached trigger signal. | |
| 209 | + | |
| 210 | +What: /sys/bus/coresight/devices/<cti-name>/channels/chan_free | |
| 211 | +Date: March 2020 | |
| 212 | +KernelVersion 5.7 | |
| 213 | +Contact: Mike Leach or Mathieu Poirier | |
| 214 | +Description: (R) show channels with no attached trigger signals. | |
| 215 | + | |
| 216 | +What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_sel | |
| 217 | +Date: March 2020 | |
| 218 | +KernelVersion 5.7 | |
| 219 | +Contact: Mike Leach or Mathieu Poirier | |
| 220 | +Description: (RW) Write channel number to select a channel to view, read to | |
| 221 | + see selected channel number. | |
| 222 | + | |
| 223 | +What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_in | |
| 224 | +Date: March 2020 | |
| 225 | +KernelVersion 5.7 | |
| 226 | +Contact: Mike Leach or Mathieu Poirier | |
| 227 | +Description: (R) Read to see input triggers connected to selected view | |
| 228 | + channel. | |
| 229 | + | |
| 230 | +What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_out | |
| 231 | +Date: March 2020 | |
| 232 | +KernelVersion 5.7 | |
| 233 | +Contact: Mike Leach or Mathieu Poirier | |
| 234 | +Description: (R) Read to see output triggers connected to selected view | |
| 235 | + channel. | |
| 236 | + | |
| 237 | +What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_reset | |
| 238 | +Date: March 2020 | |
| 239 | +KernelVersion 5.7 | |
| 240 | +Contact: Mike Leach or Mathieu Poirier | |
| 241 | +Description: (W) Clear all channel / trigger programming. | |
| @@ -1,3 +1,28 @@ | ||
| 1 | +What: /sys/bus/counter/devices/counterX/signalY/cable_fault | |
| 2 | +KernelVersion: 5.7 | |
| 3 | +Contact: linux-iio@vger.kernel.org | |
| 4 | +Description: | |
| 5 | + Read-only attribute that indicates whether a differential | |
| 6 | + encoder cable fault (not connected or loose wires) is detected | |
| 7 | + for the respective channel of Signal Y. Valid attribute values | |
| 8 | + are boolean. Detection must first be enabled via the | |
| 9 | + corresponding cable_fault_enable attribute. | |
| 10 | + | |
| 11 | +What: /sys/bus/counter/devices/counterX/signalY/cable_fault_enable | |
| 12 | +KernelVersion: 5.7 | |
| 13 | +Contact: linux-iio@vger.kernel.org | |
| 14 | +Description: | |
| 15 | + Whether detection of differential encoder cable faults for the | |
| 16 | + respective channel of Signal Y is enabled. Valid attribute | |
| 17 | + values are boolean. | |
| 18 | + | |
| 19 | +What: /sys/bus/counter/devices/counterX/signalY/filter_clock_prescaler | |
| 20 | +KernelVersion: 5.7 | |
| 21 | +Contact: linux-iio@vger.kernel.org | |
| 22 | +Description: | |
| 23 | + Filter clock factor for input Signal Y. This prescaler value | |
| 24 | + affects the inputs of both quadrature pair signals. | |
| 25 | + | |
| 1 | 26 | What: /sys/bus/counter/devices/counterX/signalY/index_polarity |
| 2 | 27 | KernelVersion: 5.2 |
| 3 | 28 | Contact: linux-iio@vger.kernel.org |
| @@ -2,17 +2,22 @@ What: /sys/bus/iio/devices/iio:deviceX/ac_excitation_en · 1 unmodified line | ||
| 2 | 2 | KernelVersion: |
| 3 | 3 | Contact: linux-iio@vger.kernel.org |
| 4 | 4 | Description: |
| 5 | − Reading gives the state of AC excitation. | |
| 6 | − Writing '1' enables AC excitation. | |
| 5 | + This attribute, if available, is used to enable the AC | |
| 6 | + excitation mode found on some converters. In ac excitation mode, | |
| 7 | + the polarity of the excitation voltage is reversed on | |
| 8 | + alternate cycles, to eliminate DC errors. | |
| 7 | 9 | |
| 8 | 10 | What: /sys/bus/iio/devices/iio:deviceX/bridge_switch_en |
| 9 | 11 | KernelVersion: |
| 10 | 12 | Contact: linux-iio@vger.kernel.org |
| 11 | 13 | Description: |
| 12 | − This bridge switch is used to disconnect it when there is a | |
| 13 | − need to minimize the system current consumption. | |
| 14 | − Reading gives the state of the bridge switch. | |
| 15 | − Writing '1' enables the bridge switch. | |
| 14 | + This attribute, if available, is used to close or open the | |
| 15 | + bridge power down switch found on some converters. | |
| 16 | + In bridge applications, such as strain gauges and load cells, | |
| 17 | + the bridge itself consumes the majority of the current in the | |
| 18 | + system. To minimize the current consumption of the system, | |
| 19 | + the bridge can be disconnected (when it is not being used | |
| 20 | + using the bridge_switch_en attribute. | |
| 16 | 21 | |
| 17 | 22 | What: /sys/bus/iio/devices/iio:deviceX/in_voltagex_sys_calibration |
| 18 | 23 | KernelVersion: |
| @@ -21,6 +26,13 @@ Description: · 2 unmodified lines | ||
| 21 | 26 | Initiates the system calibration procedure. This is done on a |
| 22 | 27 | single channel at a time. Write '1' to start the calibration. |
| 23 | 28 | |
| 29 | +What: /sys/bus/iio/devices/iio:deviceX/in_voltage2-voltage2_shorted_raw | |
| 30 | +KernelVersion: | |
| 31 | +Contact: linux-iio@vger.kernel.org | |
| 32 | +Description: | |
| 33 | + Measure voltage from AIN2 pin connected to AIN(+) | |
| 34 | + and AIN(-) shorted. | |
| 35 | + | |
| 24 | 36 | What: /sys/bus/iio/devices/iio:deviceX/in_voltagex_sys_calibration_mode_available |
| 25 | 37 | KernelVersion: |
| 26 | 38 | Contact: linux-iio@vger.kernel.org |
| @@ -40,3 +40,11 @@ Description: (RW) Trigger window switch for the MSC's buffer, in · 39 unmodified lines | ||
| 40 | 40 | triggering a window switch for the buffer. Returns an error in any |
| 41 | 41 | other operating mode or attempts to write something other than "1". |
| 42 | 42 | |
| 43 | +What: /sys/bus/intel_th/devices/<intel_th_id>-msc<msc-id>/stop_on_full | |
| 44 | +Date: March 2020 | |
| 45 | +KernelVersion: 5.7 | |
| 46 | +Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com> | |
| 47 | +Description: (RW) Configure whether trace stops when the last available window | |
| 48 | + becomes full (1/y/Y) or wraps around and continues until the next | |
| 49 | + window becomes available again (0/n/N). | |
| 50 | + | |
| @@ -5,7 +5,7 @@ Contact: Christian Gromm <christian.gromm@microchip.com> · 4 unmodified lines | ||
| 5 | 5 | Description: |
| 6 | 6 | Provides information about the interface type and the physical |
| 7 | 7 | location of the device. Hardware attached via USB, for instance, |
| 8 | − might return <usb_device 1-1.1:1.0> | |
| 8 | + might return <1-1.1:1.0> | |
| 9 | 9 | Users: |
| 10 | 10 | |
| 11 | 11 | What: /sys/bus/most/devices/.../interface |
| @@ -278,25 +278,7 @@ Description: · 266 unmodified lines | ||
| 278 | 278 | Indicates whether current channel ran out of buffers. |
| 279 | 279 | Users: |
| 280 | 280 | |
| 281 | −What: /sys/bus/most/drivers/mostcore/add_link | |
| 282 | −Date: March 2017 | |
| 283 | −KernelVersion: 4.15 | |
| 284 | −Contact: Christian Gromm <christian.gromm@microchip.com> | |
| 285 | −Description: | |
| 286 | − This is used to link a channel to a component of the | |
| 287 | − mostcore. A link created by writing to this file is | |
| 288 | − referred to as pipe. | |
| 289 | −Users: | |
| 290 | − | |
| 291 | −What: /sys/bus/most/drivers/mostcore/remove_link | |
| 292 | −Date: March 2017 | |
| 293 | −KernelVersion: 4.15 | |
| 294 | −Contact: Christian Gromm <christian.gromm@microchip.com> | |
| 295 | −Description: | |
| 296 | − This is used to unlink a channel from a component. | |
| 297 | −Users: | |
| 298 | − | |
| 299 | −What: /sys/bus/most/drivers/mostcore/components | |
| 281 | +What: /sys/bus/most/drivers/most_core/components | |
| 300 | 282 | Date: March 2017 |
| 301 | 283 | KernelVersion: 4.15 |
| 302 | 284 | Contact: Christian Gromm <christian.gromm@microchip.com> |
| @@ -304,7 +286,7 @@ Description: · 1 unmodified line | ||
| 304 | 286 | This is used to retrieve a list of registered components. |
| 305 | 287 | Users: |
| 306 | 288 | |
| 307 | −What: /sys/bus/most/drivers/mostcore/links | |
| 289 | +What: /sys/bus/most/drivers/most_core/links | |
| 308 | 290 | Date: March 2017 |
| 309 | 291 | KernelVersion: 4.15 |
| 310 | 292 | Contact: Christian Gromm <christian.gromm@microchip.com> |
| @@ -20,13 +20,13 @@ Date: April 2017 · 19 unmodified lines | ||
| 20 | 20 | Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> |
| 21 | 21 | Description: |
| 22 | 22 | The supported power roles. This attribute can be used to request |
| 23 | − power role swap on the port when the port supports USB Power | |
| 24 | − Delivery. Swapping is supported as synchronous operation, so | |
| 25 | − write(2) to the attribute will not return until the operation | |
| 26 | − has finished. The attribute is notified about role changes so | |
| 27 | − that poll(2) on the attribute wakes up. Change on the role will | |
| 28 | − also generate uevent KOBJ_CHANGE. The current role is show in | |
| 29 | − brackets, for example "[source] sink" when in source mode. | |
| 23 | + power role swap on the port. Swapping is supported as | |
| 24 | + synchronous operation, so write(2) to the attribute will not | |
| 25 | + return until the operation has finished. The attribute is | |
| 26 | + notified about role changes so that poll(2) on the attribute | |
| 27 | + wakes up. Change on the role will also generate uevent | |
| 28 | + KOBJ_CHANGE. The current role is show in brackets, for example | |
| 29 | + "[source] sink" when in source mode. | |
| 30 | 30 | |
| 31 | 31 | Valid values: source, sink |
| 32 | 32 | |
| @@ -108,6 +108,15 @@ Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> · 75 unmodified lines | ||
| 108 | 108 | Description: |
| 109 | 109 | Revision number of the supported USB Type-C specification. |
| 110 | 110 | |
| 111 | +What: /sys/class/typec/<port>/orientation | |
| 112 | +Date: February 2020 | |
| 113 | +Contact: Badhri Jagan Sridharan <badhri@google.com> | |
| 114 | +Description: | |
| 115 | + Indicates the active orientation of the Type-C connector. | |
| 116 | + Valid values: | |
| 117 | + - "normal": CC1 orientation | |
| 118 | + - "reverse": CC2 orientation | |
| 119 | + - "unknown": Orientation cannot be determined. | |
| 111 | 120 | |
| 112 | 121 | USB Type-C partner devices (eg. /sys/class/typec/port0-partner/) |
| 113 | 122 | |
| @@ -0,0 +1,16 @@ | ||
| 1 | +What: /sys/devices/*/<our-device>/nvmem | |
| 2 | +Date: December 2017 | |
| 3 | +Contact: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com> | |
| 4 | +Description: read-only access to the efuse on the Ingenic JZ4780 SoC | |
| 5 | + The SoC has a one time programmable 8K efuse that is | |
| 6 | + split into segments. The driver supports read only. | |
| 7 | + The segments are | |
| 8 | + 0x000 64 bit Random Number | |
| 9 | + 0x008 128 bit Ingenic Chip ID | |
| 10 | + 0x018 128 bit Customer ID | |
| 11 | + 0x028 3520 bit Reserved | |
| 12 | + 0x1E0 8 bit Protect Segment | |
| 13 | + 0x1E1 2296 bit HDMI Key | |
| 14 | + 0x300 2048 bit Security boot key | |
| 15 | +Users: any user space application which wants to read the Chip | |
| 16 | + and Customer ID | |
| @@ -0,0 +1,39 @@ | ||
| 1 | +What: /sys/class/uacce/<dev_name>/api | |
| 2 | +Date: Feb 2020 | |
| 3 | +KernelVersion: 5.7 | |
| 4 | +Contact: linux-accelerators@lists.ozlabs.org | |
| 5 | +Description: Api of the device | |
| 6 | + Can be any string and up to userspace to parse. | |
| 7 | + Application use the api to match the correct driver | |
| 8 | + | |
| 9 | +What: /sys/class/uacce/<dev_name>/flags | |
| 10 | +Date: Feb 2020 | |
| 11 | +KernelVersion: 5.7 | |
| 12 | +Contact: linux-accelerators@lists.ozlabs.org | |
| 13 | +Description: Attributes of the device, see UACCE_DEV_xxx flag defined in uacce.h | |
| 14 | + | |
| 15 | +What: /sys/class/uacce/<dev_name>/available_instances | |
| 16 | +Date: Feb 2020 | |
| 17 | +KernelVersion: 5.7 | |
| 18 | +Contact: linux-accelerators@lists.ozlabs.org | |
| 19 | +Description: Available instances left of the device | |
| 20 | + Return -ENODEV if uacce_ops get_available_instances is not provided | |
| 21 | + | |
| 22 | +What: /sys/class/uacce/<dev_name>/algorithms | |
| 23 | +Date: Feb 2020 | |
| 24 | +KernelVersion: 5.7 | |
| 25 | +Contact: linux-accelerators@lists.ozlabs.org | |
| 26 | +Description: Algorithms supported by this accelerator, separated by new line. | |
| 27 | + Can be any string and up to userspace to parse. | |
| 28 | + | |
| 29 | +What: /sys/class/uacce/<dev_name>/region_mmio_size | |
| 30 | +Date: Feb 2020 | |
| 31 | +KernelVersion: 5.7 | |
| 32 | +Contact: linux-accelerators@lists.ozlabs.org | |
| 33 | +Description: Size (bytes) of mmio region queue file | |
| 34 | + | |
| 35 | +What: /sys/class/uacce/<dev_name>/region_dus_size | |
| 36 | +Date: Feb 2020 | |
| 37 | +KernelVersion: 5.7 | |
| 38 | +Contact: linux-accelerators@lists.ozlabs.org | |
| 39 | +Description: Size (bytes) of dus region queue file | |
| @@ -0,0 +1,21 @@ | ||
| 1 | +What: /sys/firmware/opal/sensor_groups | |
| 2 | +Date: August 2017 | |
| 3 | +Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org> | |
| 4 | +Description: Sensor groups directory for POWER9 powernv servers | |
| 5 | + | |
| 6 | + Each folder in this directory contains a sensor group | |
| 7 | + which are classified based on type of the sensor | |
| 8 | + like power, temperature, frequency, current, etc. They | |
| 9 | + can also indicate the group of sensors belonging to | |
| 10 | + different owners like CSM, Profiler, Job-Scheduler | |
| 11 | + | |
| 12 | +What: /sys/firmware/opal/sensor_groups/<sensor_group_name>/clear | |
| 13 | +Date: August 2017 | |
| 14 | +Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org> | |
| 15 | +Description: Sysfs file to clear the min-max of all the sensors | |
| 16 | + belonging to the group. | |
| 17 | + | |
| 18 | + Writing 1 to this file will clear the minimum and | |
| 19 | + maximum values of all the sensors in the group. | |
| 20 | + In POWER9, the min-max of a sensor is the historical minimum | |
| 21 | + and maximum value of the sensor cached by OCC. | |
| @@ -318,3 +318,8 @@ Date: September 2019 · 317 unmodified lines | ||
| 318 | 318 | Contact: "Hridya Valsaraju" <hridya@google.com> |
| 319 | 319 | Description: Average number of valid blocks. |
| 320 | 320 | Available when CONFIG_F2FS_STAT_FS=y. |
| 321 | + | |
| 322 | +What: /sys/fs/f2fs/<disk>/mounted_time_sec | |
| 323 | +Date: February 2020 | |
| 324 | +Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> | |
| 325 | +Description: Show the mounted time in secs of this partition. | |
| @@ -0,0 +1,40 @@ | ||
| 1 | +What: /sys/kernel/fadump/* | |
| 2 | +Date: Dec 2019 | |
| 3 | +Contact: linuxppc-dev@lists.ozlabs.org | |
| 4 | +Description: | |
| 5 | + The /sys/kernel/fadump/* is a collection of FADump sysfs | |
| 6 | + file provide information about the configuration status | |
| 7 | + of Firmware Assisted Dump (FADump). | |
| 8 | + | |
| 9 | +What: /sys/kernel/fadump/enabled | |
| 10 | +Date: Dec 2019 | |
| 11 | +Contact: linuxppc-dev@lists.ozlabs.org | |
| 12 | +Description: read only | |
| 13 | + Primarily used to identify whether the FADump is enabled in | |
| 14 | + the kernel or not. | |
| 15 | +User: Kdump service | |
| 16 | + | |
| 17 | +What: /sys/kernel/fadump/registered | |
| 18 | +Date: Dec 2019 | |
| 19 | +Contact: linuxppc-dev@lists.ozlabs.org | |
| 20 | +Description: read/write | |
| 21 | + Helps to control the dump collect feature from userspace. | |
| 22 | + Setting 1 to this file enables the system to collect the | |
| 23 | + dump and 0 to disable it. | |
| 24 | +User: Kdump service | |
| 25 | + | |
| 26 | +What: /sys/kernel/fadump/release_mem | |
| 27 | +Date: Dec 2019 | |
| 28 | +Contact: linuxppc-dev@lists.ozlabs.org | |
| 29 | +Description: write only | |
| 30 | + This is a special sysfs file and only available when | |
| 31 | + the system is booted to capture the vmcore using FADump. | |
| 32 | + It is used to release the memory reserved by FADump to | |
| 33 | + save the crash dump. | |
| 34 | + | |
| 35 | +What: /sys/kernel/fadump/mem_reserved | |
| 36 | +Date: Dec 2019 | |
| 37 | +Contact: linuxppc-dev@lists.ozlabs.org | |
| 38 | +Description: read only | |
| 39 | + Provide information about the amount of memory reserved by | |
| 40 | + FADump to save the crash dump in bytes. | |
| @@ -2,7 +2,7 @@ What: /sys/class/leds/dell::kbd_backlight/als_enabled · 1 unmodified line | ||
| 2 | 2 | Date: December 2014 |
| 3 | 3 | KernelVersion: 3.19 |
| 4 | 4 | Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>, |
| 5 | − Pali Rohár <pali.rohar@gmail.com> | |
| 5 | + Pali Rohár <pali@kernel.org> | |
| 6 | 6 | Description: |
| 7 | 7 | This file allows to control the automatic keyboard |
| 8 | 8 | illumination mode on some systems that have an ambient |
| @@ -13,7 +13,7 @@ What: /sys/class/leds/dell::kbd_backlight/als_setting · 4 unmodified lines | ||
| 13 | 13 | Date: December 2014 |
| 14 | 14 | KernelVersion: 3.19 |
| 15 | 15 | Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>, |
| 16 | − Pali Rohár <pali.rohar@gmail.com> | |
| 16 | + Pali Rohár <pali@kernel.org> | |
| 17 | 17 | Description: |
| 18 | 18 | This file allows to specifiy the on/off threshold value, |
| 19 | 19 | as reported by the ambient light sensor. |
| @@ -22,7 +22,7 @@ What: /sys/class/leds/dell::kbd_backlight/start_triggers · 2 unmodified lines | ||
| 22 | 22 | Date: December 2014 |
| 23 | 23 | KernelVersion: 3.19 |
| 24 | 24 | Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>, |
| 25 | − Pali Rohár <pali.rohar@gmail.com> | |
| 25 | + Pali Rohár <pali@kernel.org> | |
| 26 | 26 | Description: |
| 27 | 27 | This file allows to control the input triggers that |
| 28 | 28 | turn on the keyboard backlight illumination that is |
| @@ -45,7 +45,7 @@ What: /sys/class/leds/dell::kbd_backlight/stop_timeout · 16 unmodified lines | ||
| 45 | 45 | Date: December 2014 |
| 46 | 46 | KernelVersion: 3.19 |
| 47 | 47 | Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>, |
| 48 | − Pali Rohár <pali.rohar@gmail.com> | |
| 48 | + Pali Rohár <pali@kernel.org> | |
| 49 | 49 | Description: |
| 50 | 50 | This file allows to specify the interval after which the |
| 51 | 51 | keyboard illumination is disabled because of inactivity. |
| @@ -154,3 +154,10 @@ Description: · 153 unmodified lines | ||
| 154 | 154 | device specification. For example, when user sets 7bytes on |
| 155 | 155 | 16550A, which has 1/4/8/14 bytes trigger, the RX trigger is |
| 156 | 156 | automatically changed to 4 bytes. |
| 157 | + | |
| 158 | +What: /sys/class/tty/ttyS0/console | |
| 159 | +Date: February 2020 | |
| 160 | +Contact: Andy Shevchenko <andriy.shevchenko@linux.intel.com> | |
| 161 | +Description: | |
| 162 | + Allows user to detach or attach back the given device as | |
| 163 | + kernel console. It shows and accepts a boolean variable. | |
| @@ -2,7 +2,8 @@ · 1 unmodified line | ||
| 2 | 2 | # Makefile for Sphinx documentation |
| 3 | 3 | # |
| 4 | 4 | |
| 5 | −subdir-y := devicetree/bindings/ | |
| 5 | +# for cleaning | |
| 6 | +subdir- := devicetree/bindings | |
| 6 | 7 | |
| 7 | 8 | # Check for broken documentation file references |
| 8 | 9 | ifeq ($(CONFIG_WARN_MISSING_DOCUMENTS),y) |
| @@ -13,7 +14,7 @@ endif · 4 unmodified lines | ||
| 13 | 14 | SPHINXBUILD = sphinx-build |
| 14 | 15 | SPHINXOPTS = |
| 15 | 16 | SPHINXDIRS = . |
| 16 | −_SPHINXDIRS = $(patsubst $(srctree)/Documentation/%/index.rst,%,$(wildcard $(srctree)/Documentation/*/index.rst)) | |
| 17 | +_SPHINXDIRS = $(sort $(patsubst $(srctree)/Documentation/%/index.rst,%,$(wildcard $(srctree)/Documentation/*/index.rst))) | |
| 17 | 18 | SPHINX_CONF = conf.py |
| 18 | 19 | PAPER = |
| 19 | 20 | BUILDDIR = $(obj)/output |
| @@ -0,0 +1,155 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +=============== | |
| 4 | +Boot Interrupts | |
| 5 | +=============== | |
| 6 | + | |
| 7 | +:Author: - Sean V Kelley <sean.v.kelley@linux.intel.com> | |
| 8 | + | |
| 9 | +Overview | |
| 10 | +======== | |
| 11 | + | |
| 12 | +On PCI Express, interrupts are represented with either MSI or inbound | |
| 13 | +interrupt messages (Assert_INTx/Deassert_INTx). The integrated IO-APIC in a | |
| 14 | +given Core IO converts the legacy interrupt messages from PCI Express to | |
| 15 | +MSI interrupts. If the IO-APIC is disabled (via the mask bits in the | |
| 16 | +IO-APIC table entries), the messages are routed to the legacy PCH. This | |
| 17 | +in-band interrupt mechanism was traditionally necessary for systems that | |
| 18 | +did not support the IO-APIC and for boot. Intel in the past has used the | |
| 19 | +term "boot interrupts" to describe this mechanism. Further, the PCI Express | |
| 20 | +protocol describes this in-band legacy wire-interrupt INTx mechanism for | |
| 21 | +I/O devices to signal PCI-style level interrupts. The subsequent paragraphs | |
| 22 | +describe problems with the Core IO handling of INTx message routing to the | |
| 23 | +PCH and mitigation within BIOS and the OS. | |
| 24 | + | |
| 25 | + | |
| 26 | +Issue | |
| 27 | +===== | |
| 28 | + | |
| 29 | +When in-band legacy INTx messages are forwarded to the PCH, they in turn | |
| 30 | +trigger a new interrupt for which the OS likely lacks a handler. When an | |
| 31 | +interrupt goes unhandled over time, they are tracked by the Linux kernel as | |
| 32 | +Spurious Interrupts. The IRQ will be disabled by the Linux kernel after it | |
| 33 | +reaches a specific count with the error "nobody cared". This disabled IRQ | |
| 34 | +now prevents valid usage by an existing interrupt which may happen to share | |
| 35 | +the IRQ line. | |
| 36 | + | |
| 37 | + irq 19: nobody cared (try booting with the "irqpoll" option) | |
| 38 | + CPU: 0 PID: 2988 Comm: irq/34-nipalk Tainted: 4.14.87-rt49-02410-g4a640ec-dirty #1 | |
| 39 | + Hardware name: National Instruments NI PXIe-8880/NI PXIe-8880, BIOS 2.1.5f1 01/09/2020 | |
| 40 | + Call Trace: | |
| 41 | + <IRQ> | |
| 42 | + ? dump_stack+0x46/0x5e | |
| 43 | + ? __report_bad_irq+0x2e/0xb0 | |
| 44 | + ? note_interrupt+0x242/0x290 | |
| 45 | + ? nNIKAL100_memoryRead16+0x8/0x10 [nikal] | |
| 46 | + ? handle_irq_event_percpu+0x55/0x70 | |
| 47 | + ? handle_irq_event+0x4f/0x80 | |
| 48 | + ? handle_fasteoi_irq+0x81/0x180 | |
| 49 | + ? handle_irq+0x1c/0x30 | |
| 50 | + ? do_IRQ+0x41/0xd0 | |
| 51 | + ? common_interrupt+0x84/0x84 | |
| 52 | + </IRQ> | |
| 53 | + | |
| 54 | + handlers: | |
| 55 | + irq_default_primary_handler threaded usb_hcd_irq | |
| 56 | + Disabling IRQ #19 | |
| 57 | + | |
| 58 | + | |
| 59 | +Conditions | |
| 60 | +========== | |
| 61 | + | |
| 62 | +The use of threaded interrupts is the most likely condition to trigger | |
| 63 | +this problem today. Threaded interrupts may not be reenabled after the IRQ | |
| 64 | +handler wakes. These "one shot" conditions mean that the threaded interrupt | |
| 65 | +needs to keep the interrupt line masked until the threaded handler has run. | |
| 66 | +Especially when dealing with high data rate interrupts, the thread needs to | |
| 67 | +run to completion; otherwise some handlers will end up in stack overflows | |
| 68 | +since the interrupt of the issuing device is still active. | |
| 69 | + | |
| 70 | +Affected Chipsets | |
| 71 | +================= | |
| 72 | + | |
| 73 | +The legacy interrupt forwarding mechanism exists today in a number of | |
| 74 | +devices including but not limited to chipsets from AMD/ATI, Broadcom, and | |
| 75 | +Intel. Changes made through the mitigations below have been applied to | |
| 76 | +drivers/pci/quirks.c | |
| 77 | + | |
| 78 | +Starting with ICX there are no longer any IO-APICs in the Core IO's | |
| 79 | +devices. IO-APIC is only in the PCH. Devices connected to the Core IO's | |
| 80 | +PCIe Root Ports will use native MSI/MSI-X mechanisms. | |
| 81 | + | |
| 82 | +Mitigations | |
| 83 | +=========== | |
| 84 | + | |
| 85 | +The mitigations take the form of PCI quirks. The preference has been to | |
| 86 | +first identify and make use of a means to disable the routing to the PCH. | |
| 87 | +In such a case a quirk to disable boot interrupt generation can be | |
| 88 | +added.[1] | |
| 89 | + | |
| 90 | + Intel® 6300ESB I/O Controller Hub | |
| 91 | + Alternate Base Address Register: | |
| 92 | + BIE: Boot Interrupt Enable | |
| 93 | + 0 = Boot interrupt is enabled. | |
| 94 | + 1 = Boot interrupt is disabled. | |
| 95 | + | |
| 96 | + Intel® Sandy Bridge through Sky Lake based Xeon servers: | |
| 97 | + Coherent Interface Protocol Interrupt Control | |
| 98 | + dis_intx_route2pch/dis_intx_route2ich/dis_intx_route2dmi2: | |
| 99 | + When this bit is set. Local INTx messages received from the | |
| 100 | + Intel® Quick Data DMA/PCI Express ports are not routed to legacy | |
| 101 | + PCH - they are either converted into MSI via the integrated IO-APIC | |
| 102 | + (if the IO-APIC mask bit is clear in the appropriate entries) | |
| 103 | + or cause no further action (when mask bit is set) | |
| 104 | + | |
| 105 | +In the absence of a way to directly disable the routing, another approach | |
| 106 | +has been to make use of PCI Interrupt pin to INTx routing tables for | |
| 107 | +purposes of redirecting the interrupt handler to the rerouted interrupt | |
| 108 | +line by default. Therefore, on chipsets where this INTx routing cannot be | |
| 109 | +disabled, the Linux kernel will reroute the valid interrupt to its legacy | |
| 110 | +interrupt. This redirection of the handler will prevent the occurrence of | |
| 111 | +the spurious interrupt detection which would ordinarily disable the IRQ | |
| 112 | +line due to excessive unhandled counts.[2] | |
| 113 | + | |
| 114 | +The config option X86_REROUTE_FOR_BROKEN_BOOT_IRQS exists to enable (or | |
| 115 | +disable) the redirection of the interrupt handler to the PCH interrupt | |
| 116 | +line. The option can be overridden by either pci=ioapicreroute or | |
| 117 | +pci=noioapicreroute.[3] | |
| 118 | + | |
| 119 | + | |
| 120 | +More Documentation | |
| 121 | +================== | |
| 122 | + | |
| 123 | +There is an overview of the legacy interrupt handling in several datasheets | |
| 124 | +(6300ESB and 6700PXH below). While largely the same, it provides insight | |
| 125 | +into the evolution of its handling with chipsets. | |
| 126 | + | |
| 127 | +Example of disabling of the boot interrupt | |
| 128 | +------------------------------------------ | |
| 129 | + | |
| 130 | +Intel® 6300ESB I/O Controller Hub (Document # 300641-004US) | |
| 131 | + 5.7.3 Boot Interrupt | |
| 132 | + https://www.intel.com/content/dam/doc/datasheet/6300esb-io-controller-hub-datasheet.pdf | |
| 133 | + | |
| 134 | +Intel® Xeon® Processor E5-1600/2400/2600/4600 v3 Product Families | |
| 135 | +Datasheet - Volume 2: Registers (Document # 330784-003) | |
| 136 | + 6.6.41 cipintrc Coherent Interface Protocol Interrupt Control | |
| 137 | + https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e5-v3-datasheet-vol-2.pdf | |
| 138 | + | |
| 139 | +Example of handler rerouting | |
| 140 | +---------------------------- | |
| 141 | + | |
| 142 | +Intel® 6700PXH 64-bit PCI Hub (Document # 302628) | |
| 143 | + 2.15.2 PCI Express Legacy INTx Support and Boot Interrupt | |
| 144 | + https://www.intel.com/content/dam/doc/datasheet/6700pxh-64-bit-pci-hub-datasheet.pdf | |
| 145 | + | |
| 146 | + | |
| 147 | +If you have any legacy PCI interrupt questions that aren't answered, email me. | |
| 148 | + | |
| 149 | +Cheers, | |
| 150 | + Sean V Kelley | |
| 151 | + sean.v.kelley@linux.intel.com | |
| 152 | + | |
| 153 | +[1] https://lore.kernel.org/r/12131949181903-git-send-email-sassmann@suse.de/ | |
| 154 | +[2] https://lore.kernel.org/r/12131949182094-git-send-email-sassmann@suse.de/ | |
| 155 | +[3] https://lore.kernel.org/r/487C8EA7.6020205@suse.de/ | |
| @@ -16,3 +16,4 @@ Linux PCI Bus Subsystem · 15 unmodified lines | ||
| 16 | 16 | pci-error-recovery |
| 17 | 17 | pcieaer-howto |
| 18 | 18 | endpoint/index |
| 19 | + boot-interrupts | |
| @@ -239,7 +239,7 @@ from the PCI device config space. Use the values in the pci_dev structure · 238 unmodified lines | ||
| 239 | 239 | as the PCI "bus address" might have been remapped to a "host physical" |
| 240 | 240 | address by the arch/chip-set specific kernel support. |
| 241 | 241 | |
| 242 | −See Documentation/io-mapping.txt for how to access device registers | |
| 242 | +See Documentation/driver-api/io-mapping.rst for how to access device registers | |
| 243 | 243 | or device memory. |
| 244 | 244 | |
| 245 | 245 | The device driver needs to call pci_request_region() to verify |
| @@ -156,12 +156,6 @@ default reset_link function, but different upstream ports might · 155 unmodified lines | ||
| 156 | 156 | have different specifications to reset pci express link, so all |
| 157 | 157 | upstream ports should provide their own reset_link functions. |
| 158 | 158 | |
| 159 | −In struct pcie_port_service_driver, a new pointer, reset_link, is | |
| 160 | −added. | |
| 161 | −:: | |
| 162 | − | |
| 163 | − pci_ers_result_t (*reset_link) (struct pci_dev *dev); | |
| 164 | − | |
| 165 | 159 | Section 3.2.2.2 provides more detailed info on when to call |
| 166 | 160 | reset_link. |
| 167 | 161 | |
| @@ -212,15 +206,10 @@ error_detected(dev, pci_channel_io_frozen) to all drivers within · 44 unmodified lines | ||
| 212 | 206 | a hierarchy in question. Then, performing link reset at upstream is |
| 213 | 207 | necessary. As different kinds of devices might use different approaches |
| 214 | 208 | to reset link, AER port service driver is required to provide the |
| 215 | −function to reset link. Firstly, kernel looks for if the upstream | |
| 216 | −component has an aer driver. If it has, kernel uses the reset_link | |
| 217 | −callback of the aer driver. If the upstream component has no aer driver | |
| 218 | −and the port is downstream port, we will perform a hot reset as the | |
| 219 | −default by setting the Secondary Bus Reset bit of the Bridge Control | |
| 220 | −register associated with the downstream port. As for upstream ports, | |
| 221 | −they should provide their own aer service drivers with reset_link | |
| 222 | −function. If error_detected returns PCI_ERS_RESULT_CAN_RECOVER and | |
| 223 | −reset_link returns PCI_ERS_RESULT_RECOVERED, the error handling goes | |
| 209 | +function to reset link via callback parameter of pcie_do_recovery() | |
| 210 | +function. If reset_link is not NULL, recovery function will use it | |
| 211 | +to reset the link. If error_detected returns PCI_ERS_RESULT_CAN_RECOVER | |
| 212 | +and reset_link returns PCI_ERS_RESULT_RECOVERED, the error handling goes | |
| 224 | 213 | to mmio_enabled. |
| 225 | 214 | |
| 226 | 215 | helper functions |
| @@ -243,9 +232,9 @@ messages to root port when an error is detected. · 16 unmodified lines | ||
| 243 | 232 | |
| 244 | 233 | :: |
| 245 | 234 | |
| 246 | − int pci_cleanup_aer_uncorrect_error_status(struct pci_dev *dev);` | |
| 235 | + int pci_aer_clear_nonfatal_status(struct pci_dev *dev);` | |
| 247 | 236 | |
| 248 | −pci_cleanup_aer_uncorrect_error_status cleanups the uncorrectable | |
| 237 | +pci_aer_clear_nonfatal_status clears non-fatal errors in the uncorrectable | |
| 249 | 238 | error status register. |
| 250 | 239 | |
| 251 | 240 | Frequent Asked Questions |
| @@ -4,7 +4,7 @@ A Tour Through TREE_RCU's Grace-Period Memory Ordering · 3 unmodified lines | ||
| 4 | 4 | |
| 5 | 5 | August 8, 2017 |
| 6 | 6 | |
| 7 | −This article was contributed by Paul E. McKenney | |
| 7 | +This article was contributed by Paul E. McKenney | |
| 8 | 8 | |
| 9 | 9 | Introduction |
| 10 | 10 | ============ |
| @@ -48,7 +48,7 @@ Tree RCU Grace Period Memory Ordering Building Blocks · 37 unmodified lines | ||
| 48 | 48 | |
| 49 | 49 | The workhorse for RCU's grace-period memory ordering is the |
| 50 | 50 | critical section for the ``rcu_node`` structure's |
| 51 | −``->lock``. These critical sections use helper functions for lock | |
| 51 | +``->lock``. These critical sections use helper functions for lock | |
| 52 | 52 | acquisition, including ``raw_spin_lock_rcu_node()``, |
| 53 | 53 | ``raw_spin_lock_irq_rcu_node()``, and ``raw_spin_lock_irqsave_rcu_node()``. |
| 54 | 54 | Their lock-release counterparts are ``raw_spin_unlock_rcu_node()``, |
| @@ -102,9 +102,9 @@ lock-acquisition and lock-release functions:: · 47 unmodified lines | ||
| 102 | 102 | 23 r3 = READ_ONCE(x); |
| 103 | 103 | 24 } |
| 104 | 104 | 25 |
| 105 | − 26 WARN_ON(r1 == 0 && r2 == 0 && r3 == 0); | |
| 105 | + 26 WARN_ON(r1 == 0 && r2 == 0 && r3 == 0); | |
| 106 | 106 | |
| 107 | −The ``WARN_ON()`` is evaluated at “the end of time”, | |
| 107 | +The ``WARN_ON()`` is evaluated at "the end of time", | |
| 108 | 108 | after all changes have propagated throughout the system. |
| 109 | 109 | Without the ``smp_mb__after_unlock_lock()`` provided by the |
| 110 | 110 | acquisition functions, this ``WARN_ON()`` could trigger, for example |
| @@ -4,12 +4,61 @@ Using RCU to Protect Read-Mostly Linked Lists · 3 unmodified lines | ||
| 4 | 4 | ============================================= |
| 5 | 5 | |
| 6 | 6 | One of the best applications of RCU is to protect read-mostly linked lists |
| 7 | −("struct list_head" in list.h). One big advantage of this approach | |
| 7 | +(``struct list_head`` in list.h). One big advantage of this approach | |
| 8 | 8 | is that all of the required memory barriers are included for you in |
| 9 | 9 | the list macros. This document describes several applications of RCU, |
| 10 | 10 | with the best fits first. |
| 11 | 11 | |
| 12 | −Example 1: Read-Side Action Taken Outside of Lock, No In-Place Updates | |
| 12 | + | |
| 13 | +Example 1: Read-mostly list: Deferred Destruction | |
| 14 | +------------------------------------------------- | |
| 15 | + | |
| 16 | +A widely used usecase for RCU lists in the kernel is lockless iteration over | |
| 17 | +all processes in the system. ``task_struct::tasks`` represents the list node that | |
| 18 | +links all the processes. The list can be traversed in parallel to any list | |
| 19 | +additions or removals. | |
| 20 | + | |
| 21 | +The traversal of the list is done using ``for_each_process()`` which is defined | |
| 22 | +by the 2 macros:: | |
| 23 | + | |
| 24 | + #define next_task(p) \ | |
| 25 | + list_entry_rcu((p)->tasks.next, struct task_struct, tasks) | |
| 26 | + | |
| 27 | + #define for_each_process(p) \ | |
| 28 | + for (p = &init_task ; (p = next_task(p)) != &init_task ; ) | |
| 29 | + | |
| 30 | +The code traversing the list of all processes typically looks like:: | |
| 31 | + | |
| 32 | + rcu_read_lock(); | |
| 33 | + for_each_process(p) { | |
| 34 | + /* Do something with p */ | |
| 35 | + } | |
| 36 | + rcu_read_unlock(); | |
| 37 | + | |
| 38 | +The simplified code for removing a process from a task list is:: | |
| 39 | + | |
| 40 | + void release_task(struct task_struct *p) | |
| 41 | + { | |
| 42 | + write_lock(&tasklist_lock); | |
| 43 | + list_del_rcu(&p->tasks); | |
| 44 | + write_unlock(&tasklist_lock); | |
| 45 | + call_rcu(&p->rcu, delayed_put_task_struct); | |
| 46 | + } | |
| 47 | + | |
| 48 | +When a process exits, ``release_task()`` calls ``list_del_rcu(&p->tasks)`` under | |
| 49 | +``tasklist_lock`` writer lock protection, to remove the task from the list of | |
| 50 | +all tasks. The ``tasklist_lock`` prevents concurrent list additions/removals | |
| 51 | +from corrupting the list. Readers using ``for_each_process()`` are not protected | |
| 52 | +with the ``tasklist_lock``. To prevent readers from noticing changes in the list | |
| 53 | +pointers, the ``task_struct`` object is freed only after one or more grace | |
| 54 | +periods elapse (with the help of call_rcu()). This deferring of destruction | |
| 55 | +ensures that any readers traversing the list will see valid ``p->tasks.next`` | |
| 56 | +pointers and deletion/freeing can happen in parallel with traversal of the list. | |
| 57 | +This pattern is also called an **existence lock**, since RCU pins the object in | |
| 58 | +memory until all existing readers finish. | |
| 59 | + | |
| 60 | + | |
| 61 | +Example 2: Read-Side Action Taken Outside of Lock: No In-Place Updates | |
| 13 | 62 | ---------------------------------------------------------------------- |
| 14 | 63 | |
| 15 | 64 | The best applications are cases where, if reader-writer locking were |
| @@ -26,7 +75,7 @@ added or deleted, rather than being modified in place. · 10 unmodified lines | ||
| 26 | 75 | |
| 27 | 76 | A straightforward example of this use of RCU may be found in the |
| 28 | 77 | system-call auditing support. For example, a reader-writer locked |
| 29 | −implementation of audit_filter_task() might be as follows:: | |
| 78 | +implementation of ``audit_filter_task()`` might be as follows:: | |
| 30 | 79 | |
| 31 | 80 | static enum audit_state audit_filter_task(struct task_struct *tsk) |
| 32 | 81 | { |
| @@ -34,7 +83,7 @@ implementation of audit_filter_task() might be as follows:: · 1 unmodified line | ||
| 34 | 83 | enum audit_state state; |
| 35 | 84 | |
| 36 | 85 | read_lock(&auditsc_lock); |
| 37 | − /* Note: audit_netlink_sem held by caller. */ | |
| 86 | + /* Note: audit_filter_mutex held by caller. */ | |
| 38 | 87 | list_for_each_entry(e, &audit_tsklist, list) { |
| 39 | 88 | if (audit_filter_rules(tsk, &e->rule, NULL, &state)) { |
| 40 | 89 | read_unlock(&auditsc_lock); |
| @@ -58,7 +107,7 @@ This means that RCU can be easily applied to the read side, as follows:: · 17 unmodified lines | ||
| 58 | 107 | enum audit_state state; |
| 59 | 108 | |
| 60 | 109 | rcu_read_lock(); |
| 61 | − /* Note: audit_netlink_sem held by caller. */ | |
| 110 | + /* Note: audit_filter_mutex held by caller. */ | |
| 62 | 111 | list_for_each_entry_rcu(e, &audit_tsklist, list) { |
| 63 | 112 | if (audit_filter_rules(tsk, &e->rule, NULL, &state)) { |
| 64 | 113 | rcu_read_unlock(); |
| @@ -69,18 +118,18 @@ This means that RCU can be easily applied to the read side, as follows:: · 4 unmodified lines | ||
| 69 | 118 | return AUDIT_BUILD_CONTEXT; |
| 70 | 119 | } |
| 71 | 120 | |
| 72 | −The read_lock() and read_unlock() calls have become rcu_read_lock() | |
| 121 | +The ``read_lock()`` and ``read_unlock()`` calls have become rcu_read_lock() | |
| 73 | 122 | and rcu_read_unlock(), respectively, and the list_for_each_entry() has |
| 74 | −become list_for_each_entry_rcu(). The _rcu() list-traversal primitives | |
| 123 | +become list_for_each_entry_rcu(). The **_rcu()** list-traversal primitives | |
| 75 | 124 | insert the read-side memory barriers that are required on DEC Alpha CPUs. |
| 76 | 125 | |
| 77 | −The changes to the update side are also straightforward. A reader-writer | |
| 78 | −lock might be used as follows for deletion and insertion:: | |
| 126 | +The changes to the update side are also straightforward. A reader-writer lock | |
| 127 | +might be used as follows for deletion and insertion:: | |
| 79 | 128 | |
| 80 | 129 | static inline int audit_del_rule(struct audit_rule *rule, |
| 81 | 130 | struct list_head *list) |
| 82 | 131 | { |
| 83 | − struct audit_entry *e; | |
| 132 | + struct audit_entry *e; | |
| 84 | 133 | |
| 85 | 134 | write_lock(&auditsc_lock); |
| 86 | 135 | list_for_each_entry(e, list, list) { |
| @@ -113,9 +162,9 @@ Following are the RCU equivalents for these two functions:: · 26 unmodified lines | ||
| 113 | 162 | static inline int audit_del_rule(struct audit_rule *rule, |
| 114 | 163 | struct list_head *list) |
| 115 | 164 | { |
| 116 | − struct audit_entry *e; | |
| 165 | + struct audit_entry *e; | |
| 117 | 166 | |
| 118 | − /* Do not use the _rcu iterator here, since this is the only | |
| 167 | + /* No need to use the _rcu iterator here, since this is the only | |
| 119 | 168 | * deletion routine. */ |
| 120 | 169 | list_for_each_entry(e, list, list) { |
| 121 | 170 | if (!audit_compare_rule(rule, &e->rule)) { |
| @@ -139,45 +188,45 @@ Following are the RCU equivalents for these two functions:: · 17 unmodified lines | ||
| 139 | 188 | return 0; |
| 140 | 189 | } |
| 141 | 190 | |
| 142 | −Normally, the write_lock() and write_unlock() would be replaced by | |
| 143 | −a spin_lock() and a spin_unlock(), but in this case, all callers hold | |
| 144 | −audit_netlink_sem, so no additional locking is required. The auditsc_lock | |
| 145 | −can therefore be eliminated, since use of RCU eliminates the need for | |
| 146 | −writers to exclude readers. Normally, the write_lock() calls would | |
| 147 | −be converted into spin_lock() calls. | |
| 191 | +Normally, the ``write_lock()`` and ``write_unlock()`` would be replaced by a | |
| 192 | +spin_lock() and a spin_unlock(). But in this case, all callers hold | |
| 193 | +``audit_filter_mutex``, so no additional locking is required. The | |
| 194 | +``auditsc_lock`` can therefore be eliminated, since use of RCU eliminates the | |
| 195 | +need for writers to exclude readers. | |
| 148 | 196 | |
| 149 | 197 | The list_del(), list_add(), and list_add_tail() primitives have been |
| 150 | 198 | replaced by list_del_rcu(), list_add_rcu(), and list_add_tail_rcu(). |
| 151 | −The _rcu() list-manipulation primitives add memory barriers that are | |
| 152 | −needed on weakly ordered CPUs (most of them!). The list_del_rcu() | |
| 153 | −primitive omits the pointer poisoning debug-assist code that would | |
| 154 | −otherwise cause concurrent readers to fail spectacularly. | |
| 199 | +The **_rcu()** list-manipulation primitives add memory barriers that are needed on | |
| 200 | +weakly ordered CPUs (most of them!). The list_del_rcu() primitive omits the | |
| 201 | +pointer poisoning debug-assist code that would otherwise cause concurrent | |
| 202 | +readers to fail spectacularly. | |
| 155 | 203 | |
| 156 | −So, when readers can tolerate stale data and when entries are either added | |
| 157 | −or deleted, without in-place modification, it is very easy to use RCU! | |
| 204 | +So, when readers can tolerate stale data and when entries are either added or | |
| 205 | +deleted, without in-place modification, it is very easy to use RCU! | |
| 158 | 206 | |
| 159 | −Example 2: Handling In-Place Updates | |
| 207 | + | |
| 208 | +Example 3: Handling In-Place Updates | |
| 160 | 209 | ------------------------------------ |
| 161 | 210 | |
| 162 | −The system-call auditing code does not update auditing rules in place. | |
| 163 | −However, if it did, reader-writer-locked code to do so might look as | |
| 164 | −follows (presumably, the field_count is only permitted to decrease, | |
| 165 | −otherwise, the added fields would need to be filled in):: | |
| 211 | +The system-call auditing code does not update auditing rules in place. However, | |
| 212 | +if it did, the reader-writer-locked code to do so might look as follows | |
| 213 | +(assuming only ``field_count`` is updated, otherwise, the added fields would | |
| 214 | +need to be filled in):: | |
| 166 | 215 | |
| 167 | 216 | static inline int audit_upd_rule(struct audit_rule *rule, |
| 168 | 217 | struct list_head *list, |
| 169 | 218 | __u32 newaction, |
| 170 | 219 | __u32 newfield_count) |
| 171 | 220 | { |
| 172 | − struct audit_entry *e; | |
| 173 | − struct audit_newentry *ne; | |
| 221 | + struct audit_entry *e; | |
| 222 | + struct audit_entry *ne; | |
| 174 | 223 | |
| 175 | 224 | write_lock(&auditsc_lock); |
| 176 | − /* Note: audit_netlink_sem held by caller. */ | |
| 225 | + /* Note: audit_filter_mutex held by caller. */ | |
| 177 | 226 | list_for_each_entry(e, list, list) { |
| 178 | 227 | if (!audit_compare_rule(rule, &e->rule)) { |
| 179 | 228 | e->rule.action = newaction; |
| 180 | − e->rule.file_count = newfield_count; | |
| 229 | + e->rule.field_count = newfield_count; | |
| 181 | 230 | write_unlock(&auditsc_lock); |
| 182 | 231 | return 0; |
| 183 | 232 | } |
| @@ -188,16 +237,16 @@ otherwise, the added fields would need to be filled in):: · 4 unmodified lines | ||
| 188 | 237 | |
| 189 | 238 | The RCU version creates a copy, updates the copy, then replaces the old |
| 190 | 239 | entry with the newly updated entry. This sequence of actions, allowing |
| 191 | −concurrent reads while doing a copy to perform an update, is what gives | |
| 192 | −RCU ("read-copy update") its name. The RCU code is as follows:: | |
| 240 | +concurrent reads while making a copy to perform an update, is what gives | |
| 241 | +RCU (*read-copy update*) its name. The RCU code is as follows:: | |
| 193 | 242 | |
| 194 | 243 | static inline int audit_upd_rule(struct audit_rule *rule, |
| 195 | 244 | struct list_head *list, |
| 196 | 245 | __u32 newaction, |
| 197 | 246 | __u32 newfield_count) |
| 198 | 247 | { |
| 199 | − struct audit_entry *e; | |
| 200 | − struct audit_newentry *ne; | |
| 248 | + struct audit_entry *e; | |
| 249 | + struct audit_entry *ne; | |
| 201 | 250 | |
| 202 | 251 | list_for_each_entry(e, list, list) { |
| 203 | 252 | if (!audit_compare_rule(rule, &e->rule)) { |
| @@ -206,7 +255,7 @@ RCU ("read-copy update") its name. The RCU code is as follows:: · 2 unmodified lines | ||
| 206 | 255 | return -ENOMEM; |
| 207 | 256 | audit_copy_rule(&ne->rule, &e->rule); |
| 208 | 257 | ne->rule.action = newaction; |
| 209 | − ne->rule.file_count = newfield_count; | |
| 258 | + ne->rule.field_count = newfield_count; | |
| 210 | 259 | list_replace_rcu(&e->list, &ne->list); |
| 211 | 260 | call_rcu(&e->rcu, audit_free_rule); |
| 212 | 261 | return 0; |
| @@ -215,34 +264,45 @@ RCU ("read-copy update") its name. The RCU code is as follows:: · 2 unmodified lines | ||
| 215 | 264 | return -EFAULT; /* No matching rule */ |
| 216 | 265 | } |
| 217 | 266 | |
| 218 | −Again, this assumes that the caller holds audit_netlink_sem. Normally, | |
| 219 | −the reader-writer lock would become a spinlock in this sort of code. | |
| 267 | +Again, this assumes that the caller holds ``audit_filter_mutex``. Normally, the | |
| 268 | +writer lock would become a spinlock in this sort of code. | |
| 220 | 269 | |
| 221 | −Example 3: Eliminating Stale Data | |
| 270 | +Another use of this pattern can be found in the openswitch driver's *connection | |
| 271 | +tracking table* code in ``ct_limit_set()``. The table holds connection tracking | |
| 272 | +entries and has a limit on the maximum entries. There is one such table | |
| 273 | +per-zone and hence one *limit* per zone. The zones are mapped to their limits | |
| 274 | +through a hashtable using an RCU-managed hlist for the hash chains. When a new | |
| 275 | +limit is set, a new limit object is allocated and ``ct_limit_set()`` is called | |
| 276 | +to replace the old limit object with the new one using list_replace_rcu(). | |
| 277 | +The old limit object is then freed after a grace period using kfree_rcu(). | |
| 278 | + | |
| 279 | + | |
| 280 | +Example 4: Eliminating Stale Data | |
| 222 | 281 | --------------------------------- |
| 223 | 282 | |
| 224 | −The auditing examples above tolerate stale data, as do most algorithms | |
| 283 | +The auditing example above tolerates stale data, as do most algorithms | |
| 225 | 284 | that are tracking external state. Because there is a delay from the |
| 226 | 285 | time the external state changes before Linux becomes aware of the change, |
| 227 | −additional RCU-induced staleness is normally not a problem. | |
| 286 | +additional RCU-induced staleness is generally not a problem. | |
| 228 | 287 | |
| 229 | 288 | However, there are many examples where stale data cannot be tolerated. |
| 230 | −One example in the Linux kernel is the System V IPC (see the ipc_lock() | |
| 231 | −function in ipc/util.c). This code checks a "deleted" flag under a | |
| 232 | −per-entry spinlock, and, if the "deleted" flag is set, pretends that the | |
| 289 | +One example in the Linux kernel is the System V IPC (see the shm_lock() | |
| 290 | +function in ipc/shm.c). This code checks a *deleted* flag under a | |
| 291 | +per-entry spinlock, and, if the *deleted* flag is set, pretends that the | |
| 233 | 292 | entry does not exist. For this to be helpful, the search function must |
| 234 | −return holding the per-entry spinlock, as ipc_lock() does in fact do. | |
| 293 | +return holding the per-entry spinlock, as shm_lock() does in fact do. | |
| 294 | + | |
| 295 | +.. _quick_quiz: | |
| 235 | 296 | |
| 236 | 297 | Quick Quiz: |
| 237 | − Why does the search function need to return holding the per-entry lock for | |
| 238 | − this deleted-flag technique to be helpful? | |
| 298 | + For the deleted-flag technique to be helpful, why is it necessary | |
| 299 | + to hold the per-entry lock while returning from the search function? | |
| 239 | 300 | |
| 240 | −:ref:`Answer to Quick Quiz <answer_quick_quiz_list>` | |
| 301 | +:ref:`Answer to Quick Quiz <quick_quiz_answer>` | |
| 241 | 302 | |
| 242 | −If the system-call audit module were to ever need to reject stale data, | |
| 243 | −one way to accomplish this would be to add a "deleted" flag and a "lock" | |
| 244 | −spinlock to the audit_entry structure, and modify audit_filter_task() | |
| 245 | −as follows:: | |
| 303 | +If the system-call audit module were to ever need to reject stale data, one way | |
| 304 | +to accomplish this would be to add a ``deleted`` flag and a ``lock`` spinlock to the | |
| 305 | +audit_entry structure, and modify ``audit_filter_task()`` as follows:: | |
| 246 | 306 | |
| 247 | 307 | static enum audit_state audit_filter_task(struct task_struct *tsk) |
| 248 | 308 | { |
| @@ -267,20 +327,20 @@ as follows:: · 18 unmodified lines | ||
| 267 | 327 | } |
| 268 | 328 | |
| 269 | 329 | Note that this example assumes that entries are only added and deleted. |
| 270 | −Additional mechanism is required to deal correctly with the | |
| 271 | −update-in-place performed by audit_upd_rule(). For one thing, | |
| 272 | −audit_upd_rule() would need additional memory barriers to ensure | |
| 273 | −that the list_add_rcu() was really executed before the list_del_rcu(). | |
| 330 | +Additional mechanism is required to deal correctly with the update-in-place | |
| 331 | +performed by ``audit_upd_rule()``. For one thing, ``audit_upd_rule()`` would | |
| 332 | +need additional memory barriers to ensure that the list_add_rcu() was really | |
| 333 | +executed before the list_del_rcu(). | |
| 274 | 334 | |
| 275 | −The audit_del_rule() function would need to set the "deleted" | |
| 276 | −flag under the spinlock as follows:: | |
| 335 | +The ``audit_del_rule()`` function would need to set the ``deleted`` flag under the | |
| 336 | +spinlock as follows:: | |
| 277 | 337 | |
| 278 | 338 | static inline int audit_del_rule(struct audit_rule *rule, |
| 279 | 339 | struct list_head *list) |
| 280 | 340 | { |
| 281 | − struct audit_entry *e; | |
| 341 | + struct audit_entry *e; | |
| 282 | 342 | |
| 283 | − /* Do not need to use the _rcu iterator here, since this | |
| 343 | + /* No need to use the _rcu iterator here, since this | |
| 284 | 344 | * is the only deletion routine. */ |
| 285 | 345 | list_for_each_entry(e, list, list) { |
| 286 | 346 | if (!audit_compare_rule(rule, &e->rule)) { |
| @@ -295,6 +355,91 @@ flag under the spinlock as follows:: · 8 unmodified lines | ||
| 295 | 355 | return -EFAULT; /* No matching rule */ |
| 296 | 356 | } |
| 297 | 357 | |
| 358 | +This too assumes that the caller holds ``audit_filter_mutex``. | |
| 359 | + | |
| 360 | + | |
| 361 | +Example 5: Skipping Stale Objects | |
| 362 | +--------------------------------- | |
| 363 | + | |
| 364 | +For some usecases, reader performance can be improved by skipping stale objects | |
| 365 | +during read-side list traversal if the object in concern is pending destruction | |
| 366 | +after one or more grace periods. One such example can be found in the timerfd | |
| 367 | +subsystem. When a ``CLOCK_REALTIME`` clock is reprogrammed - for example due to | |
| 368 | +setting of the system time, then all programmed timerfds that depend on this | |
| 369 | +clock get triggered and processes waiting on them to expire are woken up in | |
| 370 | +advance of their scheduled expiry. To facilitate this, all such timers are added | |
| 371 | +to an RCU-managed ``cancel_list`` when they are setup in | |
| 372 | +``timerfd_setup_cancel()``:: | |
| 373 | + | |
| 374 | + static void timerfd_setup_cancel(struct timerfd_ctx *ctx, int flags) | |
| 375 | + { | |
| 376 | + spin_lock(&ctx->cancel_lock); | |
| 377 | + if ((ctx->clockid == CLOCK_REALTIME && | |
| 378 | + (flags & TFD_TIMER_ABSTIME) && (flags & TFD_TIMER_CANCEL_ON_SET)) { | |
| 379 | + if (!ctx->might_cancel) { | |
| 380 | + ctx->might_cancel = true; | |
| 381 | + spin_lock(&cancel_lock); | |
| 382 | + list_add_rcu(&ctx->clist, &cancel_list); | |
| 383 | + spin_unlock(&cancel_lock); | |
| 384 | + } | |
| 385 | + } | |
| 386 | + spin_unlock(&ctx->cancel_lock); | |
| 387 | + } | |
| 388 | + | |
| 389 | +When a timerfd is freed (fd is closed), then the ``might_cancel`` flag of the | |
| 390 | +timerfd object is cleared, the object removed from the ``cancel_list`` and | |
| 391 | +destroyed:: | |
| 392 | + | |
| 393 | + int timerfd_release(struct inode *inode, struct file *file) | |
| 394 | + { | |
| 395 | + struct timerfd_ctx *ctx = file->private_data; | |
| 396 | + | |
| 397 | + spin_lock(&ctx->cancel_lock); | |
| 398 | + if (ctx->might_cancel) { | |
| 399 | + ctx->might_cancel = false; | |
| 400 | + spin_lock(&cancel_lock); | |
| 401 | + list_del_rcu(&ctx->clist); | |
| 402 | + spin_unlock(&cancel_lock); | |
| 403 | + } | |
| 404 | + spin_unlock(&ctx->cancel_lock); | |
| 405 | + | |
| 406 | + hrtimer_cancel(&ctx->t.tmr); | |
| 407 | + kfree_rcu(ctx, rcu); | |
| 408 | + return 0; | |
| 409 | + } | |
| 410 | + | |
| 411 | +If the ``CLOCK_REALTIME`` clock is set, for example by a time server, the | |
| 412 | +hrtimer framework calls ``timerfd_clock_was_set()`` which walks the | |
| 413 | +``cancel_list`` and wakes up processes waiting on the timerfd. While iterating | |
| 414 | +the ``cancel_list``, the ``might_cancel`` flag is consulted to skip stale | |
| 415 | +objects:: | |
| 416 | + | |
| 417 | + void timerfd_clock_was_set(void) | |
| 418 | + { | |
| 419 | + struct timerfd_ctx *ctx; | |
| 420 | + unsigned long flags; | |
| 421 | + | |
| 422 | + rcu_read_lock(); | |
| 423 | + list_for_each_entry_rcu(ctx, &cancel_list, clist) { | |
| 424 | + if (!ctx->might_cancel) | |
| 425 | + continue; | |
| 426 | + spin_lock_irqsave(&ctx->wqh.lock, flags); | |
| 427 | + if (ctx->moffs != ktime_mono_to_real(0)) { | |
| 428 | + ctx->moffs = KTIME_MAX; | |
| 429 | + ctx->ticks++; | |
| 430 | + wake_up_locked_poll(&ctx->wqh, EPOLLIN); | |
| 431 | + } | |
| 432 | + spin_unlock_irqrestore(&ctx->wqh.lock, flags); | |
| 433 | + } | |
| 434 | + rcu_read_unlock(); | |
| 435 | + } | |
| 436 | + | |
| 437 | +The key point here is, because RCU-traversal of the ``cancel_list`` happens | |
| 438 | +while objects are being added and removed to the list, sometimes the traversal | |
| 439 | +can step on an object that has been removed from the list. In this example, it | |
| 440 | +is seen that it is better to skip such objects using a flag. | |
| 441 | + | |
| 442 | + | |
| 298 | 443 | Summary |
| 299 | 444 | ------- |
| 300 | 445 | |
| @@ -303,19 +448,21 @@ the most amenable to use of RCU. The simplest case is where entries are · 2 unmodified lines | ||
| 303 | 448 | either added or deleted from the data structure (or atomically modified |
| 304 | 449 | in place), but non-atomic in-place modifications can be handled by making |
| 305 | 450 | a copy, updating the copy, then replacing the original with the copy. |
| 306 | −If stale data cannot be tolerated, then a "deleted" flag may be used | |
| 451 | +If stale data cannot be tolerated, then a *deleted* flag may be used | |
| 307 | 452 | in conjunction with a per-entry spinlock in order to allow the search |
| 308 | 453 | function to reject newly deleted data. |
| 309 | 454 | |
| 310 | −.. _answer_quick_quiz_list: | |
| 455 | +.. _quick_quiz_answer: | |
| 311 | 456 | |
| 312 | 457 | Answer to Quick Quiz: |
| 313 | − Why does the search function need to return holding the per-entry | |
| 314 | − lock for this deleted-flag technique to be helpful? | |
| 458 | + For the deleted-flag technique to be helpful, why is it necessary | |
| 459 | + to hold the per-entry lock while returning from the search function? | |
| 315 | 460 | |
| 316 | 461 | If the search function drops the per-entry lock before returning, |
| 317 | 462 | then the caller will be processing stale data in any case. If it |
| 318 | 463 | is really OK to be processing stale data, then you don't need a |
| 319 | − "deleted" flag. If processing stale data really is a problem, | |
| 464 | + *deleted* flag. If processing stale data really is a problem, | |
| 320 | 465 | then you need to hold the per-entry lock across all of the code |
| 321 | 466 | that uses the value that was returned. |
| 467 | + | |
| 468 | +:ref:`Back to Quick Quiz <quick_quiz>` | |
| @@ -11,8 +11,8 @@ must be long enough that any readers accessing the item being deleted have · 10 unmodified lines | ||
| 11 | 11 | since dropped their references. For example, an RCU-protected deletion |
| 12 | 12 | from a linked list would first remove the item from the list, wait for |
| 13 | 13 | a grace period to elapse, then free the element. See the |
| 14 | −Documentation/RCU/listRCU.rst file for more information on using RCU with | |
| 15 | −linked lists. | |
| 14 | +:ref:`Documentation/RCU/listRCU.rst <list_rcu_doc>` for more information on | |
| 15 | +using RCU with linked lists. | |
| 16 | 16 | |
| 17 | 17 | Frequently Asked Questions |
| 18 | 18 | -------------------------- |
| @@ -50,7 +50,7 @@ Frequently Asked Questions · 31 unmodified lines | ||
| 50 | 50 | - If I am running on a uniprocessor kernel, which can only do one |
| 51 | 51 | thing at a time, why should I wait for a grace period? |
| 52 | 52 | |
| 53 | − See the Documentation/RCU/UP.rst file for more information. | |
| 53 | + See :ref:`Documentation/RCU/UP.rst <up_doc>` for more information. | |
| 54 | 54 | |
| 55 | 55 | - How can I see where RCU is currently used in the Linux kernel? |
| 56 | 56 | |
| @@ -68,18 +68,18 @@ Frequently Asked Questions · 11 unmodified lines | ||
| 68 | 68 | |
| 69 | 69 | - Why the name "RCU"? |
| 70 | 70 | |
| 71 | − "RCU" stands for "read-copy update". The file Documentation/RCU/listRCU.rst | |
| 72 | − has more information on where this name came from, search for | |
| 73 | − "read-copy update" to find it. | |
| 71 | + "RCU" stands for "read-copy update". | |
| 72 | + :ref:`Documentation/RCU/listRCU.rst <list_rcu_doc>` has more information on where | |
| 73 | + this name came from, search for "read-copy update" to find it. | |
| 74 | 74 | |
| 75 | 75 | - I hear that RCU is patented? What is with that? |
| 76 | 76 | |
| 77 | 77 | Yes, it is. There are several known patents related to RCU, |
| 78 | − search for the string "Patent" in RTFP.txt to find them. | |
| 78 | + search for the string "Patent" in Documentation/RCU/RTFP.txt to find them. | |
| 79 | 79 | Of these, one was allowed to lapse by the assignee, and the |
| 80 | 80 | others have been contributed to the Linux kernel under GPL. |
| 81 | 81 | There are now also LGPL implementations of user-level RCU |
| 82 | − available (http://liburcu.org/). | |
| 82 | + available (https://liburcu.org/). | |
| 83 | 83 | |
| 84 | 84 | - I hear that RCU needs work in order to support realtime kernels? |
| 85 | 85 | |
| @@ -88,5 +88,5 @@ Frequently Asked Questions · 2 unmodified lines | ||
| 88 | 88 | |
| 89 | 89 | - Where can I find more information on RCU? |
| 90 | 90 | |
| 91 | − See the RTFP.txt file in this directory. | |
| 91 | + See the Documentation/RCU/RTFP.txt file. | |
| 92 | 92 | Or point your browser at (http://www.rdrop.com/users/paulmck/RCU/). |
| @@ -124,9 +124,14 @@ using a dynamically allocated srcu_struct (hence "srcud-" rather than · 123 unmodified lines | ||
| 124 | 124 | debugging. The final "T" entry contains the totals of the counters. |
| 125 | 125 | |
| 126 | 126 | |
| 127 | −USAGE | |
| 127 | +USAGE ON SPECIFIC KERNEL BUILDS | |
| 128 | 128 | |
| 129 | −The following script may be used to torture RCU: | |
| 129 | +It is sometimes desirable to torture RCU on a specific kernel build, | |
| 130 | +for example, when preparing to put that kernel build into production. | |
| 131 | +In that case, the kernel should be built with CONFIG_RCU_TORTURE_TEST=m | |
| 132 | +so that the test can be started using modprobe and terminated using rmmod. | |
| 133 | + | |
| 134 | +For example, the following script may be used to torture RCU: | |
| 130 | 135 | |
| 131 | 136 | #!/bin/sh |
| 132 | 137 | |
| @@ -142,8 +147,136 @@ checked for such errors. The "rmmod" command forces a "SUCCESS", · 9 unmodified lines | ||
| 142 | 147 | two are self-explanatory, while the last indicates that while there |
| 143 | 148 | were no RCU failures, CPU-hotplug problems were detected. |
| 144 | 149 | |
| 145 | −However, the tools/testing/selftests/rcutorture/bin/kvm.sh script | |
| 146 | −provides better automation, including automatic failure analysis. | |
| 147 | −It assumes a qemu/kvm-enabled platform, and runs guest OSes out of initrd. | |
| 148 | −See tools/testing/selftests/rcutorture/doc/initrd.txt for instructions | |
| 149 | −on setting up such an initrd. | |
| 150 | + | |
| 151 | +USAGE ON MAINLINE KERNELS | |
| 152 | + | |
| 153 | +When using rcutorture to test changes to RCU itself, it is often | |
| 154 | +necessary to build a number of kernels in order to test that change | |
| 155 | +across a broad range of combinations of the relevant Kconfig options | |
| 156 | +and of the relevant kernel boot parameters. In this situation, use | |
| 157 | +of modprobe and rmmod can be quite time-consuming and error-prone. | |
| 158 | + | |
| 159 | +Therefore, the tools/testing/selftests/rcutorture/bin/kvm.sh | |
| 160 | +script is available for mainline testing for x86, arm64, and | |
| 161 | +powerpc. By default, it will run the series of tests specified by | |
| 162 | +tools/testing/selftests/rcutorture/configs/rcu/CFLIST, with each test | |
| 163 | +running for 30 minutes within a guest OS using a minimal userspace | |
| 164 | +supplied by an automatically generated initrd. After the tests are | |
| 165 | +complete, the resulting build products and console output are analyzed | |
| 166 | +for errors and the results of the runs are summarized. | |
| 167 | + | |
| 168 | +On larger systems, rcutorture testing can be accelerated by passing the | |
| 169 | +--cpus argument to kvm.sh. For example, on a 64-CPU system, "--cpus 43" | |
| 170 | +would use up to 43 CPUs to run tests concurrently, which as of v5.4 would | |
| 171 | +complete all the scenarios in two batches, reducing the time to complete | |
| 172 | +from about eight hours to about one hour (not counting the time to build | |
| 173 | +the sixteen kernels). The "--dryrun sched" argument will not run tests, | |
| 174 | +but rather tell you how the tests would be scheduled into batches. This | |
| 175 | +can be useful when working out how many CPUs to specify in the --cpus | |
| 176 | +argument. | |
| 177 | + | |
| 178 | +Not all changes require that all scenarios be run. For example, a change | |
| 179 | +to Tree SRCU might run only the SRCU-N and SRCU-P scenarios using the | |
| 180 | +--configs argument to kvm.sh as follows: "--configs 'SRCU-N SRCU-P'". | |
| 181 | +Large systems can run multiple copies of of the full set of scenarios, | |
| 182 | +for example, a system with 448 hardware threads can run five instances | |
| 183 | +of the full set concurrently. To make this happen: | |
| 184 | + | |
| 185 | + kvm.sh --cpus 448 --configs '5*CFLIST' | |
| 186 | + | |
| 187 | +Alternatively, such a system can run 56 concurrent instances of a single | |
| 188 | +eight-CPU scenario: | |
| 189 | + | |
| 190 | + kvm.sh --cpus 448 --configs '56*TREE04' | |
| 191 | + | |
| 192 | +Or 28 concurrent instances of each of two eight-CPU scenarios: | |
| 193 | + | |
| 194 | + kvm.sh --cpus 448 --configs '28*TREE03 28*TREE04' | |
| 195 | + | |
| 196 | +Of course, each concurrent instance will use memory, which can be | |
| 197 | +limited using the --memory argument, which defaults to 512M. Small | |
| 198 | +values for memory may require disabling the callback-flooding tests | |
| 199 | +using the --bootargs parameter discussed below. | |
| 200 | + | |
| 201 | +Sometimes additional debugging is useful, and in such cases the --kconfig | |
| 202 | +parameter to kvm.sh may be used, for example, "--kconfig 'CONFIG_KASAN=y'". | |
| 203 | + | |
| 204 | +Kernel boot arguments can also be supplied, for example, to control | |
| 205 | +rcutorture's module parameters. For example, to test a change to RCU's | |
| 206 | +CPU stall-warning code, use "--bootargs 'rcutorture.stall_cpu=30'". | |
| 207 | +This will of course result in the scripting reporting a failure, namely | |
| 208 | +the resuling RCU CPU stall warning. As noted above, reducing memory may | |
| 209 | +require disabling rcutorture's callback-flooding tests: | |
| 210 | + | |
| 211 | + kvm.sh --cpus 448 --configs '56*TREE04' --memory 128M \ | |
| 212 | + --bootargs 'rcutorture.fwd_progress=0' | |
| 213 | + | |
| 214 | +Sometimes all that is needed is a full set of kernel builds. This is | |
| 215 | +what the --buildonly argument does. | |
| 216 | + | |
| 217 | +Finally, the --trust-make argument allows each kernel build to reuse what | |
| 218 | +it can from the previous kernel build. | |
| 219 | + | |
| 220 | +There are additional more arcane arguments that are documented in the | |
| 221 | +source code of the kvm.sh script. | |
| 222 | + | |
| 223 | +If a run contains failures, the number of buildtime and runtime failures | |
| 224 | +is listed at the end of the kvm.sh output, which you really should redirect | |
| 225 | +to a file. The build products and console output of each run is kept in | |
| 226 | +tools/testing/selftests/rcutorture/res in timestamped directories. A | |
| 227 | +given directory can be supplied to kvm-find-errors.sh in order to have | |
| 228 | +it cycle you through summaries of errors and full error logs. For example: | |
| 229 | + | |
| 230 | + tools/testing/selftests/rcutorture/bin/kvm-find-errors.sh \ | |
| 231 | + tools/testing/selftests/rcutorture/res/2020.01.20-15.54.23 | |
| 232 | + | |
| 233 | +However, it is often more convenient to access the files directly. | |
| 234 | +Files pertaining to all scenarios in a run reside in the top-level | |
| 235 | +directory (2020.01.20-15.54.23 in the example above), while per-scenario | |
| 236 | +files reside in a subdirectory named after the scenario (for example, | |
| 237 | +"TREE04"). If a given scenario ran more than once (as in "--configs | |
| 238 | +'56*TREE04'" above), the directories corresponding to the second and | |
| 239 | +subsequent runs of that scenario include a sequence number, for example, | |
| 240 | +"TREE04.2", "TREE04.3", and so on. | |
| 241 | + | |
| 242 | +The most frequently used file in the top-level directory is testid.txt. | |
| 243 | +If the test ran in a git repository, then this file contains the commit | |
| 244 | +that was tested and any uncommitted changes in diff format. | |
| 245 | + | |
| 246 | +The most frequently used files in each per-scenario-run directory are: | |
| 247 | + | |
| 248 | +.config: This file contains the Kconfig options. | |
| 249 | + | |
| 250 | +Make.out: This contains build output for a specific scenario. | |
| 251 | + | |
| 252 | +console.log: This contains the console output for a specific scenario. | |
| 253 | + This file may be examined once the kernel has booted, but | |
| 254 | + it might not exist if the build failed. | |
| 255 | + | |
| 256 | +vmlinux: This contains the kernel, which can be useful with tools like | |
| 257 | + objdump and gdb. | |
| 258 | + | |
| 259 | +A number of additional files are available, but are less frequently used. | |
| 260 | +Many are intended for debugging of rcutorture itself or of its scripting. | |
| 261 | + | |
| 262 | +As of v5.4, a successful run with the default set of scenarios produces | |
| 263 | +the following summary at the end of the run on a 12-CPU system: | |
| 264 | + | |
| 265 | +SRCU-N ------- 804233 GPs (148.932/s) [srcu: g10008272 f0x0 ] | |
| 266 | +SRCU-P ------- 202320 GPs (37.4667/s) [srcud: g1809476 f0x0 ] | |
| 267 | +SRCU-t ------- 1122086 GPs (207.794/s) [srcu: g0 f0x0 ] | |
| 268 | +SRCU-u ------- 1111285 GPs (205.794/s) [srcud: g1 f0x0 ] | |
| 269 | +TASKS01 ------- 19666 GPs (3.64185/s) [tasks: g0 f0x0 ] | |
| 270 | +TASKS02 ------- 20541 GPs (3.80389/s) [tasks: g0 f0x0 ] | |
| 271 | +TASKS03 ------- 19416 GPs (3.59556/s) [tasks: g0 f0x0 ] | |
| 272 | +TINY01 ------- 836134 GPs (154.84/s) [rcu: g0 f0x0 ] n_max_cbs: 34198 | |
| 273 | +TINY02 ------- 850371 GPs (157.476/s) [rcu: g0 f0x0 ] n_max_cbs: 2631 | |
| 274 | +TREE01 ------- 162625 GPs (30.1157/s) [rcu: g1124169 f0x0 ] | |
| 275 | +TREE02 ------- 333003 GPs (61.6672/s) [rcu: g2647753 f0x0 ] n_max_cbs: 35844 | |
| 276 | +TREE03 ------- 306623 GPs (56.782/s) [rcu: g2975325 f0x0 ] n_max_cbs: 1496497 | |
| 277 | +CPU count limited from 16 to 12 | |
| 278 | +TREE04 ------- 246149 GPs (45.5831/s) [rcu: g1695737 f0x0 ] n_max_cbs: 434961 | |
| 279 | +TREE05 ------- 314603 GPs (58.2598/s) [rcu: g2257741 f0x2 ] n_max_cbs: 193997 | |
| 280 | +TREE07 ------- 167347 GPs (30.9902/s) [rcu: g1079021 f0x0 ] n_max_cbs: 478732 | |
| 281 | +CPU count limited from 16 to 12 | |
| 282 | +TREE09 ------- 752238 GPs (139.303/s) [rcu: g13075057 f0x0 ] n_max_cbs: 99011 | |
| @@ -1,3 +1,5 @@ | ||
| 1 | +.. _psi: | |
| 2 | + | |
| 1 | 3 | ================================ |
| 2 | 4 | PSI - Pressure Stall Information |
| 3 | 5 | ================================ |
| @@ -33,6 +33,12 @@ max · 32 unmodified lines | ||
| 33 | 33 | a per-instance limit. If ``max=<count>`` is set then only ``<count>`` number |
| 34 | 34 | of binder devices can be allocated in this binderfs instance. |
| 35 | 35 | |
| 36 | +stats | |
| 37 | + Using ``stats=global`` enables global binder statistics. | |
| 38 | + ``stats=global`` is only available for a binderfs instance mounted in the | |
| 39 | + initial user namespace. An attempt to use the option to mount a binderfs | |
| 40 | + instance in another user namespace will return a permission error. | |
| 41 | + | |
| 36 | 42 | Allocating binder Devices |
| 37 | 43 | ------------------------- |
| 38 | 44 | |
| @@ -1,5 +1,5 @@ | ||
| 1 | −Kernel Support for miscellaneous (your favourite) Binary Formats v1.1 | |
| 2 | −===================================================================== | |
| 1 | +Kernel Support for miscellaneous Binary Formats (binfmt_misc) | |
| 2 | +============================================================= | |
| 3 | 3 | |
| 4 | 4 | This Kernel feature allows you to invoke almost (for restrictions see below) |
| 5 | 5 | every program by simply typing its name in the shell. |
| @@ -140,8 +140,8 @@ Hints · 134 unmodified lines | ||
| 140 | 140 | ----- |
| 141 | 141 | |
| 142 | 142 | If you want to pass special arguments to your interpreter, you can |
| 143 | −write a wrapper script for it. See Documentation/admin-guide/java.rst for an | |
| 144 | −example. | |
| 143 | +write a wrapper script for it. | |
| 144 | +See :doc:`Documentation/admin-guide/java.rst <./java>` for an example. | |
| 145 | 145 | |
| 146 | 146 | Your interpreter should NOT look in the PATH for the filename; the kernel |
| 147 | 147 | passes it the full filename (or the file descriptor) to use. Using ``$PATH`` can |
| @@ -251,8 +251,6 @@ line of text and contains the following stats separated by whitespace: · 250 unmodified lines | ||
| 251 | 251 | |
| 252 | 252 | ================ ============================================================= |
| 253 | 253 | orig_data_size uncompressed size of data stored in this disk. |
| 254 | − This excludes same-element-filled pages (same_pages) since | |
| 255 | − no memory is allocated for them. | |
| 256 | 254 | Unit: bytes |
| 257 | 255 | compr_data_size compressed size of data stored in this disk |
| 258 | 256 | mem_used_total the amount of memory allocated for this disk. This |
| @@ -23,7 +23,7 @@ of dot-connected-words, and key and value are connected by ``=``. The value · 22 unmodified lines | ||
| 23 | 23 | has to be terminated by semi-colon (``;``) or newline (``\n``). |
| 24 | 24 | For array value, array entries are separated by comma (``,``). :: |
| 25 | 25 | |
| 26 | −KEY[.WORD[...]] = VALUE[, VALUE2[...]][;] | |
| 26 | + KEY[.WORD[...]] = VALUE[, VALUE2[...]][;] | |
| 27 | 27 | |
| 28 | 28 | Unlike the kernel command line syntax, spaces are OK around the comma and ``=``. |
| 29 | 29 | |
| @@ -223,6 +223,17 @@ cpu_online_mask using a CPU hotplug notifier, and the mems file · 222 unmodified lines | ||
| 223 | 223 | automatically tracks the value of node_states[N_MEMORY]--i.e., |
| 224 | 224 | nodes with memory--using the cpuset_track_online_nodes() hook. |
| 225 | 225 | |
| 226 | +The cpuset.effective_cpus and cpuset.effective_mems files are | |
| 227 | +normally read-only copies of cpuset.cpus and cpuset.mems files | |
| 228 | +respectively. If the cpuset cgroup filesystem is mounted with the | |
| 229 | +special "cpuset_v2_mode" option, the behavior of these files will become | |
| 230 | +similar to the corresponding files in cpuset v2. In other words, hotplug | |
| 231 | +events will not change cpuset.cpus and cpuset.mems. Those events will | |
| 232 | +only affect cpuset.effective_cpus and cpuset.effective_mems which show | |
| 233 | +the actual cpus and memory nodes that are currently used by this cpuset. | |
| 234 | +See Documentation/admin-guide/cgroup-v2.rst for more information about | |
| 235 | +cpuset v2 behavior. | |
| 236 | + | |
| 226 | 237 | |
| 227 | 238 | 1.4 What are exclusive cpusets ? |
| 228 | 239 | -------------------------------- |
| @@ -2,13 +2,6 @@ · 1 unmodified line | ||
| 2 | 2 | HugeTLB Controller |
| 3 | 3 | ================== |
| 4 | 4 | |
| 5 | −The HugeTLB controller allows to limit the HugeTLB usage per control group and | |
| 6 | −enforces the controller limit during page fault. Since HugeTLB doesn't | |
| 7 | −support page reclaim, enforcing the limit at page fault time implies that, | |
| 8 | −the application will get SIGBUS signal if it tries to access HugeTLB pages | |
| 9 | −beyond its limit. This requires the application to know beforehand how much | |
| 10 | −HugeTLB pages it would require for its use. | |
| 11 | − | |
| 12 | 5 | HugeTLB controller can be created by first mounting the cgroup filesystem. |
| 13 | 6 | |
| 14 | 7 | # mount -t cgroup -o hugetlb none /sys/fs/cgroup |
| @@ -28,10 +21,14 @@ process (bash) into it. · 13 unmodified lines | ||
| 28 | 21 | |
| 29 | 22 | Brief summary of control files:: |
| 30 | 23 | |
| 31 | − hugetlb.<hugepagesize>.limit_in_bytes # set/show limit of "hugepagesize" hugetlb usage | |
| 32 | − hugetlb.<hugepagesize>.max_usage_in_bytes # show max "hugepagesize" hugetlb usage recorded | |
| 33 | − hugetlb.<hugepagesize>.usage_in_bytes # show current usage for "hugepagesize" hugetlb | |
| 34 | − hugetlb.<hugepagesize>.failcnt # show the number of allocation failure due to HugeTLB limit | |
| 24 | + hugetlb.<hugepagesize>.rsvd.limit_in_bytes # set/show limit of "hugepagesize" hugetlb reservations | |
| 25 | + hugetlb.<hugepagesize>.rsvd.max_usage_in_bytes # show max "hugepagesize" hugetlb reservations and no-reserve faults | |
| 26 | + hugetlb.<hugepagesize>.rsvd.usage_in_bytes # show current reservations and no-reserve faults for "hugepagesize" hugetlb | |
| 27 | + hugetlb.<hugepagesize>.rsvd.failcnt # show the number of allocation failure due to HugeTLB reservation limit | |
| 28 | + hugetlb.<hugepagesize>.limit_in_bytes # set/show limit of "hugepagesize" hugetlb faults | |
| 29 | + hugetlb.<hugepagesize>.max_usage_in_bytes # show max "hugepagesize" hugetlb usage recorded | |
| 30 | + hugetlb.<hugepagesize>.usage_in_bytes # show current usage for "hugepagesize" hugetlb | |
| 31 | + hugetlb.<hugepagesize>.failcnt # show the number of allocation failure due to HugeTLB usage limit | |
| 35 | 32 | |
| 36 | 33 | For a system supporting three hugepage sizes (64k, 32M and 1G), the control |
| 37 | 34 | files include:: |
| @@ -40,11 +37,95 @@ files include:: · 2 unmodified lines | ||
| 40 | 37 | hugetlb.1GB.max_usage_in_bytes |
| 41 | 38 | hugetlb.1GB.usage_in_bytes |
| 42 | 39 | hugetlb.1GB.failcnt |
| 40 | + hugetlb.1GB.rsvd.limit_in_bytes | |
| 41 | + hugetlb.1GB.rsvd.max_usage_in_bytes | |
| 42 | + hugetlb.1GB.rsvd.usage_in_bytes | |
| 43 | + hugetlb.1GB.rsvd.failcnt | |
| 43 | 44 | hugetlb.64KB.limit_in_bytes |
| 44 | 45 | hugetlb.64KB.max_usage_in_bytes |
| 45 | 46 | hugetlb.64KB.usage_in_bytes |
| 46 | 47 | hugetlb.64KB.failcnt |
| 48 | + hugetlb.64KB.rsvd.limit_in_bytes | |
| 49 | + hugetlb.64KB.rsvd.max_usage_in_bytes | |
| 50 | + hugetlb.64KB.rsvd.usage_in_bytes | |
| 51 | + hugetlb.64KB.rsvd.failcnt | |
| 47 | 52 | hugetlb.32MB.limit_in_bytes |
| 48 | 53 | hugetlb.32MB.max_usage_in_bytes |
| 49 | 54 | hugetlb.32MB.usage_in_bytes |
| 50 | 55 | hugetlb.32MB.failcnt |
| 56 | + hugetlb.32MB.rsvd.limit_in_bytes | |
| 57 | + hugetlb.32MB.rsvd.max_usage_in_bytes | |
| 58 | + hugetlb.32MB.rsvd.usage_in_bytes | |
| 59 | + hugetlb.32MB.rsvd.failcnt | |
| 60 | + | |
| 61 | + | |
| 62 | +1. Page fault accounting | |
| 63 | + | |
| 64 | +hugetlb.<hugepagesize>.limit_in_bytes | |
| 65 | +hugetlb.<hugepagesize>.max_usage_in_bytes | |
| 66 | +hugetlb.<hugepagesize>.usage_in_bytes | |
| 67 | +hugetlb.<hugepagesize>.failcnt | |
| 68 | + | |
| 69 | +The HugeTLB controller allows users to limit the HugeTLB usage (page fault) per | |
| 70 | +control group and enforces the limit during page fault. Since HugeTLB | |
| 71 | +doesn't support page reclaim, enforcing the limit at page fault time implies | |
| 72 | +that, the application will get SIGBUS signal if it tries to fault in HugeTLB | |
| 73 | +pages beyond its limit. Therefore the application needs to know exactly how many | |
| 74 | +HugeTLB pages it uses before hand, and the sysadmin needs to make sure that | |
| 75 | +there are enough available on the machine for all the users to avoid processes | |
| 76 | +getting SIGBUS. | |
| 77 | + | |
| 78 | + | |
| 79 | +2. Reservation accounting | |
| 80 | + | |
| 81 | +hugetlb.<hugepagesize>.rsvd.limit_in_bytes | |
| 82 | +hugetlb.<hugepagesize>.rsvd.max_usage_in_bytes | |
| 83 | +hugetlb.<hugepagesize>.rsvd.usage_in_bytes | |
| 84 | +hugetlb.<hugepagesize>.rsvd.failcnt | |
| 85 | + | |
| 86 | +The HugeTLB controller allows to limit the HugeTLB reservations per control | |
| 87 | +group and enforces the controller limit at reservation time and at the fault of | |
| 88 | +HugeTLB memory for which no reservation exists. Since reservation limits are | |
| 89 | +enforced at reservation time (on mmap or shget), reservation limits never causes | |
| 90 | +the application to get SIGBUS signal if the memory was reserved before hand. For | |
| 91 | +MAP_NORESERVE allocations, the reservation limit behaves the same as the fault | |
| 92 | +limit, enforcing memory usage at fault time and causing the application to | |
| 93 | +receive a SIGBUS if it's crossing its limit. | |
| 94 | + | |
| 95 | +Reservation limits are superior to page fault limits described above, since | |
| 96 | +reservation limits are enforced at reservation time (on mmap or shget), and | |
| 97 | +never causes the application to get SIGBUS signal if the memory was reserved | |
| 98 | +before hand. This allows for easier fallback to alternatives such as | |
| 99 | +non-HugeTLB memory for example. In the case of page fault accounting, it's very | |
| 100 | +hard to avoid processes getting SIGBUS since the sysadmin needs precisely know | |
| 101 | +the HugeTLB usage of all the tasks in the system and make sure there is enough | |
| 102 | +pages to satisfy all requests. Avoiding tasks getting SIGBUS on overcommited | |
| 103 | +systems is practically impossible with page fault accounting. | |
| 104 | + | |
| 105 | + | |
| 106 | +3. Caveats with shared memory | |
| 107 | + | |
| 108 | +For shared HugeTLB memory, both HugeTLB reservation and page faults are charged | |
| 109 | +to the first task that causes the memory to be reserved or faulted, and all | |
| 110 | +subsequent uses of this reserved or faulted memory is done without charging. | |
| 111 | + | |
| 112 | +Shared HugeTLB memory is only uncharged when it is unreserved or deallocated. | |
| 113 | +This is usually when the HugeTLB file is deleted, and not when the task that | |
| 114 | +caused the reservation or fault has exited. | |
| 115 | + | |
| 116 | + | |
| 117 | +4. Caveats with HugeTLB cgroup offline. | |
| 118 | + | |
| 119 | +When a HugeTLB cgroup goes offline with some reservations or faults still | |
| 120 | +charged to it, the behavior is as follows: | |
| 121 | + | |
| 122 | +- The fault charges are charged to the parent HugeTLB cgroup (reparented), | |
| 123 | +- the reservation charges remain on the offline HugeTLB cgroup. | |
| 124 | + | |
| 125 | +This means that if a HugeTLB cgroup gets offlined while there is still HugeTLB | |
| 126 | +reservations charged to it, that cgroup persists as a zombie until all HugeTLB | |
| 127 | +reservations are uncharged. HugeTLB reservations behave in this manner to match | |
| 128 | +the memory controller whose cgroups also persist as zombie until all charged | |
| 129 | +memory is uncharged. Also, the tracking of HugeTLB reservations is a bit more | |
| 130 | +complex compared to the tracking of HugeTLB faults, so it is significantly | |
| 131 | +harder to reparent reservations at offline time. | |
| @@ -1,3 +1,5 @@ | ||
| 1 | +.. _cgroup-v1: | |
| 2 | + | |
| 1 | 3 | ======================== |
| 2 | 4 | Control Groups version 1 |
| 3 | 5 | ======================== |
| @@ -9,7 +9,7 @@ This is the authoritative documentation on the design, interface and · 8 unmodified lines | ||
| 9 | 9 | conventions of cgroup v2. It describes all userland-visible aspects |
| 10 | 10 | of cgroup including core and specific controller behaviors. All |
| 11 | 11 | future changes must be reflected in this document. Documentation for |
| 12 | −v1 is available under Documentation/admin-guide/cgroup-v1/. | |
| 12 | +v1 is available under :ref:`Documentation/admin-guide/cgroup-v1/index.rst <cgroup-v1>`. | |
| 13 | 13 | |
| 14 | 14 | .. CONTENTS |
| 15 | 15 | |
| @@ -188,6 +188,17 @@ cgroup v2 currently supports the following mount options. · 172 unmodified lines | ||
| 188 | 188 | modified through remount from the init namespace. The mount |
| 189 | 189 | option is ignored on non-init namespace mounts. |
| 190 | 190 | |
| 191 | + memory_recursiveprot | |
| 192 | + | |
| 193 | + Recursively apply memory.min and memory.low protection to | |
| 194 | + entire subtrees, without requiring explicit downward | |
| 195 | + propagation into leaf cgroups. This allows protecting entire | |
| 196 | + subtrees from one another, while retaining free competition | |
| 197 | + within those subtrees. This should have been the default | |
| 198 | + behavior but is a mount-option to avoid regressing setups | |
| 199 | + relying on the original semantics (e.g. specifying bogusly | |
| 200 | + high 'bypass' protection values at higher tree levels). | |
| 201 | + | |
| 191 | 202 | |
| 192 | 203 | Organizing Processes and Threads |
| 193 | 204 | -------------------------------- |
| @@ -1023,7 +1034,7 @@ All time durations are in microseconds. · 829 unmodified lines | ||
| 1023 | 1034 | A read-only nested-key file which exists on non-root cgroups. |
| 1024 | 1035 | |
| 1025 | 1036 | Shows pressure stall information for CPU. See |
| 1026 | − Documentation/accounting/psi.rst for details. | |
| 1037 | + :ref:`Documentation/accounting/psi.rst <psi>` for details. | |
| 1027 | 1038 | |
| 1028 | 1039 | cpu.uclamp.min |
| 1029 | 1040 | A read-write single value file which exists on non-root cgroups. |
| @@ -1103,7 +1114,7 @@ PAGE_SIZE multiple when read back. · 73 unmodified lines | ||
| 1103 | 1114 | proportionally to the overage, reducing reclaim pressure for |
| 1104 | 1115 | smaller overages. |
| 1105 | 1116 | |
| 1106 | − Effective min boundary is limited by memory.min values of | |
| 1117 | + Effective min boundary is limited by memory.min values of | |
| 1107 | 1118 | all ancestor cgroups. If there is memory.min overcommitment |
| 1108 | 1119 | (child cgroup or cgroups are requiring more protected memory |
| 1109 | 1120 | than parent will allow), then each child cgroup will get |
| @@ -1313,53 +1324,41 @@ PAGE_SIZE multiple when read back. · 203 unmodified lines | ||
| 1313 | 1324 | Number of major page faults incurred |
| 1314 | 1325 | |
| 1315 | 1326 | workingset_refault |
| 1316 | − | |
| 1317 | 1327 | Number of refaults of previously evicted pages |
| 1318 | 1328 | |
| 1319 | 1329 | workingset_activate |
| 1320 | − | |
| 1321 | 1330 | Number of refaulted pages that were immediately activated |
| 1322 | 1331 | |
| 1323 | 1332 | workingset_nodereclaim |
| 1324 | − | |
| 1325 | 1333 | Number of times a shadow node has been reclaimed |
| 1326 | 1334 | |
| 1327 | 1335 | pgrefill |
| 1328 | − | |
| 1329 | 1336 | Amount of scanned pages (in an active LRU list) |
| 1330 | 1337 | |
| 1331 | 1338 | pgscan |
| 1332 | − | |
| 1333 | 1339 | Amount of scanned pages (in an inactive LRU list) |
| 1334 | 1340 | |
| 1335 | 1341 | pgsteal |
| 1336 | − | |
| 1337 | 1342 | Amount of reclaimed pages |
| 1338 | 1343 | |
| 1339 | 1344 | pgactivate |
| 1340 | − | |
| 1341 | 1345 | Amount of pages moved to the active LRU list |
| 1342 | 1346 | |
| 1343 | 1347 | pgdeactivate |
| 1344 | − | |
| 1345 | 1348 | Amount of pages moved to the inactive LRU list |
| 1346 | 1349 | |
| 1347 | 1350 | pglazyfree |
| 1348 | − | |
| 1349 | 1351 | Amount of pages postponed to be freed under memory pressure |
| 1350 | 1352 | |
| 1351 | 1353 | pglazyfreed |
| 1352 | − | |
| 1353 | 1354 | Amount of reclaimed lazyfree pages |
| 1354 | 1355 | |
| 1355 | 1356 | thp_fault_alloc |
| 1356 | − | |
| 1357 | 1357 | Number of transparent hugepages which were allocated to satisfy |
| 1358 | 1358 | a page fault, including COW faults. This counter is not present |
| 1359 | 1359 | when CONFIG_TRANSPARENT_HUGEPAGE is not set. |
| 1360 | 1360 | |
| 1361 | 1361 | thp_collapse_alloc |
| 1362 | − | |
| 1363 | 1362 | Number of transparent hugepages which were allocated to allow |
| 1364 | 1363 | collapsing an existing range of pages. This counter is not |
| 1365 | 1364 | present when CONFIG_TRANSPARENT_HUGEPAGE is not set. |
| @@ -1403,7 +1402,7 @@ PAGE_SIZE multiple when read back. · 37 unmodified lines | ||
| 1403 | 1402 | A read-only nested-key file which exists on non-root cgroups. |
| 1404 | 1403 | |
| 1405 | 1404 | Shows pressure stall information for memory. See |
| 1406 | − Documentation/accounting/psi.rst for details. | |
| 1405 | + :ref:`Documentation/accounting/psi.rst <psi>` for details. | |
| 1407 | 1406 | |
| 1408 | 1407 | |
| 1409 | 1408 | Usage Guidelines |
| @@ -1478,7 +1477,7 @@ IO Interface Files · 68 unmodified lines | ||
| 1478 | 1477 | dios Number of discard IOs |
| 1479 | 1478 | ====== ===================== |
| 1480 | 1479 | |
| 1481 | − An example read output follows: | |
| 1480 | + An example read output follows:: | |
| 1482 | 1481 | |
| 1483 | 1482 | 8:16 rbytes=1459200 wbytes=314773504 rios=192 wios=353 dbytes=0 dios=0 |
| 1484 | 1483 | 8:0 rbytes=90430464 wbytes=299008000 rios=8950 wios=1252 dbytes=50331648 dios=3021 |
| @@ -1643,7 +1642,7 @@ IO Interface Files · 158 unmodified lines | ||
| 1643 | 1642 | A read-only nested-key file which exists on non-root cgroups. |
| 1644 | 1643 | |
| 1645 | 1644 | Shows pressure stall information for IO. See |
| 1646 | − Documentation/accounting/psi.rst for details. | |
| 1645 | + :ref:`Documentation/accounting/psi.rst <psi>` for details. | |
| 1647 | 1646 | |
| 1648 | 1647 | |
| 1649 | 1648 | Writeback |
| @@ -1853,7 +1852,7 @@ Cpuset Interface Files · 203 unmodified lines | ||
| 1853 | 1852 | from the requested CPUs. |
| 1854 | 1853 | |
| 1855 | 1854 | The CPU numbers are comma-separated numbers or ranges. |
| 1856 | − For example: | |
| 1855 | + For example:: | |
| 1857 | 1856 | |
| 1858 | 1857 | # cat cpuset.cpus |
| 1859 | 1858 | 0-4,6,8-10 |
| @@ -1892,7 +1891,7 @@ Cpuset Interface Files · 32 unmodified lines | ||
| 1892 | 1891 | from the requested memory nodes. |
| 1893 | 1892 | |
| 1894 | 1893 | The memory node numbers are comma-separated numbers or ranges. |
| 1895 | − For example: | |
| 1894 | + For example:: | |
| 1896 | 1895 | |
| 1897 | 1896 | # cat cpuset.mems |
| 1898 | 1897 | 0-1,3 |
| @@ -54,6 +54,9 @@ If you make a mistake with the syntax, the write will fail thus:: · 53 unmodified lines | ||
| 54 | 54 | <debugfs>/dynamic_debug/control |
| 55 | 55 | -bash: echo: write error: Invalid argument |
| 56 | 56 | |
| 57 | +Note, for systems without 'debugfs' enabled, the control file can be | |
| 58 | +found in ``/proc/dynamic_debug/control``. | |
| 59 | + | |
| 57 | 60 | Viewing Dynamic Debug Behaviour |
| 58 | 61 | =============================== |
| 59 | 62 | |
| @@ -11,11 +11,13 @@ Today, with the advent of Kernel Mode Setting, a graphics board is · 10 unmodified lines | ||
| 11 | 11 | either correctly working because all components follow the standards - |
| 12 | 12 | or the computer is unusable, because the screen remains dark after |
| 13 | 13 | booting or it displays the wrong area. Cases when this happens are: |
| 14 | + | |
| 14 | 15 | - The graphics board does not recognize the monitor. |
| 15 | 16 | - The graphics board is unable to detect any EDID data. |
| 16 | 17 | - The graphics board incorrectly forwards EDID data to the driver. |
| 17 | 18 | - The monitor sends no or bogus EDID data. |
| 18 | 19 | - A KVM sends its own EDID data instead of querying the connected monitor. |
| 20 | + | |
| 19 | 21 | Adding the kernel parameter "nomodeset" helps in most cases, but causes |
| 20 | 22 | restrictions later on. |
| 21 | 23 | |
| @@ -32,7 +34,7 @@ individual data for a specific misbehaving monitor, commented sources · 10 unmodified lines | ||
| 32 | 34 | and a Makefile environment are given here. |
| 33 | 35 | |
| 34 | 36 | To create binary EDID and C source code files from the existing data |
| 35 | −material, simply type "make". | |
| 37 | +material, simply type "make" in tools/edid/. | |
| 36 | 38 | |
| 37 | 39 | If you want to create your own EDID file, copy the file 1024x768.S, |
| 38 | 40 | replace the settings with your own data and add a new target to the |
| @@ -136,8 +136,6 @@ enables the mitigation by default. · 135 unmodified lines | ||
| 136 | 136 | The mitigation can be controlled at boot time via a kernel command line option. |
| 137 | 137 | See :ref:`taa_mitigation_control_command_line`. |
| 138 | 138 | |
| 139 | −.. _virt_mechanism: | |
| 140 | − | |
| 141 | 139 | Virtualization mitigation |
| 142 | 140 | ^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 143 | 141 | |
| @@ -75,6 +75,7 @@ configure specific aspects of kernel behavior to your liking. · 74 unmodified lines | ||
| 75 | 75 | cputopology |
| 76 | 76 | dell_rbu |
| 77 | 77 | device-mapper/index |
| 78 | + edid | |
| 78 | 79 | efi-stub |
| 79 | 80 | ext4 |
| 80 | 81 | nfs/index |
| @@ -100,7 +100,7 @@ Field 10 -- # of milliseconds spent doing I/Os (unsigned int) · 99 unmodified lines | ||
| 100 | 100 | |
| 101 | 101 | Since 5.0 this field counts jiffies when at least one request was |
| 102 | 102 | started or completed. If request runs more than 2 jiffies then some |
| 103 | − I/O time will not be accounted unless there are other requests. | |
| 103 | + I/O time might be not accounted in case of concurrent requests. | |
| 104 | 104 | |
| 105 | 105 | Field 11 -- weighted # of milliseconds spent doing I/Os (unsigned int) |
| 106 | 106 | This field is incremented at each I/O start, I/O completion, I/O |
| @@ -143,6 +143,9 @@ are summed (possibly overflowing the unsigned long variable they are · 36 unmodified lines | ||
| 143 | 143 | summed to) and the result given to the user. There is no convenient |
| 144 | 144 | user interface for accessing the per-CPU counters themselves. |
| 145 | 145 | |
| 146 | +Since 4.19 request times are measured with nanoseconds precision and | |
| 147 | +truncated to milliseconds before showing in this interface. | |
| 148 | + | |
| 146 | 149 | Disks vs Partitions |
| 147 | 150 | ------------------- |
| 148 | 151 | |
| @@ -22,11 +22,13 @@ · 21 unmodified lines | ||
| 22 | 22 | default: 0 |
| 23 | 23 | |
| 24 | 24 | acpi_backlight= [HW,ACPI] |
| 25 | − acpi_backlight=vendor | |
| 26 | − acpi_backlight=video | |
| 27 | − If set to vendor, prefer vendor specific driver | |
| 25 | + { vendor | video | native | none } | |
| 26 | + If set to vendor, prefer vendor-specific driver | |
| 28 | 27 | (e.g. thinkpad_acpi, sony_acpi, etc.) instead |
| 29 | 28 | of the ACPI video.ko driver. |
| 29 | + If set to video, use the ACPI video.ko driver. | |
| 30 | + If set to native, use the device's native backlight mode. | |
| 31 | + If set to none, disable the ACPI backlight interface. | |
| 30 | 32 | |
| 31 | 33 | acpi_force_32bit_fadt_addr |
| 32 | 34 | force FADT to use 32 bit addresses rather than the |
| @@ -450,6 +452,9 @@ · 417 unmodified lines | ||
| 450 | 452 | bert_disable [ACPI] |
| 451 | 453 | Disable BERT OS support on buggy BIOSes. |
| 452 | 454 | |
| 455 | + bgrt_disable [ACPI][X86] | |
| 456 | + Disable BGRT to avoid flickering OEM logo. | |
| 457 | + | |
| 453 | 458 | bttv.card= [HW,V4L] bttv (bt848 + bt878 based grabber cards) |
| 454 | 459 | bttv.radio= Most important insmod options are available as |
| 455 | 460 | kernel args too. |
| @@ -522,6 +527,7 @@ · 66 unmodified lines | ||
| 522 | 527 | Default value is set via a kernel config option. |
| 523 | 528 | Value can be changed at runtime via |
| 524 | 529 | /sys/fs/selinux/checkreqprot. |
| 530 | + Setting checkreqprot to 1 is deprecated. | |
| 525 | 531 | |
| 526 | 532 | cio_ignore= [S390] |
| 527 | 533 | See Documentation/s390/common_io.rst for details. |
| @@ -679,7 +685,7 @@ · 151 unmodified lines | ||
| 679 | 685 | coredump_filter= |
| 680 | 686 | [KNL] Change the default value for |
| 681 | 687 | /proc/<pid>/coredump_filter. |
| 682 | − See also Documentation/filesystems/proc.txt. | |
| 688 | + See also Documentation/filesystems/proc.rst. | |
| 683 | 689 | |
| 684 | 690 | coresight_cpu_debug.enable |
| 685 | 691 | [ARM,ARM64] |
| @@ -956,7 +962,7 @@ · 270 unmodified lines | ||
| 956 | 962 | edid/1680x1050.bin, or edid/1920x1080.bin is given |
| 957 | 963 | and no file with the same name exists. Details and |
| 958 | 964 | instructions how to build your own EDID data are |
| 959 | − available in Documentation/driver-api/edid.rst. An EDID | |
| 965 | + available in Documentation/admin-guide/edid.rst. An EDID | |
| 960 | 966 | data set will only be used for a particular connector, |
| 961 | 967 | if its name and a colon are prepended to the EDID |
| 962 | 968 | name. Each connector may use a unique EDID data |
| @@ -986,10 +992,6 @@ · 23 unmodified lines | ||
| 986 | 992 | Documentation/admin-guide/dynamic-debug-howto.rst |
| 987 | 993 | for details. |
| 988 | 994 | |
| 989 | − nompx [X86] Disables Intel Memory Protection Extensions. | |
| 990 | − See Documentation/x86/intel_mpx.rst for more | |
| 991 | − information about the feature. | |
| 992 | − | |
| 993 | 995 | nopku [X86] Disable Memory Protection Keys CPU feature found |
| 994 | 996 | in some Intel CPUs. |
| 995 | 997 | |
| @@ -1099,6 +1101,12 @@ · 103 unmodified lines | ||
| 1099 | 1101 | A valid base address must be provided, and the serial |
| 1100 | 1102 | port must already be setup and configured. |
| 1101 | 1103 | |
| 1104 | + ec_imx21,<addr> | |
| 1105 | + ec_imx6q,<addr> | |
| 1106 | + Start an early, polled-mode, output-only console on the | |
| 1107 | + Freescale i.MX UART at the specified address. The UART | |
| 1108 | + must already be setup and configured. | |
| 1109 | + | |
| 1102 | 1110 | ar3700_uart,<addr> |
| 1103 | 1111 | Start an early, polled-mode console on the |
| 1104 | 1112 | Armada 3700 serial port at the specified |
| @@ -1354,6 +1362,24 @@ · 249 unmodified lines | ||
| 1354 | 1362 | can be changed at run time by the max_graph_depth file |
| 1355 | 1363 | in the tracefs tracing directory. default: 0 (no limit) |
| 1356 | 1364 | |
| 1365 | + fw_devlink= [KNL] Create device links between consumer and supplier | |
| 1366 | + devices by scanning the firmware to infer the | |
| 1367 | + consumer/supplier relationships. This feature is | |
| 1368 | + especially useful when drivers are loaded as modules as | |
| 1369 | + it ensures proper ordering of tasks like device probing | |
| 1370 | + (suppliers first, then consumers), supplier boot state | |
| 1371 | + clean up (only after all consumers have probed), | |
| 1372 | + suspend/resume & runtime PM (consumers first, then | |
| 1373 | + suppliers). | |
| 1374 | + Format: { off | permissive | on | rpm } | |
| 1375 | + off -- Don't create device links from firmware info. | |
| 1376 | + permissive -- Create device links from firmware info | |
| 1377 | + but use it only for ordering boot state clean | |
| 1378 | + up (sync_state() calls). | |
| 1379 | + on -- Create device links from firmware info and use it | |
| 1380 | + to enforce probe and suspend/resume ordering. | |
| 1381 | + rpm -- Like "on", but also use to order runtime PM. | |
| 1382 | + | |
| 1357 | 1383 | gamecon.map[2|3]= |
| 1358 | 1384 | [HW,JOY] Multisystem joystick and NES/SNES/PSX pad |
| 1359 | 1385 | support via parallel port (up to 5 devices per port) |
| @@ -1445,6 +1471,14 @@ · 85 unmodified lines | ||
| 1445 | 1471 | hpet_mmap= [X86, HPET_MMAP] Allow userspace to mmap HPET |
| 1446 | 1472 | registers. Default set by CONFIG_HPET_MMAP_DEFAULT. |
| 1447 | 1473 | |
| 1474 | + hugetlb_cma= [HW] The size of a cma area used for allocation | |
| 1475 | + of gigantic hugepages. | |
| 1476 | + Format: nn[KMGTPE] | |
| 1477 | + | |
| 1478 | + Reserve a cma area of given size and allocate gigantic | |
| 1479 | + hugepages using the cma allocator. If enabled, the | |
| 1480 | + boot-time allocation of gigantic hugepages is skipped. | |
| 1481 | + | |
| 1448 | 1482 | hugepages= [HW,X86-32,IA-64] HugeTLB pages to allocate at boot. |
| 1449 | 1483 | hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages. |
| 1450 | 1484 | On x86-64 and powerpc, this option can be specified |
| @@ -1779,7 +1813,7 @@ · 328 unmodified lines | ||
| 1779 | 1813 | provided by tboot because it makes the system |
| 1780 | 1814 | vulnerable to DMA attacks. |
| 1781 | 1815 | nobounce [Default off] |
| 1782 | − Disable bounce buffer for unstrusted devices such as | |
| 1816 | + Disable bounce buffer for untrusted devices such as | |
| 1783 | 1817 | the Thunderbolt devices. This will treat the untrusted |
| 1784 | 1818 | devices as the trusted ones, hence might expose security |
| 1785 | 1819 | risks of DMA attacks. |
| @@ -1883,7 +1917,7 @@ · 97 unmodified lines | ||
| 1883 | 1917 | No delay |
| 1884 | 1918 | |
| 1885 | 1919 | ip= [IP_PNP] |
| 1886 | − See Documentation/filesystems/nfs/nfsroot.txt. | |
| 1920 | + See Documentation/admin-guide/nfs/nfsroot.rst. | |
| 1887 | 1921 | |
| 1888 | 1922 | ipcmni_extend [KNL] Extend the maximum number of unique System V |
| 1889 | 1923 | IPC identifiers from 32,768 to 16,777,216. |
| @@ -2543,13 +2577,22 @@ · 653 unmodified lines | ||
| 2543 | 2577 | For details see: Documentation/admin-guide/hw-vuln/mds.rst |
| 2544 | 2578 | |
| 2545 | 2579 | mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory |
| 2546 | − Amount of memory to be used when the kernel is not able | |
| 2547 | − to see the whole system memory or for test. | |
| 2580 | + Amount of memory to be used in cases as follows: | |
| 2581 | + | |
| 2582 | + 1 for test; | |
| 2583 | + 2 when the kernel is not able to see the whole system memory; | |
| 2584 | + 3 memory that lies after 'mem=' boundary is excluded from | |
| 2585 | + the hypervisor, then assigned to KVM guests. | |
| 2586 | + | |
| 2548 | 2587 | [X86] Work as limiting max address. Use together |
| 2549 | 2588 | with memmap= to avoid physical address space collisions. |
| 2550 | 2589 | Without memmap= PCI devices could be placed at addresses |
| 2551 | 2590 | belonging to unused RAM. |
| 2552 | 2591 | |
| 2592 | + Note that this only takes effects during boot time since | |
| 2593 | + in above case 3, memory may need be hot added after boot | |
| 2594 | + if system memory of hypervisor is not sufficient. | |
| 2595 | + | |
| 2553 | 2596 | mem=nopentium [BUGS=X86-32] Disable usage of 4MB pages for kernel |
| 2554 | 2597 | memory. |
| 2555 | 2598 | |
| @@ -2795,7 +2838,7 @@ · 239 unmodified lines | ||
| 2795 | 2838 | <name>,<region-number>[,<base>,<size>,<buswidth>,<altbuswidth>] |
| 2796 | 2839 | |
| 2797 | 2840 | mtdparts= [MTD] |
| 2798 | − See drivers/mtd/cmdlinepart.c. | |
| 2841 | + See drivers/mtd/parsers/cmdlinepart.c | |
| 2799 | 2842 | |
| 2800 | 2843 | multitce=off [PPC] This parameter disables the use of the pSeries |
| 2801 | 2844 | firmware feature for updating multiple TCE entries |
| @@ -2853,13 +2896,13 @@ · 51 unmodified lines | ||
| 2853 | 2896 | Default value is 0. |
| 2854 | 2897 | |
| 2855 | 2898 | nfsaddrs= [NFS] Deprecated. Use ip= instead. |
| 2856 | − See Documentation/filesystems/nfs/nfsroot.txt. | |
| 2899 | + See Documentation/admin-guide/nfs/nfsroot.rst. | |
| 2857 | 2900 | |
| 2858 | 2901 | nfsroot= [NFS] nfs root filesystem for disk-less boxes. |
| 2859 | − See Documentation/filesystems/nfs/nfsroot.txt. | |
| 2902 | + See Documentation/admin-guide/nfs/nfsroot.rst. | |
| 2860 | 2903 | |
| 2861 | 2904 | nfsrootdebug [NFS] enable nfsroot debugging messages. |
| 2862 | − See Documentation/filesystems/nfs/nfsroot.txt. | |
| 2905 | + See Documentation/admin-guide/nfs/nfsroot.rst. | |
| 2863 | 2906 | |
| 2864 | 2907 | nfs.callback_nr_threads= |
| 2865 | 2908 | [NFSv4] set the total number of threads that the |
| @@ -3174,7 +3217,7 @@ · 308 unmodified lines | ||
| 3174 | 3217 | [X86,PV_OPS] Disable paravirtualized VMware scheduler |
| 3175 | 3218 | clock and use the default one. |
| 3176 | 3219 | |
| 3177 | − no-steal-acc [X86,KVM,ARM64] Disable paravirtualized steal time | |
| 3220 | + no-steal-acc [X86,PV_OPS,ARM64] Disable paravirtualized steal time | |
| 3178 | 3221 | accounting. steal time is computed, but won't |
| 3179 | 3222 | influence scheduler behaviour |
| 3180 | 3223 | |
| @@ -3285,12 +3328,6 @@ · 104 unmodified lines | ||
| 3285 | 3328 | This can be set from sysctl after boot. |
| 3286 | 3329 | See Documentation/admin-guide/sysctl/vm.rst for details. |
| 3287 | 3330 | |
| 3288 | − of_devlink [OF, KNL] Create device links between consumer and | |
| 3289 | − supplier devices by scanning the devictree to infer the | |
| 3290 | − consumer/supplier relationships. A consumer device | |
| 3291 | − will not be probed until all the supplier devices have | |
| 3292 | − probed successfully. | |
| 3293 | − | |
| 3294 | 3331 | ohci1394_dma=early [HW] enable debugging via the ohci1394 driver. |
| 3295 | 3332 | See Documentation/debugging-via-ohci1394.txt for more |
| 3296 | 3333 | info. |
| @@ -3698,6 +3735,9 @@ · 401 unmodified lines | ||
| 3698 | 3735 | Override pmtimer IOPort with a hex value. |
| 3699 | 3736 | e.g. pmtmr=0x508 |
| 3700 | 3737 | |
| 3738 | + pm_debug_messages [SUSPEND,KNL] | |
| 3739 | + Enable suspend/resume debug messages during boot up. | |
| 3740 | + | |
| 3701 | 3741 | pnp.debug=1 [PNP] |
| 3702 | 3742 | Enable PNP debug messages (depends on the |
| 3703 | 3743 | CONFIG_PNP_DEBUG_MESSAGES option). Change at run-time |
| @@ -3799,6 +3839,11 @@ · 95 unmodified lines | ||
| 3799 | 3839 | before loading. |
| 3800 | 3840 | See Documentation/admin-guide/blockdev/ramdisk.rst. |
| 3801 | 3841 | |
| 3842 | + prot_virt= [S390] enable hosting protected virtual machines | |
| 3843 | + isolated from the hypervisor (if hardware supports | |
| 3844 | + that). | |
| 3845 | + Format: <bool> | |
| 3846 | + | |
| 3802 | 3847 | psi= [KNL] Enable or disable pressure stall information |
| 3803 | 3848 | tracking. |
| 3804 | 3849 | Format: <bool> |
| @@ -3984,6 +4029,15 @@ · 179 unmodified lines | ||
| 3984 | 4029 | Set threshold of queued RCU callbacks below which |
| 3985 | 4030 | batch limiting is re-enabled. |
| 3986 | 4031 | |
| 4032 | + rcutree.qovld= [KNL] | |
| 4033 | + Set threshold of queued RCU callbacks beyond which | |
| 4034 | + RCU's force-quiescent-state scan will aggressively | |
| 4035 | + enlist help from cond_resched() and sched IPIs to | |
| 4036 | + help CPUs more quickly reach quiescent states. | |
| 4037 | + Set to less than zero to make this be set based | |
| 4038 | + on rcutree.qhimark at boot time and to zero to | |
| 4039 | + disable more aggressive help enlistment. | |
| 4040 | + | |
| 3987 | 4041 | rcutree.rcu_idle_gp_delay= [KNL] |
| 3988 | 4042 | Set wakeup interval for idle CPUs that have |
| 3989 | 4043 | RCU callbacks (RCU_FAST_NO_HZ=y). |
| @@ -4199,6 +4253,12 @@ · 209 unmodified lines | ||
| 4199 | 4253 | rcupdate.rcu_cpu_stall_suppress= [KNL] |
| 4200 | 4254 | Suppress RCU CPU stall warning messages. |
| 4201 | 4255 | |
| 4256 | + rcupdate.rcu_cpu_stall_suppress_at_boot= [KNL] | |
| 4257 | + Suppress RCU CPU stall warning messages and | |
| 4258 | + rcutorture writer stall warnings that occur | |
| 4259 | + during early boot, that is, during the time | |
| 4260 | + before the init task is spawned. | |
| 4261 | + | |
| 4202 | 4262 | rcupdate.rcu_cpu_stall_timeout= [KNL] |
| 4203 | 4263 | Set timeout for RCU CPU stall warning messages. |
| 4204 | 4264 | |
| @@ -4392,6 +4452,22 @@ · 187 unmodified lines | ||
| 4392 | 4452 | incurs a small amount of overhead in the scheduler |
| 4393 | 4453 | but is useful for debugging and performance tuning. |
| 4394 | 4454 | |
| 4455 | + sched_thermal_decay_shift= | |
| 4456 | + [KNL, SMP] Set a decay shift for scheduler thermal | |
| 4457 | + pressure signal. Thermal pressure signal follows the | |
| 4458 | + default decay period of other scheduler pelt | |
| 4459 | + signals(usually 32 ms but configurable). Setting | |
| 4460 | + sched_thermal_decay_shift will left shift the decay | |
| 4461 | + period for the thermal pressure signal by the shift | |
| 4462 | + value. | |
| 4463 | + i.e. with the default pelt decay period of 32 ms | |
| 4464 | + sched_thermal_decay_shift thermal pressure decay pr | |
| 4465 | + 1 64 ms | |
| 4466 | + 2 128 ms | |
| 4467 | + and so on. | |
| 4468 | + Format: integer between 0 and 10 | |
| 4469 | + Default is 0. | |
| 4470 | + | |
| 4395 | 4471 | skew_tick= [KNL] Offset the periodic timer tick per cpu to mitigate |
| 4396 | 4472 | xtime_lock contention on larger systems, and/or RCU lock |
| 4397 | 4473 | contention on all systems with CONFIG_MAXSMP set. |
| @@ -4514,10 +4590,10 @@ · 116 unmodified lines | ||
| 4514 | 4590 | Format: <integer> |
| 4515 | 4591 | |
| 4516 | 4592 | A nonzero value instructs the soft-lockup detector |
| 4517 | − to panic the machine when a soft-lockup occurs. This | |
| 4518 | − is also controlled by CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC | |
| 4519 | − which is the respective build-time switch to that | |
| 4520 | − functionality. | |
| 4593 | + to panic the machine when a soft-lockup occurs. It is | |
| 4594 | + also controlled by the kernel.softlockup_panic sysctl | |
| 4595 | + and CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC, which is the | |
| 4596 | + respective build-time switch to that functionality. | |
| 4521 | 4597 | |
| 4522 | 4598 | softlockup_all_cpu_backtrace= |
| 4523 | 4599 | [KNL] Should the soft-lockup detector generate |
| @@ -4659,6 +4735,28 @@ · 135 unmodified lines | ||
| 4659 | 4735 | spia_pedr= |
| 4660 | 4736 | spia_peddr= |
| 4661 | 4737 | |
| 4738 | + split_lock_detect= | |
| 4739 | + [X86] Enable split lock detection | |
| 4740 | + | |
| 4741 | + When enabled (and if hardware support is present), atomic | |
| 4742 | + instructions that access data across cache line | |
| 4743 | + boundaries will result in an alignment check exception. | |
| 4744 | + | |
| 4745 | + off - not enabled | |
| 4746 | + | |
| 4747 | + warn - the kernel will emit rate limited warnings | |
| 4748 | + about applications triggering the #AC | |
| 4749 | + exception. This mode is the default on CPUs | |
| 4750 | + that supports split lock detection. | |
| 4751 | + | |
| 4752 | + fatal - the kernel will send SIGBUS to applications | |
| 4753 | + that trigger the #AC exception. | |
| 4754 | + | |
| 4755 | + If an #AC exception is hit in the kernel or in | |
| 4756 | + firmware (i.e. not while executing in user mode) | |
| 4757 | + the kernel will oops in either "warn" or "fatal" | |
| 4758 | + mode. | |
| 4759 | + | |
| 4662 | 4760 | srcutree.counter_wrap_check [KNL] |
| 4663 | 4761 | Specifies how frequently to check for |
| 4664 | 4762 | grace-period sequence counter wrap for the |
| @@ -4871,6 +4969,10 @@ · 206 unmodified lines | ||
| 4871 | 4969 | topology updates sent by the hypervisor to this |
| 4872 | 4970 | LPAR. |
| 4873 | 4971 | |
| 4972 | + torture.disable_onoff_at_boot= [KNL] | |
| 4973 | + Prevent the CPU-hotplug component of torturing | |
| 4974 | + until after init has spawned. | |
| 4975 | + | |
| 4874 | 4976 | tp720= [HW,PS2] |
| 4875 | 4977 | |
| 4876 | 4978 | tpm_suspend_pcr=[HW,TPM] |
| @@ -234,7 +234,7 @@ To reduce its OS jitter, do any of the following: · 233 unmodified lines | ||
| 234 | 234 | Such a workqueue can be confined to a given subset of the |
| 235 | 235 | CPUs using the ``/sys/devices/virtual/workqueue/*/cpumask`` sysfs |
| 236 | 236 | files. The set of WQ_SYSFS workqueues can be displayed using |
| 237 | − "ls sys/devices/virtual/workqueue". That said, the workqueues | |
| 237 | + "ls /sys/devices/virtual/workqueue". That said, the workqueues | |
| 238 | 238 | maintainer would like to caution people against indiscriminately |
| 239 | 239 | sprinkling WQ_SYSFS across all the workqueues. The reason for |
| 240 | 240 | caution is that it is easy to add WQ_SYSFS, but because sysfs is |
| @@ -310,6 +310,11 @@ thp_fault_fallback · 309 unmodified lines | ||
| 310 | 310 | is incremented if a page fault fails to allocate |
| 311 | 311 | a huge page and instead falls back to using small pages. |
| 312 | 312 | |
| 313 | +thp_fault_fallback_charge | |
| 314 | + is incremented if a page fault fails to charge a huge page and | |
| 315 | + instead falls back to using small pages even though the | |
| 316 | + allocation was successful. | |
| 317 | + | |
| 313 | 318 | thp_collapse_alloc_failed |
| 314 | 319 | is incremented if khugepaged found a range |
| 315 | 320 | of pages that should be collapsed into one huge page but failed |
| @@ -319,6 +324,15 @@ thp_file_alloc · 3 unmodified lines | ||
| 319 | 324 | is incremented every time a file huge page is successfully |
| 320 | 325 | allocated. |
| 321 | 326 | |
| 327 | +thp_file_fallback | |
| 328 | + is incremented if a file huge page is attempted to be allocated | |
| 329 | + but fails and instead falls back to using small pages. | |
| 330 | + | |
| 331 | +thp_file_fallback_charge | |
| 332 | + is incremented if a file huge page cannot be charged and instead | |
| 333 | + falls back to using small pages even though the allocation was | |
| 334 | + successful. | |
| 335 | + | |
| 322 | 336 | thp_file_mapped |
| 323 | 337 | is incremented every time a file huge page is mapped into |
| 324 | 338 | user address space. |
| @@ -108,6 +108,57 @@ UFFDIO_COPY. They're atomic as in guaranteeing that nothing can see an · 107 unmodified lines | ||
| 108 | 108 | half copied page since it'll keep userfaulting until the copy has |
| 109 | 109 | finished. |
| 110 | 110 | |
| 111 | +Notes: | |
| 112 | + | |
| 113 | +- If you requested UFFDIO_REGISTER_MODE_MISSING when registering then | |
| 114 | + you must provide some kind of page in your thread after reading from | |
| 115 | + the uffd. You must provide either UFFDIO_COPY or UFFDIO_ZEROPAGE. | |
| 116 | + The normal behavior of the OS automatically providing a zero page on | |
| 117 | + an annonymous mmaping is not in place. | |
| 118 | + | |
| 119 | +- None of the page-delivering ioctls default to the range that you | |
| 120 | + registered with. You must fill in all fields for the appropriate | |
| 121 | + ioctl struct including the range. | |
| 122 | + | |
| 123 | +- You get the address of the access that triggered the missing page | |
| 124 | + event out of a struct uffd_msg that you read in the thread from the | |
| 125 | + uffd. You can supply as many pages as you want with UFFDIO_COPY or | |
| 126 | + UFFDIO_ZEROPAGE. Keep in mind that unless you used DONTWAKE then | |
| 127 | + the first of any of those IOCTLs wakes up the faulting thread. | |
| 128 | + | |
| 129 | +- Be sure to test for all errors including (pollfd[0].revents & | |
| 130 | + POLLERR). This can happen, e.g. when ranges supplied were | |
| 131 | + incorrect. | |
| 132 | + | |
| 133 | +Write Protect Notifications | |
| 134 | +--------------------------- | |
| 135 | + | |
| 136 | +This is equivalent to (but faster than) using mprotect and a SIGSEGV | |
| 137 | +signal handler. | |
| 138 | + | |
| 139 | +Firstly you need to register a range with UFFDIO_REGISTER_MODE_WP. | |
| 140 | +Instead of using mprotect(2) you use ioctl(uffd, UFFDIO_WRITEPROTECT, | |
| 141 | +struct *uffdio_writeprotect) while mode = UFFDIO_WRITEPROTECT_MODE_WP | |
| 142 | +in the struct passed in. The range does not default to and does not | |
| 143 | +have to be identical to the range you registered with. You can write | |
| 144 | +protect as many ranges as you like (inside the registered range). | |
| 145 | +Then, in the thread reading from uffd the struct will have | |
| 146 | +msg.arg.pagefault.flags & UFFD_PAGEFAULT_FLAG_WP set. Now you send | |
| 147 | +ioctl(uffd, UFFDIO_WRITEPROTECT, struct *uffdio_writeprotect) again | |
| 148 | +while pagefault.mode does not have UFFDIO_WRITEPROTECT_MODE_WP set. | |
| 149 | +This wakes up the thread which will continue to run with writes. This | |
| 150 | +allows you to do the bookkeeping about the write in the uffd reading | |
| 151 | +thread before the ioctl. | |
| 152 | + | |
| 153 | +If you registered with both UFFDIO_REGISTER_MODE_MISSING and | |
| 154 | +UFFDIO_REGISTER_MODE_WP then you need to think about the sequence in | |
| 155 | +which you supply a page and undo write protect. Note that there is a | |
| 156 | +difference between writes into a WP area and into a !WP area. The | |
| 157 | +former will have UFFD_PAGEFAULT_FLAG_WP set, the latter | |
| 158 | +UFFD_PAGEFAULT_FLAG_WRITE. The latter did not fail on protection but | |
| 159 | +you still need to supply a page when UFFDIO_REGISTER_MODE_MISSING was | |
| 160 | +used. | |
| 161 | + | |
| 111 | 162 | QEMU/KVM |
| 112 | 163 | ======== |
| 113 | 164 | |
| @@ -43,7 +43,8 @@ value 1 for supported. · 42 unmodified lines | ||
| 43 | 43 | |
| 44 | 44 | AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance counter. |
| 45 | 45 | When non-masked bits are matching corresponding AXI_ID bits then counter is |
| 46 | − incremented. Perf counter is incremented if | |
| 46 | + incremented. Perf counter is incremented if:: | |
| 47 | + | |
| 47 | 48 | AxID && AXI_MASKING == AXI_ID && AXI_MASKING |
| 48 | 49 | |
| 49 | 50 | This filter doesn't support filter different AXI ID for axid-read and axid-write |
| @@ -0,0 +1,274 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +======================================================= | |
| 4 | +Legacy Documentation of CPU Performance Scaling Drivers | |
| 5 | +======================================================= | |
| 6 | + | |
| 7 | +Included below are historic documents describing assorted | |
| 8 | +:doc:`CPU performance scaling <cpufreq>` drivers. They are reproduced verbatim, | |
| 9 | +with the original white space formatting and indentation preserved, except for | |
| 10 | +the added leading space character in every line of text. | |
| 11 | + | |
| 12 | + | |
| 13 | +AMD PowerNow! Drivers | |
| 14 | +===================== | |
| 15 | + | |
| 16 | +:: | |
| 17 | + | |
| 18 | + PowerNow! and Cool'n'Quiet are AMD names for frequency | |
| 19 | + management capabilities in AMD processors. As the hardware | |
| 20 | + implementation changes in new generations of the processors, | |
| 21 | + there is a different cpu-freq driver for each generation. | |
| 22 | + | |
| 23 | + Note that the driver's will not load on the "wrong" hardware, | |
| 24 | + so it is safe to try each driver in turn when in doubt as to | |
| 25 | + which is the correct driver. | |
| 26 | + | |
| 27 | + Note that the functionality to change frequency (and voltage) | |
| 28 | + is not available in all processors. The drivers will refuse | |
| 29 | + to load on processors without this capability. The capability | |
| 30 | + is detected with the cpuid instruction. | |
| 31 | + | |
| 32 | + The drivers use BIOS supplied tables to obtain frequency and | |
| 33 | + voltage information appropriate for a particular platform. | |
| 34 | + Frequency transitions will be unavailable if the BIOS does | |
| 35 | + not supply these tables. | |
| 36 | + | |
| 37 | + 6th Generation: powernow-k6 | |
| 38 | + | |
| 39 | + 7th Generation: powernow-k7: Athlon, Duron, Geode. | |
| 40 | + | |
| 41 | + 8th Generation: powernow-k8: Athlon, Athlon 64, Opteron, Sempron. | |
| 42 | + Documentation on this functionality in 8th generation processors | |
| 43 | + is available in the "BIOS and Kernel Developer's Guide", publication | |
| 44 | + 26094, in chapter 9, available for download from www.amd.com. | |
| 45 | + | |
| 46 | + BIOS supplied data, for powernow-k7 and for powernow-k8, may be | |
| 47 | + from either the PSB table or from ACPI objects. The ACPI support | |
| 48 | + is only available if the kernel config sets CONFIG_ACPI_PROCESSOR. | |
| 49 | + The powernow-k8 driver will attempt to use ACPI if so configured, | |
| 50 | + and fall back to PST if that fails. | |
| 51 | + The powernow-k7 driver will try to use the PSB support first, and | |
| 52 | + fall back to ACPI if the PSB support fails. A module parameter, | |
| 53 | + acpi_force, is provided to force ACPI support to be used instead | |
| 54 | + of PSB support. | |
| 55 | + | |
| 56 | + | |
| 57 | +``cpufreq-nforce2`` | |
| 58 | +=================== | |
| 59 | + | |
| 60 | +:: | |
| 61 | + | |
| 62 | + The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 platforms. | |
| 63 | + | |
| 64 | + This works better than on other platforms, because the FSB of the CPU | |
| 65 | + can be controlled independently from the PCI/AGP clock. | |
| 66 | + | |
| 67 | + The module has two options: | |
| 68 | + | |
| 69 | + fid: multiplier * 10 (for example 8.5 = 85) | |
| 70 | + min_fsb: minimum FSB | |
| 71 | + | |
| 72 | + If not set, fid is calculated from the current CPU speed and the FSB. | |
| 73 | + min_fsb defaults to FSB at boot time - 50 MHz. | |
| 74 | + | |
| 75 | + IMPORTANT: The available range is limited downwards! | |
| 76 | + Also the minimum available FSB can differ, for systems | |
| 77 | + booting with 200 MHz, 150 should always work. | |
| 78 | + | |
| 79 | + | |
| 80 | +``pcc-cpufreq`` | |
| 81 | +=============== | |
| 82 | + | |
| 83 | +:: | |
| 84 | + | |
| 85 | + /* | |
| 86 | + * pcc-cpufreq.txt - PCC interface documentation | |
| 87 | + * | |
| 88 | + * Copyright (C) 2009 Red Hat, Matthew Garrett <mjg@redhat.com> | |
| 89 | + * Copyright (C) 2009 Hewlett-Packard Development Company, L.P. | |
| 90 | + * Nagananda Chumbalkar <nagananda.chumbalkar@hp.com> | |
| 91 | + */ | |
| 92 | + | |
| 93 | + | |
| 94 | + Processor Clocking Control Driver | |
| 95 | + --------------------------------- | |
| 96 | + | |
| 97 | + Contents: | |
| 98 | + --------- | |
| 99 | + 1. Introduction | |
| 100 | + 1.1 PCC interface | |
| 101 | + 1.1.1 Get Average Frequency | |
| 102 | + 1.1.2 Set Desired Frequency | |
| 103 | + 1.2 Platforms affected | |
| 104 | + 2. Driver and /sys details | |
| 105 | + 2.1 scaling_available_frequencies | |
| 106 | + 2.2 cpuinfo_transition_latency | |
| 107 | + 2.3 cpuinfo_cur_freq | |
| 108 | + 2.4 related_cpus | |
| 109 | + 3. Caveats | |
| 110 | + | |
| 111 | + 1. Introduction: | |
| 112 | + ---------------- | |
| 113 | + Processor Clocking Control (PCC) is an interface between the platform | |
| 114 | + firmware and OSPM. It is a mechanism for coordinating processor | |
| 115 | + performance (ie: frequency) between the platform firmware and the OS. | |
| 116 | + | |
| 117 | + The PCC driver (pcc-cpufreq) allows OSPM to take advantage of the PCC | |
| 118 | + interface. | |
| 119 | + | |
| 120 | + OS utilizes the PCC interface to inform platform firmware what frequency the | |
| 121 | + OS wants for a logical processor. The platform firmware attempts to achieve | |
| 122 | + the requested frequency. If the request for the target frequency could not be | |
| 123 | + satisfied by platform firmware, then it usually means that power budget | |
| 124 | + conditions are in place, and "power capping" is taking place. | |
| 125 | + | |
| 126 | + 1.1 PCC interface: | |
| 127 | + ------------------ | |
| 128 | + The complete PCC specification is available here: | |
| 129 | + https://acpica.org/sites/acpica/files/Processor-Clocking-Control-v1p0.pdf | |
| 130 | + | |
| 131 | + PCC relies on a shared memory region that provides a channel for communication | |
| 132 | + between the OS and platform firmware. PCC also implements a "doorbell" that | |
| 133 | + is used by the OS to inform the platform firmware that a command has been | |
| 134 | + sent. | |
| 135 | + | |
| 136 | + The ACPI PCCH() method is used to discover the location of the PCC shared | |
| 137 | + memory region. The shared memory region header contains the "command" and | |
| 138 | + "status" interface. PCCH() also contains details on how to access the platform | |
| 139 | + doorbell. | |
| 140 | + | |
| 141 | + The following commands are supported by the PCC interface: | |
| 142 | + * Get Average Frequency | |
| 143 | + * Set Desired Frequency | |
| 144 | + | |
| 145 | + The ACPI PCCP() method is implemented for each logical processor and is | |
| 146 | + used to discover the offsets for the input and output buffers in the shared | |
| 147 | + memory region. | |
| 148 | + | |
| 149 | + When PCC mode is enabled, the platform will not expose processor performance | |
| 150 | + or throttle states (_PSS, _TSS and related ACPI objects) to OSPM. Therefore, | |
| 151 | + the native P-state driver (such as acpi-cpufreq for Intel, powernow-k8 for | |
| 152 | + AMD) will not load. | |
| 153 | + | |
| 154 | + However, OSPM remains in control of policy. The governor (eg: "ondemand") | |
| 155 | + computes the required performance for each processor based on server workload. | |
| 156 | + The PCC driver fills in the command interface, and the input buffer and | |
| 157 | + communicates the request to the platform firmware. The platform firmware is | |
| 158 | + responsible for delivering the requested performance. | |
| 159 | + | |
| 160 | + Each PCC command is "global" in scope and can affect all the logical CPUs in | |
| 161 | + the system. Therefore, PCC is capable of performing "group" updates. With PCC | |
| 162 | + the OS is capable of getting/setting the frequency of all the logical CPUs in | |
| 163 | + the system with a single call to the BIOS. | |
| 164 | + | |
| 165 | + 1.1.1 Get Average Frequency: | |
| 166 | + ---------------------------- | |
| 167 | + This command is used by the OSPM to query the running frequency of the | |
| 168 | + processor since the last time this command was completed. The output buffer | |
| 169 | + indicates the average unhalted frequency of the logical processor expressed as | |
| 170 | + a percentage of the nominal (ie: maximum) CPU frequency. The output buffer | |
| 171 | + also signifies if the CPU frequency is limited by a power budget condition. | |
| 172 | + | |
| 173 | + 1.1.2 Set Desired Frequency: | |
| 174 | + ---------------------------- | |
| 175 | + This command is used by the OSPM to communicate to the platform firmware the | |
| 176 | + desired frequency for a logical processor. The output buffer is currently | |
| 177 | + ignored by OSPM. The next invocation of "Get Average Frequency" will inform | |
| 178 | + OSPM if the desired frequency was achieved or not. | |
| 179 | + | |
| 180 | + 1.2 Platforms affected: | |
| 181 | + ----------------------- | |
| 182 | + The PCC driver will load on any system where the platform firmware: | |
| 183 | + * supports the PCC interface, and the associated PCCH() and PCCP() methods | |
| 184 | + * assumes responsibility for managing the hardware clocking controls in order | |
| 185 | + to deliver the requested processor performance | |
| 186 | + | |
| 187 | + Currently, certain HP ProLiant platforms implement the PCC interface. On those | |
| 188 | + platforms PCC is the "default" choice. | |
| 189 | + | |
| 190 | + However, it is possible to disable this interface via a BIOS setting. In | |
| 191 | + such an instance, as is also the case on platforms where the PCC interface | |
| 192 | + is not implemented, the PCC driver will fail to load silently. | |
| 193 | + | |
| 194 | + 2. Driver and /sys details: | |
| 195 | + --------------------------- | |
| 196 | + When the driver loads, it merely prints the lowest and the highest CPU | |
| 197 | + frequencies supported by the platform firmware. | |
| 198 | + | |
| 199 | + The PCC driver loads with a message such as: | |
| 200 | + pcc-cpufreq: (v1.00.00) driver loaded with frequency limits: 1600 MHz, 2933 | |
| 201 | + MHz | |
| 202 | + | |
| 203 | + This means that the OPSM can request the CPU to run at any frequency in | |
| 204 | + between the limits (1600 MHz, and 2933 MHz) specified in the message. | |
| 205 | + | |
| 206 | + Internally, there is no need for the driver to convert the "target" frequency | |
| 207 | + to a corresponding P-state. | |
| 208 | + | |
| 209 | + The VERSION number for the driver will be of the format v.xy.ab. | |
| 210 | + eg: 1.00.02 | |
| 211 | + ----- -- | |
| 212 | + | | | |
| 213 | + | -- this will increase with bug fixes/enhancements to the driver | |
| 214 | + |-- this is the version of the PCC specification the driver adheres to | |
| 215 | + | |
| 216 | + | |
| 217 | + The following is a brief discussion on some of the fields exported via the | |
| 218 | + /sys filesystem and how their values are affected by the PCC driver: | |
| 219 | + | |
| 220 | + 2.1 scaling_available_frequencies: | |
| 221 | + ---------------------------------- | |
| 222 | + scaling_available_frequencies is not created in /sys. No intermediate | |
| 223 | + frequencies need to be listed because the BIOS will try to achieve any | |
| 224 | + frequency, within limits, requested by the governor. A frequency does not have | |
| 225 | + to be strictly associated with a P-state. | |
| 226 | + | |
| 227 | + 2.2 cpuinfo_transition_latency: | |
| 228 | + ------------------------------- | |
| 229 | + The cpuinfo_transition_latency field is 0. The PCC specification does | |
| 230 | + not include a field to expose this value currently. | |
| 231 | + | |
| 232 | + 2.3 cpuinfo_cur_freq: | |
| 233 | + --------------------- | |
| 234 | + A) Often cpuinfo_cur_freq will show a value different than what is declared | |
| 235 | + in the scaling_available_frequencies or scaling_cur_freq, or scaling_max_freq. | |
| 236 | + This is due to "turbo boost" available on recent Intel processors. If certain | |
| 237 | + conditions are met the BIOS can achieve a slightly higher speed than requested | |
| 238 | + by OSPM. An example: | |
| 239 | + | |
| 240 | + scaling_cur_freq : 2933000 | |
| 241 | + cpuinfo_cur_freq : 3196000 | |
| 242 | + | |
| 243 | + B) There is a round-off error associated with the cpuinfo_cur_freq value. | |
| 244 | + Since the driver obtains the current frequency as a "percentage" (%) of the | |
| 245 | + nominal frequency from the BIOS, sometimes, the values displayed by | |
| 246 | + scaling_cur_freq and cpuinfo_cur_freq may not match. An example: | |
| 247 | + | |
| 248 | + scaling_cur_freq : 1600000 | |
| 249 | + cpuinfo_cur_freq : 1583000 | |
| 250 | + | |
| 251 | + In this example, the nominal frequency is 2933 MHz. The driver obtains the | |
| 252 | + current frequency, cpuinfo_cur_freq, as 54% of the nominal frequency: | |
| 253 | + | |
| 254 | + 54% of 2933 MHz = 1583 MHz | |
| 255 | + | |
| 256 | + Nominal frequency is the maximum frequency of the processor, and it usually | |
| 257 | + corresponds to the frequency of the P0 P-state. | |
| 258 | + | |
| 259 | + 2.4 related_cpus: | |
| 260 | + ----------------- | |
| 261 | + The related_cpus field is identical to affected_cpus. | |
| 262 | + | |
| 263 | + affected_cpus : 4 | |
| 264 | + related_cpus : 4 | |
| 265 | + | |
| 266 | + Currently, the PCC driver does not evaluate _PSD. The platforms that support | |
| 267 | + PCC do not implement SW_ALL. So OSPM doesn't need to perform any coordination | |
| 268 | + to ensure that the same frequency is requested of all dependent CPUs. | |
| 269 | + | |
| 270 | + 3. Caveats: | |
| 271 | + ----------- | |
| 272 | + The "cpufreq_stats" module in its present form cannot be loaded and | |
| 273 | + expected to work with the PCC driver. Since the "cpufreq_stats" module | |
| 274 | + provides information wrt each P-state, it is not applicable to the PCC driver. | |
| @@ -583,20 +583,17 @@ Power Management Quality of Service for CPUs · 582 unmodified lines | ||
| 583 | 583 | The power management quality of service (PM QoS) framework in the Linux kernel |
| 584 | 584 | allows kernel code and user space processes to set constraints on various |
| 585 | 585 | energy-efficiency features of the kernel to prevent performance from dropping |
| 586 | −below a required level. The PM QoS constraints can be set globally, in | |
| 587 | −predefined categories referred to as PM QoS classes, or against individual | |
| 588 | −devices. | |
| 586 | +below a required level. | |
| 589 | 587 | |
| 590 | 588 | CPU idle time management can be affected by PM QoS in two ways, through the |
| 591 | −global constraint in the ``PM_QOS_CPU_DMA_LATENCY`` class and through the | |
| 592 | −resume latency constraints for individual CPUs. Kernel code (e.g. device | |
| 593 | −drivers) can set both of them with the help of special internal interfaces | |
| 594 | −provided by the PM QoS framework. User space can modify the former by opening | |
| 595 | −the :file:`cpu_dma_latency` special device file under :file:`/dev/` and writing | |
| 596 | −a binary value (interpreted as a signed 32-bit integer) to it. In turn, the | |
| 597 | −resume latency constraint for a CPU can be modified by user space by writing a | |
| 598 | −string (representing a signed 32-bit integer) to the | |
| 599 | −:file:`power/pm_qos_resume_latency_us` file under | |
| 589 | +global CPU latency limit and through the resume latency constraints for | |
| 590 | +individual CPUs. Kernel code (e.g. device drivers) can set both of them with | |
| 591 | +the help of special internal interfaces provided by the PM QoS framework. User | |
| 592 | +space can modify the former by opening the :file:`cpu_dma_latency` special | |
| 593 | +device file under :file:`/dev/` and writing a binary value (interpreted as a | |
| 594 | +signed 32-bit integer) to it. In turn, the resume latency constraint for a CPU | |
| 595 | +can be modified from user space by writing a string (representing a signed | |
| 596 | +32-bit integer) to the :file:`power/pm_qos_resume_latency_us` file under | |
| 600 | 597 | :file:`/sys/devices/system/cpu/cpu<N>/` in ``sysfs``, where the CPU number |
| 601 | 598 | ``<N>`` is allocated at the system initialization time. Negative values |
| 602 | 599 | will be rejected in both cases and, also in both cases, the written integer |
| @@ -605,32 +602,34 @@ number will be interpreted as a requested PM QoS constraint in microseconds. · 2 unmodified lines | ||
| 605 | 602 | The requested value is not automatically applied as a new constraint, however, |
| 606 | 603 | as it may be less restrictive (greater in this particular case) than another |
| 607 | 604 | constraint previously requested by someone else. For this reason, the PM QoS |
| 608 | −framework maintains a list of requests that have been made so far in each | |
| 609 | −global class and for each device, aggregates them and applies the effective | |
| 610 | −(minimum in this particular case) value as the new constraint. | |
| 605 | +framework maintains a list of requests that have been made so far for the | |
| 606 | +global CPU latency limit and for each individual CPU, aggregates them and | |
| 607 | +applies the effective (minimum in this particular case) value as the new | |
| 608 | +constraint. | |
| 611 | 609 | |
| 612 | 610 | In fact, opening the :file:`cpu_dma_latency` special device file causes a new |
| 613 | −PM QoS request to be created and added to the priority list of requests in the | |
| 614 | −``PM_QOS_CPU_DMA_LATENCY`` class and the file descriptor coming from the | |
| 615 | −"open" operation represents that request. If that file descriptor is then | |
| 616 | −used for writing, the number written to it will be associated with the PM QoS | |
| 617 | −request represented by it as a new requested constraint value. Next, the | |
| 618 | −priority list mechanism will be used to determine the new effective value of | |
| 619 | −the entire list of requests and that effective value will be set as a new | |
| 620 | −constraint. Thus setting a new requested constraint value will only change the | |
| 621 | −real constraint if the effective "list" value is affected by it. In particular, | |
| 622 | −for the ``PM_QOS_CPU_DMA_LATENCY`` class it only affects the real constraint if | |
| 623 | −it is the minimum of the requested constraints in the list. The process holding | |
| 624 | −a file descriptor obtained by opening the :file:`cpu_dma_latency` special device | |
| 625 | −file controls the PM QoS request associated with that file descriptor, but it | |
| 626 | −controls this particular PM QoS request only. | |
| 611 | +PM QoS request to be created and added to a global priority list of CPU latency | |
| 612 | +limit requests and the file descriptor coming from the "open" operation | |
| 613 | +represents that request. If that file descriptor is then used for writing, the | |
| 614 | +number written to it will be associated with the PM QoS request represented by | |
| 615 | +it as a new requested limit value. Next, the priority list mechanism will be | |
| 616 | +used to determine the new effective value of the entire list of requests and | |
| 617 | +that effective value will be set as a new CPU latency limit. Thus requesting a | |
| 618 | +new limit value will only change the real limit if the effective "list" value is | |
| 619 | +affected by it, which is the case if it is the minimum of the requested values | |
| 620 | +in the list. | |
| 621 | + | |
| 622 | +The process holding a file descriptor obtained by opening the | |
| 623 | +:file:`cpu_dma_latency` special device file controls the PM QoS request | |
| 624 | +associated with that file descriptor, but it controls this particular PM QoS | |
| 625 | +request only. | |
| 627 | 626 | |
| 628 | 627 | Closing the :file:`cpu_dma_latency` special device file or, more precisely, the |
| 629 | 628 | file descriptor obtained while opening it, causes the PM QoS request associated |
| 630 | −with that file descriptor to be removed from the ``PM_QOS_CPU_DMA_LATENCY`` | |
| 631 | −class priority list and destroyed. If that happens, the priority list mechanism | |
| 632 | −will be used, again, to determine the new effective value for the whole list | |
| 633 | −and that value will become the new real constraint. | |
| 629 | +with that file descriptor to be removed from the global priority list of CPU | |
| 630 | +latency limit requests and destroyed. If that happens, the priority list | |
| 631 | +mechanism will be used again, to determine the new effective value for the whole | |
| 632 | +list and that value will become the new limit. | |
| 634 | 633 | |
| 635 | 634 | In turn, for each CPU there is one resume latency PM QoS request associated with |
| 636 | 635 | the :file:`power/pm_qos_resume_latency_us` file under |
| @@ -647,10 +646,10 @@ CPU in question every time the list of requests is updated this way or another · 10 unmodified lines | ||
| 647 | 646 | (there may be other requests coming from kernel code in that list). |
| 648 | 647 | |
| 649 | 648 | CPU idle time governors are expected to regard the minimum of the global |
| 650 | −effective ``PM_QOS_CPU_DMA_LATENCY`` class constraint and the effective | |
| 651 | −resume latency constraint for the given CPU as the upper limit for the exit | |
| 652 | −latency of the idle states they can select for that CPU. They should never | |
| 653 | −select any idle states with exit latency beyond that limit. | |
| 649 | +(effective) CPU latency limit and the effective resume latency constraint for | |
| 650 | +the given CPU as the upper limit for the exit latency of the idle states that | |
| 651 | +they are allowed to select for that CPU. They should never select any idle | |
| 652 | +states with exit latency beyond that limit. | |
| 654 | 653 | |
| 655 | 654 | |
| 656 | 655 | Idle States Control Via Kernel Command Line |
| @@ -734,10 +734,10 @@ References · 733 unmodified lines | ||
| 734 | 734 | ========== |
| 735 | 735 | |
| 736 | 736 | .. [1] Kristen Accardi, *Balancing Power and Performance in the Linux Kernel*, |
| 737 | − http://events.linuxfoundation.org/sites/events/files/slides/LinuxConEurope_2015.pdf | |
| 737 | + https://events.static.linuxfound.org/sites/events/files/slides/LinuxConEurope_2015.pdf | |
| 738 | 738 | |
| 739 | 739 | .. [2] *Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3: System Programming Guide*, |
| 740 | − http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-system-programming-manual-325384.html | |
| 740 | + https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-system-programming-manual-325384.html | |
| 741 | 741 | |
| 742 | 742 | .. [3] *Advanced Configuration and Power Interface Specification*, |
| 743 | 743 | https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf |
| @@ -0,0 +1,270 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | +.. include:: <isonum.txt> | |
| 3 | + | |
| 4 | +========================= | |
| 5 | +System Suspend Code Flows | |
| 6 | +========================= | |
| 7 | + | |
| 8 | +:Copyright: |copy| 2020 Intel Corporation | |
| 9 | + | |
| 10 | +:Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> | |
| 11 | + | |
| 12 | +At least one global system-wide transition needs to be carried out for the | |
| 13 | +system to get from the working state into one of the supported | |
| 14 | +:doc:`sleep states <sleep-states>`. Hibernation requires more than one | |
| 15 | +transition to occur for this purpose, but the other sleep states, commonly | |
| 16 | +referred to as *system-wide suspend* (or simply *system suspend*) states, need | |
| 17 | +only one. | |
| 18 | + | |
| 19 | +For those sleep states, the transition from the working state of the system into | |
| 20 | +the target sleep state is referred to as *system suspend* too (in the majority | |
| 21 | +of cases, whether this means a transition or a sleep state of the system should | |
| 22 | +be clear from the context) and the transition back from the sleep state into the | |
| 23 | +working state is referred to as *system resume*. | |
| 24 | + | |
| 25 | +The kernel code flows associated with the suspend and resume transitions for | |
| 26 | +different sleep states of the system are quite similar, but there are some | |
| 27 | +significant differences between the :ref:`suspend-to-idle <s2idle>` code flows | |
| 28 | +and the code flows related to the :ref:`suspend-to-RAM <s2ram>` and | |
| 29 | +:ref:`standby <standby>` sleep states. | |
| 30 | + | |
| 31 | +The :ref:`suspend-to-RAM <s2ram>` and :ref:`standby <standby>` sleep states | |
| 32 | +cannot be implemented without platform support and the difference between them | |
| 33 | +boils down to the platform-specific actions carried out by the suspend and | |
| 34 | +resume hooks that need to be provided by the platform driver to make them | |
| 35 | +available. Apart from that, the suspend and resume code flows for these sleep | |
| 36 | +states are mostly identical, so they both together will be referred to as | |
| 37 | +*platform-dependent suspend* states in what follows. | |
| 38 | + | |
| 39 | + | |
| 40 | +.. _s2idle_suspend: | |
| 41 | + | |
| 42 | +Suspend-to-idle Suspend Code Flow | |
| 43 | +================================= | |
| 44 | + | |
| 45 | +The following steps are taken in order to transition the system from the working | |
| 46 | +state to the :ref:`suspend-to-idle <s2idle>` sleep state: | |
| 47 | + | |
| 48 | + 1. Invoking system-wide suspend notifiers. | |
| 49 | + | |
| 50 | + Kernel subsystems can register callbacks to be invoked when the suspend | |
| 51 | + transition is about to occur and when the resume transition has finished. | |
| 52 | + | |
| 53 | + That allows them to prepare for the change of the system state and to clean | |
| 54 | + up after getting back to the working state. | |
| 55 | + | |
| 56 | + 2. Freezing tasks. | |
| 57 | + | |
| 58 | + Tasks are frozen primarily in order to avoid unchecked hardware accesses | |
| 59 | + from user space through MMIO regions or I/O registers exposed directly to | |
| 60 | + it and to prevent user space from entering the kernel while the next step | |
| 61 | + of the transition is in progress (which might have been problematic for | |
| 62 | + various reasons). | |
| 63 | + | |
| 64 | + All user space tasks are intercepted as though they were sent a signal and | |
| 65 | + put into uninterruptible sleep until the end of the subsequent system resume | |
| 66 | + transition. | |
| 67 | + | |
| 68 | + The kernel threads that choose to be frozen during system suspend for | |
| 69 | + specific reasons are frozen subsequently, but they are not intercepted. | |
| 70 | + Instead, they are expected to periodically check whether or not they need | |
| 71 | + to be frozen and to put themselves into uninterruptible sleep if so. [Note, | |
| 72 | + however, that kernel threads can use locking and other concurrency controls | |
| 73 | + available in kernel space to synchronize themselves with system suspend and | |
| 74 | + resume, which can be much more precise than the freezing, so the latter is | |
| 75 | + not a recommended option for kernel threads.] | |
| 76 | + | |
| 77 | + 3. Suspending devices and reconfiguring IRQs. | |
| 78 | + | |
| 79 | + Devices are suspended in four phases called *prepare*, *suspend*, | |
| 80 | + *late suspend* and *noirq suspend* (see :ref:`driverapi_pm_devices` for more | |
| 81 | + information on what exactly happens in each phase). | |
| 82 | + | |
| 83 | + Every device is visited in each phase, but typically it is not physically | |
| 84 | + accessed in more than two of them. | |
| 85 | + | |
| 86 | + The runtime PM API is disabled for every device during the *late* suspend | |
| 87 | + phase and high-level ("action") interrupt handlers are prevented from being | |
| 88 | + invoked before the *noirq* suspend phase. | |
| 89 | + | |
| 90 | + Interrupts are still handled after that, but they are only acknowledged to | |
| 91 | + interrupt controllers without performing any device-specific actions that | |
| 92 | + would be triggered in the working state of the system (those actions are | |
| 93 | + deferred till the subsequent system resume transition as described | |
| 94 | + `below <s2idle_resume_>`_). | |
| 95 | + | |
| 96 | + IRQs associated with system wakeup devices are "armed" so that the resume | |
| 97 | + transition of the system is started when one of them signals an event. | |
| 98 | + | |
| 99 | + 4. Freezing the scheduler tick and suspending timekeeping. | |
| 100 | + | |
| 101 | + When all devices have been suspended, CPUs enter the idle loop and are put | |
| 102 | + into the deepest available idle state. While doing that, each of them | |
| 103 | + "freezes" its own scheduler tick so that the timer events associated with | |
| 104 | + the tick do not occur until the CPU is woken up by another interrupt source. | |
| 105 | + | |
| 106 | + The last CPU to enter the idle state also stops the timekeeping which | |
| 107 | + (among other things) prevents high resolution timers from triggering going | |
| 108 | + forward until the first CPU that is woken up restarts the timekeeping. | |
| 109 | + That allows the CPUs to stay in the deep idle state relatively long in one | |
| 110 | + go. | |
| 111 | + | |
| 112 | + From this point on, the CPUs can only be woken up by non-timer hardware | |
| 113 | + interrupts. If that happens, they go back to the idle state unless the | |
| 114 | + interrupt that woke up one of them comes from an IRQ that has been armed for | |
| 115 | + system wakeup, in which case the system resume transition is started. | |
| 116 | + | |
| 117 | + | |
| 118 | +.. _s2idle_resume: | |
| 119 | + | |
| 120 | +Suspend-to-idle Resume Code Flow | |
| 121 | +================================ | |
| 122 | + | |
| 123 | +The following steps are taken in order to transition the system from the | |
| 124 | +:ref:`suspend-to-idle <s2idle>` sleep state into the working state: | |
| 125 | + | |
| 126 | + 1. Resuming timekeeping and unfreezing the scheduler tick. | |
| 127 | + | |
| 128 | + When one of the CPUs is woken up (by a non-timer hardware interrupt), it | |
| 129 | + leaves the idle state entered in the last step of the preceding suspend | |
| 130 | + transition, restarts the timekeeping (unless it has been restarted already | |
| 131 | + by another CPU that woke up earlier) and the scheduler tick on that CPU is | |
| 132 | + unfrozen. | |
| 133 | + | |
| 134 | + If the interrupt that has woken up the CPU was armed for system wakeup, | |
| 135 | + the system resume transition begins. | |
| 136 | + | |
| 137 | + 2. Resuming devices and restoring the working-state configuration of IRQs. | |
| 138 | + | |
| 139 | + Devices are resumed in four phases called *noirq resume*, *early resume*, | |
| 140 | + *resume* and *complete* (see :ref:`driverapi_pm_devices` for more | |
| 141 | + information on what exactly happens in each phase). | |
| 142 | + | |
| 143 | + Every device is visited in each phase, but typically it is not physically | |
| 144 | + accessed in more than two of them. | |
| 145 | + | |
| 146 | + The working-state configuration of IRQs is restored after the *noirq* resume | |
| 147 | + phase and the runtime PM API is re-enabled for every device whose driver | |
| 148 | + supports it during the *early* resume phase. | |
| 149 | + | |
| 150 | + 3. Thawing tasks. | |
| 151 | + | |
| 152 | + Tasks frozen in step 2 of the preceding `suspend <s2idle_suspend_>`_ | |
| 153 | + transition are "thawed", which means that they are woken up from the | |
| 154 | + uninterruptible sleep that they went into at that time and user space tasks | |
| 155 | + are allowed to exit the kernel. | |
| 156 | + | |
| 157 | + 4. Invoking system-wide resume notifiers. | |
| 158 | + | |
| 159 | + This is analogous to step 1 of the `suspend <s2idle_suspend_>`_ transition | |
| 160 | + and the same set of callbacks is invoked at this point, but a different | |
| 161 | + "notification type" parameter value is passed to them. | |
| 162 | + | |
| 163 | + | |
| 164 | +Platform-dependent Suspend Code Flow | |
| 165 | +==================================== | |
| 166 | + | |
| 167 | +The following steps are taken in order to transition the system from the working | |
| 168 | +state to platform-dependent suspend state: | |
| 169 | + | |
| 170 | + 1. Invoking system-wide suspend notifiers. | |
| 171 | + | |
| 172 | + This step is the same as step 1 of the suspend-to-idle suspend transition | |
| 173 | + described `above <s2idle_suspend_>`_. | |
| 174 | + | |
| 175 | + 2. Freezing tasks. | |
| 176 | + | |
| 177 | + This step is the same as step 2 of the suspend-to-idle suspend transition | |
| 178 | + described `above <s2idle_suspend_>`_. | |
| 179 | + | |
| 180 | + 3. Suspending devices and reconfiguring IRQs. | |
| 181 | + | |
| 182 | + This step is analogous to step 3 of the suspend-to-idle suspend transition | |
| 183 | + described `above <s2idle_suspend_>`_, but the arming of IRQs for system | |
| 184 | + wakeup generally does not have any effect on the platform. | |
| 185 | + | |
| 186 | + There are platforms that can go into a very deep low-power state internally | |
| 187 | + when all CPUs in them are in sufficiently deep idle states and all I/O | |
| 188 | + devices have been put into low-power states. On those platforms, | |
| 189 | + suspend-to-idle can reduce system power very effectively. | |
| 190 | + | |
| 191 | + On the other platforms, however, low-level components (like interrupt | |
| 192 | + controllers) need to be turned off in a platform-specific way (implemented | |
| 193 | + in the hooks provided by the platform driver) to achieve comparable power | |
| 194 | + reduction. | |
| 195 | + | |
| 196 | + That usually prevents in-band hardware interrupts from waking up the system, | |
| 197 | + which must be done in a special platform-dependent way. Then, the | |
| 198 | + configuration of system wakeup sources usually starts when system wakeup | |
| 199 | + devices are suspended and is finalized by the platform suspend hooks later | |
| 200 | + on. | |
| 201 | + | |
| 202 | + 4. Disabling non-boot CPUs. | |
| 203 | + | |
| 204 | + On some platforms the suspend hooks mentioned above must run in a one-CPU | |
| 205 | + configuration of the system (in particular, the hardware cannot be accessed | |
| 206 | + by any code running in parallel with the platform suspend hooks that may, | |
| 207 | + and often do, trap into the platform firmware in order to finalize the | |
| 208 | + suspend transition). | |
| 209 | + | |
| 210 | + For this reason, the CPU offline/online (CPU hotplug) framework is used | |
| 211 | + to take all of the CPUs in the system, except for one (the boot CPU), | |
| 212 | + offline (typically, the CPUs that have been taken offline go into deep idle | |
| 213 | + states). | |
| 214 | + | |
| 215 | + This means that all tasks are migrated away from those CPUs and all IRQs are | |
| 216 | + rerouted to the only CPU that remains online. | |
| 217 | + | |
| 218 | + 5. Suspending core system components. | |
| 219 | + | |
| 220 | + This prepares the core system components for (possibly) losing power going | |
| 221 | + forward and suspends the timekeeping. | |
| 222 | + | |
| 223 | + 6. Platform-specific power removal. | |
| 224 | + | |
| 225 | + This is expected to remove power from all of the system components except | |
| 226 | + for the memory controller and RAM (in order to preserve the contents of the | |
| 227 | + latter) and some devices designated for system wakeup. | |
| 228 | + | |
| 229 | + In many cases control is passed to the platform firmware which is expected | |
| 230 | + to finalize the suspend transition as needed. | |
| 231 | + | |
| 232 | + | |
| 233 | +Platform-dependent Resume Code Flow | |
| 234 | +=================================== | |
| 235 | + | |
| 236 | +The following steps are taken in order to transition the system from a | |
| 237 | +platform-dependent suspend state into the working state: | |
| 238 | + | |
| 239 | + 1. Platform-specific system wakeup. | |
| 240 | + | |
| 241 | + The platform is woken up by a signal from one of the designated system | |
| 242 | + wakeup devices (which need not be an in-band hardware interrupt) and | |
| 243 | + control is passed back to the kernel (the working configuration of the | |
| 244 | + platform may need to be restored by the platform firmware before the | |
| 245 | + kernel gets control again). | |
| 246 | + | |
| 247 | + 2. Resuming core system components. | |
| 248 | + | |
| 249 | + The suspend-time configuration of the core system components is restored and | |
| 250 | + the timekeeping is resumed. | |
| 251 | + | |
| 252 | + 3. Re-enabling non-boot CPUs. | |
| 253 | + | |
| 254 | + The CPUs disabled in step 4 of the preceding suspend transition are taken | |
| 255 | + back online and their suspend-time configuration is restored. | |
| 256 | + | |
| 257 | + 4. Resuming devices and restoring the working-state configuration of IRQs. | |
| 258 | + | |
| 259 | + This step is the same as step 2 of the suspend-to-idle suspend transition | |
| 260 | + described `above <s2idle_resume_>`_. | |
| 261 | + | |
| 262 | + 5. Thawing tasks. | |
| 263 | + | |
| 264 | + This step is the same as step 3 of the suspend-to-idle suspend transition | |
| 265 | + described `above <s2idle_resume_>`_. | |
| 266 | + | |
| 267 | + 6. Invoking system-wide resume notifiers. | |
| 268 | + | |
| 269 | + This step is the same as step 4 of the suspend-to-idle suspend transition | |
| 270 | + described `above <s2idle_resume_>`_. | |
| @@ -8,3 +8,4 @@ System-Wide Power Management · 7 unmodified lines | ||
| 8 | 8 | :maxdepth: 2 |
| 9 | 9 | |
| 10 | 10 | sleep-states |
| 11 | + suspend-flows | |
| @@ -11,4 +11,5 @@ Working-State Power Management · 10 unmodified lines | ||
| 11 | 11 | intel_idle |
| 12 | 12 | cpufreq |
| 13 | 13 | intel_pstate |
| 14 | + cpufreq_drivers | |
| 14 | 15 | intel_epb |
| @@ -2,262 +2,197 @@ · 1 unmodified line | ||
| 2 | 2 | Documentation for /proc/sys/kernel/ |
| 3 | 3 | =================================== |
| 4 | 4 | |
| 5 | −kernel version 2.2.10 | |
| 5 | +.. See scripts/check-sysctl-docs to keep this up to date | |
| 6 | + | |
| 6 | 7 | |
| 7 | 8 | Copyright (c) 1998, 1999, Rik van Riel <riel@nl.linux.org> |
| 8 | 9 | |
| 9 | 10 | Copyright (c) 2009, Shen Feng<shen@cn.fujitsu.com> |
| 10 | 11 | |
| 11 | −For general info and legal blurb, please look in index.rst. | |
| 12 | +For general info and legal blurb, please look in :doc:`index`. | |
| 12 | 13 | |
| 13 | 14 | ------------------------------------------------------------------------------ |
| 14 | 15 | |
| 15 | 16 | This file contains documentation for the sysctl files in |
| 16 | −/proc/sys/kernel/ and is valid for Linux kernel version 2.2. | |
| 17 | +``/proc/sys/kernel/`` and is valid for Linux kernel version 2.2. | |
| 17 | 18 | |
| 18 | 19 | The files in this directory can be used to tune and monitor |
| 19 | 20 | miscellaneous and general things in the operation of the Linux |
| 20 | −kernel. Since some of the files _can_ be used to screw up your | |
| 21 | +kernel. Since some of the files *can* be used to screw up your | |
| 21 | 22 | system, it is advisable to read both documentation and source |
| 22 | 23 | before actually making adjustments. |
| 23 | 24 | |
| 24 | 25 | Currently, these files might (depending on your configuration) |
| 25 | −show up in /proc/sys/kernel: | |
| 26 | − | |
| 27 | −- acct | |
| 28 | −- acpi_video_flags | |
| 29 | −- auto_msgmni | |
| 30 | −- bootloader_type [ X86 only ] | |
| 31 | −- bootloader_version [ X86 only ] | |
| 32 | −- cap_last_cap | |
| 33 | −- core_pattern | |
| 34 | −- core_pipe_limit | |
| 35 | −- core_uses_pid | |
| 36 | −- ctrl-alt-del | |
| 37 | −- dmesg_restrict | |
| 38 | −- domainname | |
| 39 | −- hostname | |
| 40 | −- hotplug | |
| 41 | −- hardlockup_all_cpu_backtrace | |
| 42 | −- hardlockup_panic | |
| 43 | −- hung_task_panic | |
| 44 | −- hung_task_check_count | |
| 45 | −- hung_task_timeout_secs | |
| 46 | −- hung_task_check_interval_secs | |
| 47 | −- hung_task_warnings | |
| 48 | −- hyperv_record_panic_msg | |
| 49 | −- kexec_load_disabled | |
| 50 | −- kptr_restrict | |
| 51 | −- l2cr [ PPC only ] | |
| 52 | −- modprobe ==> Documentation/debugging-modules.txt | |
| 53 | −- modules_disabled | |
| 54 | −- msg_next_id [ sysv ipc ] | |
| 55 | −- msgmax | |
| 56 | −- msgmnb | |
| 57 | −- msgmni | |
| 58 | −- nmi_watchdog | |
| 59 | −- osrelease | |
| 60 | −- ostype | |
| 61 | −- overflowgid | |
| 62 | −- overflowuid | |
| 63 | −- panic | |
| 64 | −- panic_on_oops | |
| 65 | −- panic_on_stackoverflow | |
| 66 | −- panic_on_unrecovered_nmi | |
| 67 | −- panic_on_warn | |
| 68 | −- panic_print | |
| 69 | −- panic_on_rcu_stall | |
| 70 | −- perf_cpu_time_max_percent | |
| 71 | −- perf_event_paranoid | |
| 72 | −- perf_event_max_stack | |
| 73 | −- perf_event_mlock_kb | |
| 74 | −- perf_event_max_contexts_per_stack | |
| 75 | −- pid_max | |
| 76 | −- powersave-nap [ PPC only ] | |
| 77 | −- printk | |
| 78 | −- printk_delay | |
| 79 | −- printk_ratelimit | |
| 80 | −- printk_ratelimit_burst | |
| 81 | −- pty ==> Documentation/filesystems/devpts.txt | |
| 82 | −- randomize_va_space | |
| 83 | −- real-root-dev ==> Documentation/admin-guide/initrd.rst | |
| 84 | −- reboot-cmd [ SPARC only ] | |
| 85 | −- rtsig-max | |
| 86 | −- rtsig-nr | |
| 87 | −- sched_energy_aware | |
| 88 | −- seccomp/ ==> Documentation/userspace-api/seccomp_filter.rst | |
| 89 | −- sem | |
| 90 | −- sem_next_id [ sysv ipc ] | |
| 91 | −- sg-big-buff [ generic SCSI device (sg) ] | |
| 92 | −- shm_next_id [ sysv ipc ] | |
| 93 | −- shm_rmid_forced | |
| 94 | −- shmall | |
| 95 | −- shmmax [ sysv ipc ] | |
| 96 | −- shmmni | |
| 97 | −- softlockup_all_cpu_backtrace | |
| 98 | −- soft_watchdog | |
| 99 | −- stack_erasing | |
| 100 | −- stop-a [ SPARC only ] | |
| 101 | −- sysrq ==> Documentation/admin-guide/sysrq.rst | |
| 102 | −- sysctl_writes_strict | |
| 103 | −- tainted ==> Documentation/admin-guide/tainted-kernels.rst | |
| 104 | −- threads-max | |
| 105 | −- unknown_nmi_panic | |
| 106 | −- watchdog | |
| 107 | −- watchdog_thresh | |
| 108 | −- version | |
| 109 | − | |
| 110 | − | |
| 111 | −acct: | |
| 112 | −===== | |
| 26 | +show up in ``/proc/sys/kernel``: | |
| 27 | + | |
| 28 | +.. contents:: :local: | |
| 29 | + | |
| 30 | + | |
| 31 | +acct | |
| 32 | +==== | |
| 33 | + | |
| 34 | +:: | |
| 113 | 35 | |
| 114 | −highwater lowwater frequency | |
| 36 | + highwater lowwater frequency | |
| 115 | 37 | |
| 116 | 38 | If BSD-style process accounting is enabled these values control |
| 117 | 39 | its behaviour. If free space on filesystem where the log lives |
| 118 | −goes below <lowwater>% accounting suspends. If free space gets | |
| 119 | −above <highwater>% accounting resumes. <Frequency> determines | |
| 40 | +goes below ``lowwater``% accounting suspends. If free space gets | |
| 41 | +above ``highwater``% accounting resumes. ``frequency`` determines | |
| 120 | 42 | how often do we check the amount of free space (value is in |
| 121 | 43 | seconds). Default: |
| 122 | −4 2 30 | |
| 123 | −That is, suspend accounting if there left <= 2% free; resume it | |
| 124 | −if we got >=4%; consider information about amount of free space | |
| 125 | −valid for 30 seconds. | |
| 126 | 44 | |
| 45 | +:: | |
| 127 | 46 | |
| 128 | −acpi_video_flags: | |
| 129 | −================= | |
| 47 | + 4 2 30 | |
| 48 | + | |
| 49 | +That is, suspend accounting if free space drops below 2%; resume it | |
| 50 | +if it increases to at least 4%; consider information about amount of | |
| 51 | +free space valid for 30 seconds. | |
| 130 | 52 | |
| 131 | −flags | |
| 132 | 53 | |
| 133 | −See Doc*/kernel/power/video.txt, it allows mode of video boot to be | |
| 134 | −set during run time. | |
| 54 | +acpi_video_flags | |
| 55 | +================ | |
| 135 | 56 | |
| 57 | +See :doc:`/power/video`. This allows the video resume mode to be set, | |
| 58 | +in a similar fashion to the ``acpi_sleep`` kernel parameter, by | |
| 59 | +combining the following values: | |
| 60 | + | |
| 61 | += ======= | |
| 62 | +1 s3_bios | |
| 63 | +2 s3_mode | |
| 64 | +4 s3_beep | |
| 65 | += ======= | |
| 136 | 66 | |
| 137 | −auto_msgmni: | |
| 138 | −============ | |
| 67 | + | |
| 68 | +auto_msgmni | |
| 69 | +=========== | |
| 139 | 70 | |
| 140 | 71 | This variable has no effect and may be removed in future kernel |
| 141 | 72 | releases. Reading it always returns 0. |
| 142 | −Up to Linux 3.17, it enabled/disabled automatic recomputing of msgmni | |
| 143 | −upon memory add/remove or upon ipc namespace creation/removal. | |
| 73 | +Up to Linux 3.17, it enabled/disabled automatic recomputing of | |
| 74 | +`msgmni`_ | |
| 75 | +upon memory add/remove or upon IPC namespace creation/removal. | |
| 144 | 76 | Echoing "1" into this file enabled msgmni automatic recomputing. |
| 145 | −Echoing "0" turned it off. auto_msgmni default value was 1. | |
| 146 | − | |
| 77 | +Echoing "0" turned it off. The default value was 1. | |
| 147 | 78 | |
| 148 | −bootloader_type: | |
| 149 | −================ | |
| 150 | 79 | |
| 151 | −x86 bootloader identification | |
| 80 | +bootloader_type (x86 only) | |
| 81 | +========================== | |
| 152 | 82 | |
| 153 | 83 | This gives the bootloader type number as indicated by the bootloader, |
| 154 | 84 | shifted left by 4, and OR'd with the low four bits of the bootloader |
| 155 | 85 | version. The reason for this encoding is that this used to match the |
| 156 | −type_of_loader field in the kernel header; the encoding is kept for | |
| 86 | +``type_of_loader`` field in the kernel header; the encoding is kept for | |
| 157 | 87 | backwards compatibility. That is, if the full bootloader type number |
| 158 | 88 | is 0x15 and the full version number is 0x234, this file will contain |
| 159 | 89 | the value 340 = 0x154. |
| 160 | 90 | |
| 161 | −See the type_of_loader and ext_loader_type fields in | |
| 162 | −Documentation/x86/boot.rst for additional information. | |
| 91 | +See the ``type_of_loader`` and ``ext_loader_type`` fields in | |
| 92 | +:doc:`/x86/boot` for additional information. | |
| 163 | 93 | |
| 164 | 94 | |
| 165 | −bootloader_version: | |
| 166 | −=================== | |
| 167 | − | |
| 168 | −x86 bootloader version | |
| 95 | +bootloader_version (x86 only) | |
| 96 | +============================= | |
| 169 | 97 | |
| 170 | 98 | The complete bootloader version number. In the example above, this |
| 171 | 99 | file will contain the value 564 = 0x234. |
| 172 | 100 | |
| 173 | −See the type_of_loader and ext_loader_ver fields in | |
| 174 | −Documentation/x86/boot.rst for additional information. | |
| 101 | +See the ``type_of_loader`` and ``ext_loader_ver`` fields in | |
| 102 | +:doc:`/x86/boot` for additional information. | |
| 175 | 103 | |
| 176 | 104 | |
| 177 | −cap_last_cap: | |
| 178 | −============= | |
| 105 | +cap_last_cap | |
| 106 | +============ | |
| 179 | 107 | |
| 180 | 108 | Highest valid capability of the running kernel. Exports |
| 181 | −CAP_LAST_CAP from the kernel. | |
| 109 | +``CAP_LAST_CAP`` from the kernel. | |
| 182 | 110 | |
| 183 | 111 | |
| 184 | −core_pattern: | |
| 185 | −============= | |
| 112 | +core_pattern | |
| 113 | +============ | |
| 186 | 114 | |
| 187 | −core_pattern is used to specify a core dumpfile pattern name. | |
| 115 | +``core_pattern`` is used to specify a core dumpfile pattern name. | |
| 188 | 116 | |
| 189 | 117 | * max length 127 characters; default value is "core" |
| 190 | −* core_pattern is used as a pattern template for the output filename; | |
| 191 | − certain string patterns (beginning with '%') are substituted with | |
| 192 | − their actual values. | |
| 193 | −* backward compatibility with core_uses_pid: | |
| 118 | +* ``core_pattern`` is used as a pattern template for the output | |
| 119 | + filename; certain string patterns (beginning with '%') are | |
| 120 | + substituted with their actual values. | |
| 121 | +* backward compatibility with ``core_uses_pid``: | |
| 194 | 122 | |
| 195 | − If core_pattern does not include "%p" (default does not) | |
| 196 | − and core_uses_pid is set, then .PID will be appended to | |
| 123 | + If ``core_pattern`` does not include "%p" (default does not) | |
| 124 | + and ``core_uses_pid`` is set, then .PID will be appended to | |
| 197 | 125 | the filename. |
| 198 | 126 | |
| 199 | −* corename format specifiers:: | |
| 200 | − | |
| 201 | − %<NUL> '%' is dropped | |
| 202 | − %% output one '%' | |
| 203 | − %p pid | |
| 204 | − %P global pid (init PID namespace) | |
| 205 | − %i tid | |
| 206 | − %I global tid (init PID namespace) | |
| 207 | − %u uid (in initial user namespace) | |
| 208 | − %g gid (in initial user namespace) | |
| 209 | − %d dump mode, matches PR_SET_DUMPABLE and | |
| 210 | − /proc/sys/fs/suid_dumpable | |
| 211 | − %s signal number | |
| 212 | − %t UNIX time of dump | |
| 213 | − %h hostname | |
| 214 | − %e executable filename (may be shortened) | |
| 215 | − %E executable path | |
| 216 | − %<OTHER> both are dropped | |
| 127 | +* corename format specifiers | |
| 128 | + | |
| 129 | + ======== ========================================== | |
| 130 | + %<NUL> '%' is dropped | |
| 131 | + %% output one '%' | |
| 132 | + %p pid | |
| 133 | + %P global pid (init PID namespace) | |
| 134 | + %i tid | |
| 135 | + %I global tid (init PID namespace) | |
| 136 | + %u uid (in initial user namespace) | |
| 137 | + %g gid (in initial user namespace) | |
| 138 | + %d dump mode, matches ``PR_SET_DUMPABLE`` and | |
| 139 | + ``/proc/sys/fs/suid_dumpable`` | |
| 140 | + %s signal number | |
| 141 | + %t UNIX time of dump | |
| 142 | + %h hostname | |
| 143 | + %e executable filename (may be shortened) | |
| 144 | + %E executable path | |
| 145 | + %c maximum size of core file by resource limit RLIMIT_CORE | |
| 146 | + %<OTHER> both are dropped | |
| 147 | + ======== ========================================== | |
| 217 | 148 | |
| 218 | 149 | * If the first character of the pattern is a '|', the kernel will treat |
| 219 | 150 | the rest of the pattern as a command to run. The core dump will be |
| 220 | 151 | written to the standard input of that program instead of to a file. |
| 221 | 152 | |
| 222 | 153 | |
| 223 | −core_pipe_limit: | |
| 224 | −================ | |
| 154 | +core_pipe_limit | |
| 155 | +=============== | |
| 225 | 156 | |
| 226 | −This sysctl is only applicable when core_pattern is configured to pipe | |
| 227 | −core files to a user space helper (when the first character of | |
| 228 | −core_pattern is a '|', see above). When collecting cores via a pipe | |
| 229 | −to an application, it is occasionally useful for the collecting | |
| 230 | −application to gather data about the crashing process from its | |
| 231 | −/proc/pid directory. In order to do this safely, the kernel must wait | |
| 232 | −for the collecting process to exit, so as not to remove the crashing | |
| 233 | −processes proc files prematurely. This in turn creates the | |
| 234 | −possibility that a misbehaving userspace collecting process can block | |
| 235 | −the reaping of a crashed process simply by never exiting. This sysctl | |
| 236 | −defends against that. It defines how many concurrent crashing | |
| 237 | −processes may be piped to user space applications in parallel. If | |
| 238 | −this value is exceeded, then those crashing processes above that value | |
| 239 | −are noted via the kernel log and their cores are skipped. 0 is a | |
| 240 | −special value, indicating that unlimited processes may be captured in | |
| 241 | −parallel, but that no waiting will take place (i.e. the collecting | |
| 242 | −process is not guaranteed access to /proc/<crashing pid>/). This | |
| 243 | −value defaults to 0. | |
| 244 | − | |
| 245 | − | |
| 246 | −core_uses_pid: | |
| 247 | −============== | |
| 157 | +This sysctl is only applicable when `core_pattern`_ is configured to | |
| 158 | +pipe core files to a user space helper (when the first character of | |
| 159 | +``core_pattern`` is a '|', see above). | |
| 160 | +When collecting cores via a pipe to an application, it is occasionally | |
| 161 | +useful for the collecting application to gather data about the | |
| 162 | +crashing process from its ``/proc/pid`` directory. | |
| 163 | +In order to do this safely, the kernel must wait for the collecting | |
| 164 | +process to exit, so as not to remove the crashing processes proc files | |
| 165 | +prematurely. | |
| 166 | +This in turn creates the possibility that a misbehaving userspace | |
| 167 | +collecting process can block the reaping of a crashed process simply | |
| 168 | +by never exiting. | |
| 169 | +This sysctl defends against that. | |
| 170 | +It defines how many concurrent crashing processes may be piped to user | |
| 171 | +space applications in parallel. | |
| 172 | +If this value is exceeded, then those crashing processes above that | |
| 173 | +value are noted via the kernel log and their cores are skipped. | |
| 174 | +0 is a special value, indicating that unlimited processes may be | |
| 175 | +captured in parallel, but that no waiting will take place (i.e. the | |
| 176 | +collecting process is not guaranteed access to ``/proc/<crashing | |
| 177 | +pid>/``). | |
| 178 | +This value defaults to 0. | |
| 179 | + | |
| 180 | + | |
| 181 | +core_uses_pid | |
| 182 | +============= | |
| 248 | 183 | |
| 249 | 184 | The default coredump filename is "core". By setting |
| 250 | −core_uses_pid to 1, the coredump filename becomes core.PID. | |
| 251 | −If core_pattern does not include "%p" (default does not) | |
| 252 | −and core_uses_pid is set, then .PID will be appended to | |
| 185 | +``core_uses_pid`` to 1, the coredump filename becomes core.PID. | |
| 186 | +If `core_pattern`_ does not include "%p" (default does not) | |
| 187 | +and ``core_uses_pid`` is set, then .PID will be appended to | |
| 253 | 188 | the filename. |
| 254 | 189 | |
| 255 | 190 | |
| 256 | −ctrl-alt-del: | |
| 257 | −============= | |
| 191 | +ctrl-alt-del | |
| 192 | +============ | |
| 258 | 193 | |
| 259 | 194 | When the value in this file is 0, ctrl-alt-del is trapped and |
| 260 | −sent to the init(1) program to handle a graceful restart. | |
| 195 | +sent to the ``init(1)`` program to handle a graceful restart. | |
| 261 | 196 | When, however, the value is > 0, Linux's reaction to a Vulcan |
| 262 | 197 | Nerve Pinch (tm) will be an immediate reboot, without even |
| 263 | 198 | syncing its dirty buffers. |
| @@ -269,21 +204,22 @@ Note: · 5 unmodified lines | ||
| 269 | 204 | to decide what to do with it. |
| 270 | 205 | |
| 271 | 206 | |
| 272 | −dmesg_restrict: | |
| 273 | −=============== | |
| 207 | +dmesg_restrict | |
| 208 | +============== | |
| 274 | 209 | |
| 275 | 210 | This toggle indicates whether unprivileged users are prevented |
| 276 | −from using dmesg(8) to view messages from the kernel's log buffer. | |
| 277 | −When dmesg_restrict is set to (0) there are no restrictions. When | |
| 278 | −dmesg_restrict is set set to (1), users must have CAP_SYSLOG to use | |
| 279 | −dmesg(8). | |
| 211 | +from using ``dmesg(8)`` to view messages from the kernel's log | |
| 212 | +buffer. | |
| 213 | +When ``dmesg_restrict`` is set to 0 there are no restrictions. | |
| 214 | +When ``dmesg_restrict`` is set set to 1, users must have | |
| 215 | +``CAP_SYSLOG`` to use ``dmesg(8)``. | |
| 280 | 216 | |
| 281 | −The kernel config option CONFIG_SECURITY_DMESG_RESTRICT sets the | |
| 282 | −default value of dmesg_restrict. | |
| 217 | +The kernel config option ``CONFIG_SECURITY_DMESG_RESTRICT`` sets the | |
| 218 | +default value of ``dmesg_restrict``. | |
| 283 | 219 | |
| 284 | 220 | |
| 285 | −domainname & hostname: | |
| 286 | −====================== | |
| 221 | +domainname & hostname | |
| 222 | +===================== | |
| 287 | 223 | |
| 288 | 224 | These files can be used to set the NIS/YP domainname and the |
| 289 | 225 | hostname of your box in exactly the same way as the commands |
| @@ -302,167 +238,206 @@ hostname "darkstar" and DNS (Internet Domain Name Server) · 12 unmodified lines | ||
| 302 | 238 | domainname "frop.org", not to be confused with the NIS (Network |
| 303 | 239 | Information Service) or YP (Yellow Pages) domainname. These two |
| 304 | 240 | domain names are in general different. For a detailed discussion |
| 305 | −see the hostname(1) man page. | |
| 241 | +see the ``hostname(1)`` man page. | |
| 306 | 242 | |
| 307 | 243 | |
| 308 | −hardlockup_all_cpu_backtrace: | |
| 309 | −============================= | |
| 244 | +hardlockup_all_cpu_backtrace | |
| 245 | +============================ | |
| 310 | 246 | |
| 311 | 247 | This value controls the hard lockup detector behavior when a hard |
| 312 | 248 | lockup condition is detected as to whether or not to gather further |
| 313 | 249 | debug information. If enabled, arch-specific all-CPU stack dumping |
| 314 | 250 | will be initiated. |
| 315 | 251 | |
| 316 | −0: do nothing. This is the default behavior. | |
| 252 | += ============================================ | |
| 253 | +0 Do nothing. This is the default behavior. | |
| 254 | +1 On detection capture more debug information. | |
| 255 | += ============================================ | |
| 317 | 256 | |
| 318 | −1: on detection capture more debug information. | |
| 319 | 257 | |
| 320 | − | |
| 321 | −hardlockup_panic: | |
| 322 | −================= | |
| 258 | +hardlockup_panic | |
| 259 | +================ | |
| 323 | 260 | |
| 324 | 261 | This parameter can be used to control whether the kernel panics |
| 325 | 262 | when a hard lockup is detected. |
| 326 | 263 | |
| 327 | − 0 - don't panic on hard lockup | |
| 328 | − 1 - panic on hard lockup | |
| 264 | += =========================== | |
| 265 | +0 Don't panic on hard lockup. | |
| 266 | +1 Panic on hard lockup. | |
| 267 | += =========================== | |
| 329 | 268 | |
| 330 | −See Documentation/admin-guide/lockup-watchdogs.rst for more information. This can | |
| 331 | −also be set using the nmi_watchdog kernel parameter. | |
| 269 | +See :doc:`/admin-guide/lockup-watchdogs` for more information. | |
| 270 | +This can also be set using the nmi_watchdog kernel parameter. | |
| 332 | 271 | |
| 333 | 272 | |
| 334 | −hotplug: | |
| 335 | −======== | |
| 273 | +hotplug | |
| 274 | +======= | |
| 336 | 275 | |
| 337 | 276 | Path for the hotplug policy agent. |
| 338 | −Default value is "/sbin/hotplug". | |
| 277 | +Default value is "``/sbin/hotplug``". | |
| 339 | 278 | |
| 340 | 279 | |
| 341 | −hung_task_panic: | |
| 342 | −================ | |
| 280 | +hung_task_panic | |
| 281 | +=============== | |
| 343 | 282 | |
| 344 | 283 | Controls the kernel's behavior when a hung task is detected. |
| 345 | −This file shows up if CONFIG_DETECT_HUNG_TASK is enabled. | |
| 346 | − | |
| 347 | −0: continue operation. This is the default behavior. | |
| 284 | +This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled. | |
| 348 | 285 | |
| 349 | −1: panic immediately. | |
| 286 | += ================================================= | |
| 287 | +0 Continue operation. This is the default behavior. | |
| 288 | +1 Panic immediately. | |
| 289 | += ================================================= | |
| 350 | 290 | |
| 351 | 291 | |
| 352 | −hung_task_check_count: | |
| 353 | −====================== | |
| 292 | +hung_task_check_count | |
| 293 | +===================== | |
| 354 | 294 | |
| 355 | 295 | The upper bound on the number of tasks that are checked. |
| 356 | −This file shows up if CONFIG_DETECT_HUNG_TASK is enabled. | |
| 296 | +This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled. | |
| 357 | 297 | |
| 358 | 298 | |
| 359 | −hung_task_timeout_secs: | |
| 360 | −======================= | |
| 299 | +hung_task_timeout_secs | |
| 300 | +====================== | |
| 361 | 301 | |
| 362 | 302 | When a task in D state did not get scheduled |
| 363 | 303 | for more than this value report a warning. |
| 364 | −This file shows up if CONFIG_DETECT_HUNG_TASK is enabled. | |
| 304 | +This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled. | |
| 365 | 305 | |
| 366 | −0: means infinite timeout - no checking done. | |
| 306 | +0 means infinite timeout, no checking is done. | |
| 367 | 307 | |
| 368 | −Possible values to set are in range {0..LONG_MAX/HZ}. | |
| 308 | +Possible values to set are in range {0:``LONG_MAX``/``HZ``}. | |
| 369 | 309 | |
| 370 | 310 | |
| 371 | −hung_task_check_interval_secs: | |
| 372 | −============================== | |
| 311 | +hung_task_check_interval_secs | |
| 312 | +============================= | |
| 373 | 313 | |
| 374 | 314 | Hung task check interval. If hung task checking is enabled |
| 375 | −(see hung_task_timeout_secs), the check is done every | |
| 376 | −hung_task_check_interval_secs seconds. | |
| 377 | −This file shows up if CONFIG_DETECT_HUNG_TASK is enabled. | |
| 315 | +(see `hung_task_timeout_secs`_), the check is done every | |
| 316 | +``hung_task_check_interval_secs`` seconds. | |
| 317 | +This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled. | |
| 378 | 318 | |
| 379 | −0 (default): means use hung_task_timeout_secs as checking interval. | |
| 380 | −Possible values to set are in range {0..LONG_MAX/HZ}. | |
| 319 | +0 (default) means use ``hung_task_timeout_secs`` as checking | |
| 320 | +interval. | |
| 381 | 321 | |
| 322 | +Possible values to set are in range {0:``LONG_MAX``/``HZ``}. | |
| 382 | 323 | |
| 383 | −hung_task_warnings: | |
| 384 | −=================== | |
| 324 | + | |
| 325 | +hung_task_warnings | |
| 326 | +================== | |
| 385 | 327 | |
| 386 | 328 | The maximum number of warnings to report. During a check interval |
| 387 | 329 | if a hung task is detected, this value is decreased by 1. |
| 388 | 330 | When this value reaches 0, no more warnings will be reported. |
| 389 | −This file shows up if CONFIG_DETECT_HUNG_TASK is enabled. | |
| 331 | +This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled. | |
| 390 | 332 | |
| 391 | 333 | -1: report an infinite number of warnings. |
| 392 | 334 | |
| 393 | 335 | |
| 394 | −hyperv_record_panic_msg: | |
| 395 | −======================== | |
| 336 | +hyperv_record_panic_msg | |
| 337 | +======================= | |
| 396 | 338 | |
| 397 | 339 | Controls whether the panic kmsg data should be reported to Hyper-V. |
| 398 | 340 | |
| 399 | −0: do not report panic kmsg data. | |
| 400 | − | |
| 401 | −1: report the panic kmsg data. This is the default behavior. | |
| 341 | += ========================================================= | |
| 342 | +0 Do not report panic kmsg data. | |
| 343 | +1 Report the panic kmsg data. This is the default behavior. | |
| 344 | += ========================================================= | |
| 402 | 345 | |
| 403 | 346 | |
| 404 | −kexec_load_disabled: | |
| 405 | −==================== | |
| 347 | +kexec_load_disabled | |
| 348 | +=================== | |
| 406 | 349 | |
| 407 | −A toggle indicating if the kexec_load syscall has been disabled. This | |
| 408 | −value defaults to 0 (false: kexec_load enabled), but can be set to 1 | |
| 409 | −(true: kexec_load disabled). Once true, kexec can no longer be used, and | |
| 410 | −the toggle cannot be set back to false. This allows a kexec image to be | |
| 411 | −loaded before disabling the syscall, allowing a system to set up (and | |
| 412 | −later use) an image without it being altered. Generally used together | |
| 413 | −with the "modules_disabled" sysctl. | |
| 350 | +A toggle indicating if the ``kexec_load`` syscall has been disabled. | |
| 351 | +This value defaults to 0 (false: ``kexec_load`` enabled), but can be | |
| 352 | +set to 1 (true: ``kexec_load`` disabled). | |
| 353 | +Once true, kexec can no longer be used, and the toggle cannot be set | |
| 354 | +back to false. | |
| 355 | +This allows a kexec image to be loaded before disabling the syscall, | |
| 356 | +allowing a system to set up (and later use) an image without it being | |
| 357 | +altered. | |
| 358 | +Generally used together with the `modules_disabled`_ sysctl. | |
| 414 | 359 | |
| 415 | 360 | |
| 416 | −kptr_restrict: | |
| 417 | −============== | |
| 361 | +kptr_restrict | |
| 362 | +============= | |
| 418 | 363 | |
| 419 | 364 | This toggle indicates whether restrictions are placed on |
| 420 | −exposing kernel addresses via /proc and other interfaces. | |
| 365 | +exposing kernel addresses via ``/proc`` and other interfaces. | |
| 366 | + | |
| 367 | +When ``kptr_restrict`` is set to 0 (the default) the address is hashed | |
| 368 | +before printing. | |
| 369 | +(This is the equivalent to %p.) | |
| 370 | + | |
| 371 | +When ``kptr_restrict`` is set to 1, kernel pointers printed using the | |
| 372 | +%pK format specifier will be replaced with 0s unless the user has | |
| 373 | +``CAP_SYSLOG`` and effective user and group ids are equal to the real | |
| 374 | +ids. | |
| 375 | +This is because %pK checks are done at read() time rather than open() | |
| 376 | +time, so if permissions are elevated between the open() and the read() | |
| 377 | +(e.g via a setuid binary) then %pK will not leak kernel pointers to | |
| 378 | +unprivileged users. | |
| 379 | +Note, this is a temporary solution only. | |
| 380 | +The correct long-term solution is to do the permission checks at | |
| 381 | +open() time. | |
| 382 | +Consider removing world read permissions from files that use %pK, and | |
| 383 | +using `dmesg_restrict`_ to protect against uses of %pK in ``dmesg(8)`` | |
| 384 | +if leaking kernel pointer values to unprivileged users is a concern. | |
| 385 | + | |
| 386 | +When ``kptr_restrict`` is set to 2, kernel pointers printed using | |
| 387 | +%pK will be replaced with 0s regardless of privileges. | |
| 388 | + | |
| 389 | + | |
| 390 | +modprobe | |
| 391 | +======== | |
| 421 | 392 | |
| 422 | −When kptr_restrict is set to 0 (the default) the address is hashed before | |
| 423 | −printing. (This is the equivalent to %p.) | |
| 393 | +This gives the full path of the modprobe command which the kernel will | |
| 394 | +use to load modules. This can be used to debug module loading | |
| 395 | +requests:: | |
| 424 | 396 | |
| 425 | −When kptr_restrict is set to (1), kernel pointers printed using the %pK | |
| 426 | −format specifier will be replaced with 0's unless the user has CAP_SYSLOG | |
| 427 | −and effective user and group ids are equal to the real ids. This is | |
| 428 | −because %pK checks are done at read() time rather than open() time, so | |
| 429 | −if permissions are elevated between the open() and the read() (e.g via | |
| 430 | −a setuid binary) then %pK will not leak kernel pointers to unprivileged | |
| 431 | −users. Note, this is a temporary solution only. The correct long-term | |
| 432 | −solution is to do the permission checks at open() time. Consider removing | |
| 433 | −world read permissions from files that use %pK, and using dmesg_restrict | |
| 434 | −to protect against uses of %pK in dmesg(8) if leaking kernel pointer | |
| 435 | −values to unprivileged users is a concern. | |
| 397 | + echo '#! /bin/sh' > /tmp/modprobe | |
| 398 | + echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe | |
| 399 | + echo 'exec /sbin/modprobe "$@"' >> /tmp/modprobe | |
| 400 | + chmod a+x /tmp/modprobe | |
| 401 | + echo /tmp/modprobe > /proc/sys/kernel/modprobe | |
| 436 | 402 | |
| 437 | −When kptr_restrict is set to (2), kernel pointers printed using | |
| 438 | −%pK will be replaced with 0's regardless of privileges. | |
| 403 | +This only applies when the *kernel* is requesting that the module be | |
| 404 | +loaded; it won't have any effect if the module is being loaded | |
| 405 | +explicitly using ``modprobe`` from userspace. | |
| 439 | 406 | |
| 440 | 407 | |
| 441 | −l2cr: (PPC only) | |
| 408 | +modules_disabled | |
| 442 | 409 | ================ |
| 443 | 410 | |
| 444 | −This flag controls the L2 cache of G3 processor boards. If | |
| 445 | −0, the cache is disabled. Enabled if nonzero. | |
| 446 | − | |
| 447 | − | |
| 448 | −modules_disabled: | |
| 449 | −================= | |
| 450 | − | |
| 451 | 411 | A toggle value indicating if modules are allowed to be loaded |
| 452 | 412 | in an otherwise modular kernel. This toggle defaults to off |
| 453 | 413 | (0), but can be set true (1). Once true, modules can be |
| 454 | 414 | neither loaded nor unloaded, and the toggle cannot be set back |
| 455 | −to false. Generally used with the "kexec_load_disabled" toggle. | |
| 415 | +to false. Generally used with the `kexec_load_disabled`_ toggle. | |
| 456 | 416 | |
| 457 | 417 | |
| 458 | −msg_next_id, sem_next_id, and shm_next_id: | |
| 459 | −========================================== | |
| 418 | +.. _msgmni: | |
| 419 | + | |
| 420 | +msgmax, msgmnb, and msgmni | |
| 421 | +========================== | |
| 422 | + | |
| 423 | +``msgmax`` is the maximum size of an IPC message, in bytes. 8192 by | |
| 424 | +default (``MSGMAX``). | |
| 425 | + | |
| 426 | +``msgmnb`` is the maximum size of an IPC queue, in bytes. 16384 by | |
| 427 | +default (``MSGMNB``). | |
| 428 | + | |
| 429 | +``msgmni`` is the maximum number of IPC queues. 32000 by default | |
| 430 | +(``MSGMNI``). | |
| 431 | + | |
| 432 | + | |
| 433 | +msg_next_id, sem_next_id, and shm_next_id (System V IPC) | |
| 434 | +======================================================== | |
| 460 | 435 | |
| 461 | 436 | These three toggles allows to specify desired id for next allocated IPC |
| 462 | 437 | object: message, semaphore or shared memory respectively. |
| 463 | 438 | |
| 464 | 439 | By default they are equal to -1, which means generic allocation logic. |
| 465 | −Possible values to set are in range {0..INT_MAX}. | |
| 440 | +Possible values to set are in range {0:``INT_MAX``}. | |
| 466 | 441 | |
| 467 | 442 | Notes: |
| 468 | 443 | 1) kernel doesn't guarantee, that new object will have desired id. So, |
| @@ -471,16 +446,38 @@ Notes: · 2 unmodified lines | ||
| 471 | 446 | successful IPC object allocation. If an IPC object allocation syscall |
| 472 | 447 | fails, it is undefined if the value remains unmodified or is reset to -1. |
| 473 | 448 | |
| 449 | +modprobe: | |
| 450 | +========= | |
| 474 | 451 | |
| 475 | −nmi_watchdog: | |
| 476 | −============= | |
| 452 | +The path to the usermode helper for autoloading kernel modules, by | |
| 453 | +default "/sbin/modprobe". This binary is executed when the kernel | |
| 454 | +requests a module. For example, if userspace passes an unknown | |
| 455 | +filesystem type to mount(), then the kernel will automatically request | |
| 456 | +the corresponding filesystem module by executing this usermode helper. | |
| 457 | +This usermode helper should insert the needed module into the kernel. | |
| 458 | + | |
| 459 | +This sysctl only affects module autoloading. It has no effect on the | |
| 460 | +ability to explicitly insert modules. | |
| 461 | + | |
| 462 | +If this sysctl is set to the empty string, then module autoloading is | |
| 463 | +completely disabled. The kernel will not try to execute a usermode | |
| 464 | +helper at all, nor will it call the kernel_module_request LSM hook. | |
| 465 | + | |
| 466 | +If CONFIG_STATIC_USERMODEHELPER=y is set in the kernel configuration, | |
| 467 | +then the configured static usermode helper overrides this sysctl, | |
| 468 | +except that the empty string is still accepted to completely disable | |
| 469 | +module autoloading as described above. | |
| 470 | + | |
| 471 | +nmi_watchdog | |
| 472 | +============ | |
| 477 | 473 | |
| 478 | 474 | This parameter can be used to control the NMI watchdog |
| 479 | 475 | (i.e. the hard lockup detector) on x86 systems. |
| 480 | 476 | |
| 481 | −0 - disable the hard lockup detector | |
| 482 | − | |
| 483 | −1 - enable the hard lockup detector | |
| 477 | += ================================= | |
| 478 | +0 Disable the hard lockup detector. | |
| 479 | +1 Enable the hard lockup detector. | |
| 480 | += ================================= | |
| 484 | 481 | |
| 485 | 482 | The hard lockup detector monitors each CPU for its ability to respond to |
| 486 | 483 | timer interrupts. The mechanism utilizes CPU performance counter registers |
| @@ -492,11 +489,11 @@ in a KVM virtual machine. This default can be overridden by adding:: · 5 unmodified lines | ||
| 492 | 489 | |
| 493 | 490 | nmi_watchdog=1 |
| 494 | 491 | |
| 495 | −to the guest kernel command line (see Documentation/admin-guide/kernel-parameters.rst). | |
| 492 | +to the guest kernel command line (see :doc:`/admin-guide/kernel-parameters`). | |
| 496 | 493 | |
| 497 | 494 | |
| 498 | −numa_balancing: | |
| 499 | −=============== | |
| 495 | +numa_balancing | |
| 496 | +============== | |
| 500 | 497 | |
| 501 | 498 | Enables/disables automatic page fault based NUMA memory |
| 502 | 499 | balancing. Memory is moved automatically to nodes |
| @@ -514,9 +511,10 @@ ideally is offset by improved memory locality but there is no universal · 11 unmodified lines | ||
| 514 | 511 | guarantee. If the target workload is already bound to NUMA nodes then this |
| 515 | 512 | feature should be disabled. Otherwise, if the system overhead from the |
| 516 | 513 | feature is too high then the rate the kernel samples for NUMA hinting |
| 517 | −faults may be controlled by the numa_balancing_scan_period_min_ms, | |
| 514 | +faults may be controlled by the `numa_balancing_scan_period_min_ms, | |
| 518 | 515 | numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms, |
| 519 | −numa_balancing_scan_size_mb, and numa_balancing_settle_count sysctls. | |
| 516 | +numa_balancing_scan_size_mb`_, and numa_balancing_settle_count sysctls. | |
| 517 | + | |
| 520 | 518 | |
| 521 | 519 | numa_balancing_scan_period_min_ms, numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms, numa_balancing_scan_size_mb |
| 522 | 520 | =============================================================================================================================== |
| @@ -542,23 +540,23 @@ workload pattern changes and minimises performance impact due to remote · 19 unmodified lines | ||
| 542 | 540 | memory accesses. These sysctls control the thresholds for scan delays and |
| 543 | 541 | the number of pages scanned. |
| 544 | 542 | |
| 545 | −numa_balancing_scan_period_min_ms is the minimum time in milliseconds to | |
| 543 | +``numa_balancing_scan_period_min_ms`` is the minimum time in milliseconds to | |
| 546 | 544 | scan a tasks virtual memory. It effectively controls the maximum scanning |
| 547 | 545 | rate for each task. |
| 548 | 546 | |
| 549 | −numa_balancing_scan_delay_ms is the starting "scan delay" used for a task | |
| 547 | +``numa_balancing_scan_delay_ms`` is the starting "scan delay" used for a task | |
| 550 | 548 | when it initially forks. |
| 551 | 549 | |
| 552 | −numa_balancing_scan_period_max_ms is the maximum time in milliseconds to | |
| 550 | +``numa_balancing_scan_period_max_ms`` is the maximum time in milliseconds to | |
| 553 | 551 | scan a tasks virtual memory. It effectively controls the minimum scanning |
| 554 | 552 | rate for each task. |
| 555 | 553 | |
| 556 | −numa_balancing_scan_size_mb is how many megabytes worth of pages are | |
| 554 | +``numa_balancing_scan_size_mb`` is how many megabytes worth of pages are | |
| 557 | 555 | scanned for a given scan. |
| 558 | 556 | |
| 559 | 557 | |
| 560 | −osrelease, ostype & version: | |
| 561 | −============================ | |
| 558 | +osrelease, ostype & version | |
| 559 | +=========================== | |
| 562 | 560 | |
| 563 | 561 | :: |
| 564 | 562 | |
| @@ -569,15 +567,16 @@ osrelease, ostype & version: · 4 unmodified lines | ||
| 569 | 567 | # cat version |
| 570 | 568 | #5 Wed Feb 25 21:49:24 MET 1998 |
| 571 | 569 | |
| 572 | −The files osrelease and ostype should be clear enough. Version | |
| 570 | +The files ``osrelease`` and ``ostype`` should be clear enough. | |
| 571 | +``version`` | |
| 573 | 572 | needs a little more clarification however. The '#5' means that |
| 574 | 573 | this is the fifth kernel built from this source base and the |
| 575 | 574 | date behind it indicates the time the kernel was built. |
| 576 | 575 | The only way to tune these values is to rebuild the kernel :-) |
| 577 | 576 | |
| 578 | 577 | |
| 579 | −overflowgid & overflowuid: | |
| 580 | −========================== | |
| 578 | +overflowgid & overflowuid | |
| 579 | +========================= | |
| 581 | 580 | |
| 582 | 581 | if your architecture did not always support 32-bit UIDs (i.e. arm, |
| 583 | 582 | i386, m68k, sh, and sparc32), a fixed UID and GID will be returned to |
| @@ -588,108 +587,119 @@ These sysctls allow you to change the value of the fixed UID and GID. · 4 unmodified lines | ||
| 588 | 587 | The default is 65534. |
| 589 | 588 | |
| 590 | 589 | |
| 590 | +panic | |
| 591 | +===== | |
| 592 | + | |
| 593 | +The value in this file determines the behaviour of the kernel on a | |
| 591 | 594 | panic: |
| 592 | −====== | |
| 593 | 595 | |
| 594 | −The value in this file represents the number of seconds the kernel | |
| 595 | −waits before rebooting on a panic. When you use the software watchdog, | |
| 596 | −the recommended setting is 60. | |
| 596 | +* if zero, the kernel will loop forever; | |
| 597 | +* if negative, the kernel will reboot immediately; | |
| 598 | +* if positive, the kernel will reboot after the corresponding number | |
| 599 | + of seconds. | |
| 597 | 600 | |
| 601 | +When you use the software watchdog, the recommended setting is 60. | |
| 598 | 602 | |
| 599 | −panic_on_io_nmi: | |
| 600 | −================ | |
| 603 | + | |
| 604 | +panic_on_io_nmi | |
| 605 | +=============== | |
| 601 | 606 | |
| 602 | 607 | Controls the kernel's behavior when a CPU receives an NMI caused by |
| 603 | 608 | an IO error. |
| 604 | 609 | |
| 605 | −0: try to continue operation (default) | |
| 606 | − | |
| 607 | −1: panic immediately. The IO error triggered an NMI. This indicates a | |
| 608 | − serious system condition which could result in IO data corruption. | |
| 609 | − Rather than continuing, panicking might be a better choice. Some | |
| 610 | − servers issue this sort of NMI when the dump button is pushed, | |
| 611 | − and you can use this option to take a crash dump. | |
| 610 | += ================================================================== | |
| 611 | +0 Try to continue operation (default). | |
| 612 | +1 Panic immediately. The IO error triggered an NMI. This indicates a | |
| 613 | + serious system condition which could result in IO data corruption. | |
| 614 | + Rather than continuing, panicking might be a better choice. Some | |
| 615 | + servers issue this sort of NMI when the dump button is pushed, | |
| 616 | + and you can use this option to take a crash dump. | |
| 617 | += ================================================================== | |
| 612 | 618 | |
| 613 | 619 | |
| 614 | −panic_on_oops: | |
| 615 | −============== | |
| 620 | +panic_on_oops | |
| 621 | +============= | |
| 616 | 622 | |
| 617 | 623 | Controls the kernel's behaviour when an oops or BUG is encountered. |
| 618 | 624 | |
| 619 | −0: try to continue operation | |
| 620 | − | |
| 621 | −1: panic immediately. If the `panic` sysctl is also non-zero then the | |
| 622 | − machine will be rebooted. | |
| 625 | += =================================================================== | |
| 626 | +0 Try to continue operation. | |
| 627 | +1 Panic immediately. If the `panic` sysctl is also non-zero then the | |
| 628 | + machine will be rebooted. | |
| 629 | += =================================================================== | |
| 623 | 630 | |
| 624 | 631 | |
| 625 | −panic_on_stackoverflow: | |
| 626 | −======================= | |
| 632 | +panic_on_stackoverflow | |
| 633 | +====================== | |
| 627 | 634 | |
| 628 | 635 | Controls the kernel's behavior when detecting the overflows of |
| 629 | 636 | kernel, IRQ and exception stacks except a user stack. |
| 630 | −This file shows up if CONFIG_DEBUG_STACKOVERFLOW is enabled. | |
| 631 | − | |
| 632 | −0: try to continue operation. | |
| 637 | +This file shows up if ``CONFIG_DEBUG_STACKOVERFLOW`` is enabled. | |
| 633 | 638 | |
| 634 | −1: panic immediately. | |
| 639 | += ========================== | |
| 640 | +0 Try to continue operation. | |
| 641 | +1 Panic immediately. | |
| 642 | += ========================== | |
| 635 | 643 | |
| 636 | 644 | |
| 637 | −panic_on_unrecovered_nmi: | |
| 638 | −========================= | |
| 645 | +panic_on_unrecovered_nmi | |
| 646 | +======================== | |
| 639 | 647 | |
| 640 | 648 | The default Linux behaviour on an NMI of either memory or unknown is |
| 641 | 649 | to continue operation. For many environments such as scientific |
| 642 | 650 | computing it is preferable that the box is taken out and the error |
| 643 | 651 | dealt with than an uncorrected parity/ECC error get propagated. |
| 644 | 652 | |
| 645 | −A small number of systems do generate NMI's for bizarre random reasons | |
| 653 | +A small number of systems do generate NMIs for bizarre random reasons | |
| 646 | 654 | such as power management so the default is off. That sysctl works like |
| 647 | 655 | the existing panic controls already in that directory. |
| 648 | 656 | |
| 649 | 657 | |
| 650 | −panic_on_warn: | |
| 651 | −============== | |
| 658 | +panic_on_warn | |
| 659 | +============= | |
| 652 | 660 | |
| 653 | 661 | Calls panic() in the WARN() path when set to 1. This is useful to avoid |
| 654 | 662 | a kernel rebuild when attempting to kdump at the location of a WARN(). |
| 655 | 663 | |
| 656 | −0: only WARN(), default behaviour. | |
| 664 | += ================================================ | |
| 665 | +0 Only WARN(), default behaviour. | |
| 666 | +1 Call panic() after printing out WARN() location. | |
| 667 | += ================================================ | |
| 657 | 668 | |
| 658 | −1: call panic() after printing out WARN() location. | |
| 659 | 669 | |
| 660 | − | |
| 661 | −panic_print: | |
| 662 | −============ | |
| 670 | +panic_print | |
| 671 | +=========== | |
| 663 | 672 | |
| 664 | 673 | Bitmask for printing system info when panic happens. User can chose |
| 665 | 674 | combination of the following bits: |
| 666 | 675 | |
| 667 | −===== ======================================== | |
| 676 | +===== ============================================ | |
| 668 | 677 | bit 0 print all tasks info |
| 669 | 678 | bit 1 print system memory info |
| 670 | 679 | bit 2 print timer info |
| 671 | −bit 3 print locks info if CONFIG_LOCKDEP is on | |
| 680 | +bit 3 print locks info if ``CONFIG_LOCKDEP`` is on | |
| 672 | 681 | bit 4 print ftrace buffer |
| 673 | −===== ======================================== | |
| 682 | +===== ============================================ | |
| 674 | 683 | |
| 675 | 684 | So for example to print tasks and memory info on panic, user can:: |
| 676 | 685 | |
| 677 | 686 | echo 3 > /proc/sys/kernel/panic_print |
| 678 | 687 | |
| 679 | 688 | |
| 680 | −panic_on_rcu_stall: | |
| 681 | −=================== | |
| 689 | +panic_on_rcu_stall | |
| 690 | +================== | |
| 682 | 691 | |
| 683 | 692 | When set to 1, calls panic() after RCU stall detection messages. This |
| 684 | 693 | is useful to define the root cause of RCU stalls using a vmcore. |
| 685 | 694 | |
| 686 | −0: do not panic() when RCU stall takes place, default behavior. | |
| 695 | += ============================================================ | |
| 696 | +0 Do not panic() when RCU stall takes place, default behavior. | |
| 697 | +1 panic() after printing RCU stall messages. | |
| 698 | += ============================================================ | |
| 687 | 699 | |
| 688 | −1: panic() after printing RCU stall messages. | |
| 689 | 700 | |
| 690 | − | |
| 691 | −perf_cpu_time_max_percent: | |
| 692 | −========================== | |
| 701 | +perf_cpu_time_max_percent | |
| 702 | +========================= | |
| 693 | 703 | |
| 694 | 704 | Hints to the kernel how much CPU time it should be allowed to |
| 695 | 705 | use to handle perf sampling events. If the perf subsystem |
| @@ -702,171 +712,179 @@ unexpectedly take too long to execute, the NMIs can become · 6 unmodified lines | ||
| 702 | 712 | stacked up next to each other so much that nothing else is |
| 703 | 713 | allowed to execute. |
| 704 | 714 | |
| 705 | −0: | |
| 706 | − disable the mechanism. Do not monitor or correct perf's | |
| 707 | − sampling rate no matter how CPU time it takes. | |
| 715 | +===== ======================================================== | |
| 716 | +0 Disable the mechanism. Do not monitor or correct perf's | |
| 717 | + sampling rate no matter how CPU time it takes. | |
| 708 | 718 | |
| 709 | −1-100: | |
| 710 | − attempt to throttle perf's sample rate to this | |
| 711 | − percentage of CPU. Note: the kernel calculates an | |
| 712 | − "expected" length of each sample event. 100 here means | |
| 713 | − 100% of that expected length. Even if this is set to | |
| 714 | − 100, you may still see sample throttling if this | |
| 715 | − length is exceeded. Set to 0 if you truly do not care | |
| 716 | − how much CPU is consumed. | |
| 719 | +1-100 Attempt to throttle perf's sample rate to this | |
| 720 | + percentage of CPU. Note: the kernel calculates an | |
| 721 | + "expected" length of each sample event. 100 here means | |
| 722 | + 100% of that expected length. Even if this is set to | |
| 723 | + 100, you may still see sample throttling if this | |
| 724 | + length is exceeded. Set to 0 if you truly do not care | |
| 725 | + how much CPU is consumed. | |
| 726 | +===== ======================================================== | |
| 717 | 727 | |
| 718 | 728 | |
| 719 | −perf_event_paranoid: | |
| 720 | −==================== | |
| 729 | +perf_event_paranoid | |
| 730 | +=================== | |
| 721 | 731 | |
| 722 | 732 | Controls use of the performance events system by unprivileged |
| 723 | 733 | users (without CAP_SYS_ADMIN). The default value is 2. |
| 724 | 734 | |
| 725 | 735 | === ================================================================== |
| 726 | − -1 Allow use of (almost) all events by all users | |
| 736 | + -1 Allow use of (almost) all events by all users. | |
| 727 | 737 | |
| 728 | − Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK | |
| 738 | + Ignore mlock limit after perf_event_mlock_kb without | |
| 739 | + ``CAP_IPC_LOCK``. | |
| 729 | 740 | |
| 730 | −>=0 Disallow ftrace function tracepoint by users without CAP_SYS_ADMIN | |
| 741 | +>=0 Disallow ftrace function tracepoint by users without | |
| 742 | + ``CAP_SYS_ADMIN``. | |
| 731 | 743 | |
| 732 | − Disallow raw tracepoint access by users without CAP_SYS_ADMIN | |
| 744 | + Disallow raw tracepoint access by users without ``CAP_SYS_ADMIN``. | |
| 733 | 745 | |
| 734 | −>=1 Disallow CPU event access by users without CAP_SYS_ADMIN | |
| 746 | +>=1 Disallow CPU event access by users without ``CAP_SYS_ADMIN``. | |
| 735 | 747 | |
| 736 | −>=2 Disallow kernel profiling by users without CAP_SYS_ADMIN | |
| 748 | +>=2 Disallow kernel profiling by users without ``CAP_SYS_ADMIN``. | |
| 737 | 749 | === ================================================================== |
| 738 | 750 | |
| 739 | 751 | |
| 740 | −perf_event_max_stack: | |
| 741 | −===================== | |
| 752 | +perf_event_max_stack | |
| 753 | +==================== | |
| 742 | 754 | |
| 743 | −Controls maximum number of stack frames to copy for (attr.sample_type & | |
| 744 | −PERF_SAMPLE_CALLCHAIN) configured events, for instance, when using | |
| 745 | −'perf record -g' or 'perf trace --call-graph fp'. | |
| 755 | +Controls maximum number of stack frames to copy for (``attr.sample_type & | |
| 756 | +PERF_SAMPLE_CALLCHAIN``) configured events, for instance, when using | |
| 757 | +'``perf record -g``' or '``perf trace --call-graph fp``'. | |
| 746 | 758 | |
| 747 | 759 | This can only be done when no events are in use that have callchains |
| 748 | −enabled, otherwise writing to this file will return -EBUSY. | |
| 760 | +enabled, otherwise writing to this file will return ``-EBUSY``. | |
| 749 | 761 | |
| 750 | 762 | The default value is 127. |
| 751 | 763 | |
| 752 | 764 | |
| 753 | −perf_event_mlock_kb: | |
| 754 | −==================== | |
| 765 | +perf_event_mlock_kb | |
| 766 | +=================== | |
| 755 | 767 | |
| 756 | 768 | Control size of per-cpu ring buffer not counted agains mlock limit. |
| 757 | 769 | |
| 758 | 770 | The default value is 512 + 1 page |
| 759 | 771 | |
| 760 | 772 | |
| 761 | −perf_event_max_contexts_per_stack: | |
| 762 | −================================== | |
| 773 | +perf_event_max_contexts_per_stack | |
| 774 | +================================= | |
| 763 | 775 | |
| 764 | 776 | Controls maximum number of stack frame context entries for |
| 765 | −(attr.sample_type & PERF_SAMPLE_CALLCHAIN) configured events, for | |
| 766 | −instance, when using 'perf record -g' or 'perf trace --call-graph fp'. | |
| 777 | +(``attr.sample_type & PERF_SAMPLE_CALLCHAIN``) configured events, for | |
| 778 | +instance, when using '``perf record -g``' or '``perf trace --call-graph fp``'. | |
| 767 | 779 | |
| 768 | 780 | This can only be done when no events are in use that have callchains |
| 769 | −enabled, otherwise writing to this file will return -EBUSY. | |
| 781 | +enabled, otherwise writing to this file will return ``-EBUSY``. | |
| 770 | 782 | |
| 771 | 783 | The default value is 8. |
| 772 | 784 | |
| 773 | 785 | |
| 774 | −pid_max: | |
| 775 | −======== | |
| 786 | +pid_max | |
| 787 | +======= | |
| 776 | 788 | |
| 777 | 789 | PID allocation wrap value. When the kernel's next PID value |
| 778 | 790 | reaches this value, it wraps back to a minimum PID value. |
| 779 | −PIDs of value pid_max or larger are not allocated. | |
| 791 | +PIDs of value ``pid_max`` or larger are not allocated. | |
| 780 | 792 | |
| 781 | 793 | |
| 782 | −ns_last_pid: | |
| 783 | −============ | |
| 794 | +ns_last_pid | |
| 795 | +=========== | |
| 784 | 796 | |
| 785 | 797 | The last pid allocated in the current (the one task using this sysctl |
| 786 | 798 | lives in) pid namespace. When selecting a pid for a next task on fork |
| 787 | 799 | kernel tries to allocate a number starting from this one. |
| 788 | 800 | |
| 789 | 801 | |
| 790 | −powersave-nap: (PPC only) | |
| 791 | −========================= | |
| 802 | +powersave-nap (PPC only) | |
| 803 | +======================== | |
| 792 | 804 | |
| 793 | 805 | If set, Linux-PPC will use the 'nap' mode of powersaving, |
| 794 | 806 | otherwise the 'doze' mode will be used. |
| 795 | 807 | |
| 808 | + | |
| 796 | 809 | ============================================================== |
| 797 | 810 | |
| 798 | −printk: | |
| 799 | −======= | |
| 811 | +printk | |
| 812 | +====== | |
| 800 | 813 | |
| 801 | −The four values in printk denote: console_loglevel, | |
| 802 | −default_message_loglevel, minimum_console_loglevel and | |
| 803 | −default_console_loglevel respectively. | |
| 814 | +The four values in printk denote: ``console_loglevel``, | |
| 815 | +``default_message_loglevel``, ``minimum_console_loglevel`` and | |
| 816 | +``default_console_loglevel`` respectively. | |
| 804 | 817 | |
| 805 | 818 | These values influence printk() behavior when printing or |
| 806 | −logging error messages. See 'man 2 syslog' for more info on | |
| 819 | +logging error messages. See '``man 2 syslog``' for more info on | |
| 807 | 820 | the different loglevels. |
| 808 | 821 | |
| 809 | −- console_loglevel: | |
| 810 | − messages with a higher priority than | |
| 811 | − this will be printed to the console | |
| 812 | −- default_message_loglevel: | |
| 813 | − messages without an explicit priority | |
| 814 | − will be printed with this priority | |
| 815 | −- minimum_console_loglevel: | |
| 816 | − minimum (highest) value to which | |
| 817 | − console_loglevel can be set | |
| 818 | −- default_console_loglevel: | |
| 819 | − default value for console_loglevel | |
| 822 | +======================== ===================================== | |
| 823 | +console_loglevel messages with a higher priority than | |
| 824 | + this will be printed to the console | |
| 825 | +default_message_loglevel messages without an explicit priority | |
| 826 | + will be printed with this priority | |
| 827 | +minimum_console_loglevel minimum (highest) value to which | |
| 828 | + console_loglevel can be set | |
| 829 | +default_console_loglevel default value for console_loglevel | |
| 830 | +======================== ===================================== | |
| 820 | 831 | |
| 821 | 832 | |
| 822 | −printk_delay: | |
| 823 | −============= | |
| 833 | +printk_delay | |
| 834 | +============ | |
| 824 | 835 | |
| 825 | −Delay each printk message in printk_delay milliseconds | |
| 836 | +Delay each printk message in ``printk_delay`` milliseconds | |
| 826 | 837 | |
| 827 | 838 | Value from 0 - 10000 is allowed. |
| 828 | 839 | |
| 829 | 840 | |
| 830 | −printk_ratelimit: | |
| 831 | −================= | |
| 841 | +printk_ratelimit | |
| 842 | +================ | |
| 832 | 843 | |
| 833 | −Some warning messages are rate limited. printk_ratelimit specifies | |
| 844 | +Some warning messages are rate limited. ``printk_ratelimit`` specifies | |
| 834 | 845 | the minimum length of time between these messages (in seconds). |
| 835 | 846 | The default value is 5 seconds. |
| 836 | 847 | |
| 837 | 848 | A value of 0 will disable rate limiting. |
| 838 | 849 | |
| 839 | 850 | |
| 840 | −printk_ratelimit_burst: | |
| 841 | −======================= | |
| 851 | +printk_ratelimit_burst | |
| 852 | +====================== | |
| 842 | 853 | |
| 843 | −While long term we enforce one message per printk_ratelimit | |
| 854 | +While long term we enforce one message per `printk_ratelimit`_ | |
| 844 | 855 | seconds, we do allow a burst of messages to pass through. |
| 845 | −printk_ratelimit_burst specifies the number of messages we can | |
| 856 | +``printk_ratelimit_burst`` specifies the number of messages we can | |
| 846 | 857 | send before ratelimiting kicks in. |
| 847 | 858 | |
| 848 | 859 | The default value is 10 messages. |
| 849 | 860 | |
| 850 | 861 | |
| 851 | −printk_devkmsg: | |
| 852 | −=============== | |
| 853 | − | |
| 854 | −Control the logging to /dev/kmsg from userspace: | |
| 855 | − | |
| 856 | −ratelimit: | |
| 857 | − default, ratelimited | |
| 862 | +printk_devkmsg | |
| 863 | +============== | |
| 858 | 864 | |
| 859 | −on: unlimited logging to /dev/kmsg from userspace | |
| 865 | +Control the logging to ``/dev/kmsg`` from userspace: | |
| 860 | 866 | |
| 861 | −off: logging to /dev/kmsg disabled | |
| 867 | +========= ============================================= | |
| 868 | +ratelimit default, ratelimited | |
| 869 | +on unlimited logging to /dev/kmsg from userspace | |
| 870 | +off logging to /dev/kmsg disabled | |
| 871 | +========= ============================================= | |
| 862 | 872 | |
| 863 | −The kernel command line parameter printk.devkmsg= overrides this and is | |
| 873 | +The kernel command line parameter ``printk.devkmsg=`` overrides this and is | |
| 864 | 874 | a one-time setting until next reboot: once set, it cannot be changed by |
| 865 | 875 | this sysctl interface anymore. |
| 866 | 876 | |
| 877 | +============================================================== | |
| 867 | 878 | |
| 868 | −randomize_va_space: | |
| 869 | −=================== | |
| 879 | + | |
| 880 | +pty | |
| 881 | +=== | |
| 882 | + | |
| 883 | +See Documentation/filesystems/devpts.txt. | |
| 884 | + | |
| 885 | + | |
| 886 | +randomize_va_space | |
| 887 | +================== | |
| 870 | 888 | |
| 871 | 889 | This option can be used to select the type of process address |
| 872 | 890 | space randomization that is used in the system, for architectures |
| @@ -881,10 +899,10 @@ that support this feature. · 8 unmodified lines | ||
| 881 | 899 | This, among other things, implies that shared libraries will be |
| 882 | 900 | loaded to random addresses. Also for PIE-linked binaries, the |
| 883 | 901 | location of code start is randomized. This is the default if the |
| 884 | − CONFIG_COMPAT_BRK option is enabled. | |
| 902 | + ``CONFIG_COMPAT_BRK`` option is enabled. | |
| 885 | 903 | |
| 886 | 904 | 2 Additionally enable heap randomization. This is the default if |
| 887 | − CONFIG_COMPAT_BRK is disabled. | |
| 905 | + ``CONFIG_COMPAT_BRK`` is disabled. | |
| 888 | 906 | |
| 889 | 907 | There are a few legacy applications out there (such as some ancient |
| 890 | 908 | versions of libc.so.5 from 1996) that assume that brk area starts |
| @@ -894,31 +912,27 @@ that support this feature. · 3 unmodified lines | ||
| 894 | 912 | systems it is safe to choose full randomization. |
| 895 | 913 | |
| 896 | 914 | Systems with ancient and/or broken binaries should be configured |
| 897 | − with CONFIG_COMPAT_BRK enabled, which excludes the heap from process | |
| 915 | + with ``CONFIG_COMPAT_BRK`` enabled, which excludes the heap from process | |
| 898 | 916 | address space randomization. |
| 899 | 917 | == =========================================================================== |
| 900 | 918 | |
| 901 | 919 | |
| 902 | −reboot-cmd: (Sparc only) | |
| 903 | −======================== | |
| 904 | − | |
| 905 | −??? This seems to be a way to give an argument to the Sparc | |
| 906 | −ROM/Flash boot loader. Maybe to tell it what to do after | |
| 907 | −rebooting. ??? | |
| 920 | +real-root-dev | |
| 921 | +============= | |
| 908 | 922 | |
| 923 | +See :doc:`/admin-guide/initrd`. | |
| 909 | 924 | |
| 910 | −rtsig-max & rtsig-nr: | |
| 911 | −===================== | |
| 912 | 925 | |
| 913 | −The file rtsig-max can be used to tune the maximum number | |
| 914 | −of POSIX realtime (queued) signals that can be outstanding | |
| 915 | −in the system. | |
| 926 | +reboot-cmd (SPARC only) | |
| 927 | +======================= | |
| 916 | 928 | |
| 917 | −rtsig-nr shows the number of RT signals currently queued. | |
| 929 | +??? This seems to be a way to give an argument to the Sparc | |
| 930 | +ROM/Flash boot loader. Maybe to tell it what to do after | |
| 931 | +rebooting. ??? | |
| 918 | 932 | |
| 919 | 933 | |
| 920 | −sched_energy_aware: | |
| 921 | −=================== | |
| 934 | +sched_energy_aware | |
| 935 | +================== | |
| 922 | 936 | |
| 923 | 937 | Enables/disables Energy Aware Scheduling (EAS). EAS starts |
| 924 | 938 | automatically on platforms where it can run (that is, |
| @@ -928,75 +942,88 @@ requirements for EAS but you do not want to use it, change · 3 unmodified lines | ||
| 928 | 942 | this value to 0. |
| 929 | 943 | |
| 930 | 944 | |
| 931 | −sched_schedstats: | |
| 932 | −================= | |
| 945 | +sched_schedstats | |
| 946 | +================ | |
| 933 | 947 | |
| 934 | 948 | Enables/disables scheduler statistics. Enabling this feature |
| 935 | 949 | incurs a small amount of overhead in the scheduler but is |
| 936 | 950 | useful for debugging and performance tuning. |
| 937 | 951 | |
| 938 | 952 | |
| 939 | −sg-big-buff: | |
| 940 | −============ | |
| 953 | +seccomp | |
| 954 | +======= | |
| 955 | + | |
| 956 | +See :doc:`/userspace-api/seccomp_filter`. | |
| 957 | + | |
| 958 | + | |
| 959 | +sg-big-buff | |
| 960 | +=========== | |
| 941 | 961 | |
| 942 | 962 | This file shows the size of the generic SCSI (sg) buffer. |
| 943 | 963 | You can't tune it just yet, but you could change it on |
| 944 | −compile time by editing include/scsi/sg.h and changing | |
| 945 | −the value of SG_BIG_BUFF. | |
| 964 | +compile time by editing ``include/scsi/sg.h`` and changing | |
| 965 | +the value of ``SG_BIG_BUFF``. | |
| 946 | 966 | |
| 947 | 967 | There shouldn't be any reason to change this value. If |
| 948 | 968 | you can come up with one, you probably know what you |
| 949 | 969 | are doing anyway :) |
| 950 | 970 | |
| 951 | 971 | |
| 952 | −shmall: | |
| 953 | −======= | |
| 972 | +shmall | |
| 973 | +====== | |
| 954 | 974 | |
| 955 | 975 | This parameter sets the total amount of shared memory pages that |
| 956 | −can be used system wide. Hence, SHMALL should always be at least | |
| 957 | −ceil(shmmax/PAGE_SIZE). | |
| 976 | +can be used system wide. Hence, ``shmall`` should always be at least | |
| 977 | +``ceil(shmmax/PAGE_SIZE)``. | |
| 958 | 978 | |
| 959 | −If you are not sure what the default PAGE_SIZE is on your Linux | |
| 960 | −system, you can run the following command: | |
| 979 | +If you are not sure what the default ``PAGE_SIZE`` is on your Linux | |
| 980 | +system, you can run the following command:: | |
| 961 | 981 | |
| 962 | 982 | # getconf PAGE_SIZE |
| 963 | 983 | |
| 964 | 984 | |
| 965 | −shmmax: | |
| 966 | −======= | |
| 985 | +shmmax | |
| 986 | +====== | |
| 967 | 987 | |
| 968 | 988 | This value can be used to query and set the run time limit |
| 969 | 989 | on the maximum shared memory segment size that can be created. |
| 970 | 990 | Shared memory segments up to 1Gb are now supported in the |
| 971 | −kernel. This value defaults to SHMMAX. | |
| 991 | +kernel. This value defaults to ``SHMMAX``. | |
| 972 | 992 | |
| 973 | 993 | |
| 974 | −shm_rmid_forced: | |
| 975 | −================ | |
| 994 | +shmmni | |
| 995 | +====== | |
| 996 | + | |
| 997 | +This value determines the maximum number of shared memory segments. | |
| 998 | +4096 by default (``SHMMNI``). | |
| 999 | + | |
| 1000 | + | |
| 1001 | +shm_rmid_forced | |
| 1002 | +=============== | |
| 976 | 1003 | |
| 977 | 1004 | Linux lets you set resource limits, including how much memory one |
| 978 | −process can consume, via setrlimit(2). Unfortunately, shared memory | |
| 1005 | +process can consume, via ``setrlimit(2)``. Unfortunately, shared memory | |
| 979 | 1006 | segments are allowed to exist without association with any process, and |
| 980 | 1007 | thus might not be counted against any resource limits. If enabled, |
| 981 | 1008 | shared memory segments are automatically destroyed when their attach |
| 982 | 1009 | count becomes zero after a detach or a process termination. It will |
| 983 | 1010 | also destroy segments that were created, but never attached to, on exit |
| 984 | −from the process. The only use left for IPC_RMID is to immediately | |
| 1011 | +from the process. The only use left for ``IPC_RMID`` is to immediately | |
| 985 | 1012 | destroy an unattached segment. Of course, this breaks the way things are |
| 986 | 1013 | defined, so some applications might stop working. Note that this |
| 987 | 1014 | feature will do you no good unless you also configure your resource |
| 988 | −limits (in particular, RLIMIT_AS and RLIMIT_NPROC). Most systems don't | |
| 1015 | +limits (in particular, ``RLIMIT_AS`` and ``RLIMIT_NPROC``). Most systems don't | |
| 989 | 1016 | need this. |
| 990 | 1017 | |
| 991 | 1018 | Note that if you change this from 0 to 1, already created segments |
| 992 | 1019 | without users and with a dead originative process will be destroyed. |
| 993 | 1020 | |
| 994 | 1021 | |
| 995 | −sysctl_writes_strict: | |
| 996 | −===================== | |
| 1022 | +sysctl_writes_strict | |
| 1023 | +==================== | |
| 997 | 1024 | |
| 998 | 1025 | Control how file position affects the behavior of updating sysctl values |
| 999 | −via the /proc/sys interface: | |
| 1026 | +via the ``/proc/sys`` interface: | |
| 1000 | 1027 | |
| 1001 | 1028 | == ====================================================================== |
| 1002 | 1029 | -1 Legacy per-write sysctl value handling, with no printk warnings. |
| @@ -1013,8 +1040,8 @@ via the /proc/sys interface: · 10 unmodified lines | ||
| 1013 | 1040 | == ====================================================================== |
| 1014 | 1041 | |
| 1015 | 1042 | |
| 1016 | −softlockup_all_cpu_backtrace: | |
| 1017 | −============================= | |
| 1043 | +softlockup_all_cpu_backtrace | |
| 1044 | +============================ | |
| 1018 | 1045 | |
| 1019 | 1046 | This value controls the soft lockup detector thread's behavior |
| 1020 | 1047 | when a soft lockup condition is detected as to whether or not |
| @@ -1024,43 +1051,80 @@ be issued an NMI and instructed to capture stack trace. · 3 unmodified lines | ||
| 1024 | 1051 | This feature is only applicable for architectures which support |
| 1025 | 1052 | NMI. |
| 1026 | 1053 | |
| 1027 | −0: do nothing. This is the default behavior. | |
| 1054 | += ============================================ | |
| 1055 | +0 Do nothing. This is the default behavior. | |
| 1056 | +1 On detection capture more debug information. | |
| 1057 | += ============================================ | |
| 1028 | 1058 | |
| 1029 | −1: on detection capture more debug information. | |
| 1030 | 1059 | |
| 1060 | +softlockup_panic | |
| 1061 | +================= | |
| 1031 | 1062 | |
| 1032 | −soft_watchdog: | |
| 1033 | −============== | |
| 1063 | +This parameter can be used to control whether the kernel panics | |
| 1064 | +when a soft lockup is detected. | |
| 1034 | 1065 | |
| 1035 | −This parameter can be used to control the soft lockup detector. | |
| 1066 | += ============================================ | |
| 1067 | +0 Don't panic on soft lockup. | |
| 1068 | +1 Panic on soft lockup. | |
| 1069 | += ============================================ | |
| 1036 | 1070 | |
| 1037 | − 0 - disable the soft lockup detector | |
| 1071 | +This can also be set using the softlockup_panic kernel parameter. | |
| 1038 | 1072 | |
| 1039 | − 1 - enable the soft lockup detector | |
| 1073 | + | |
| 1074 | +soft_watchdog | |
| 1075 | +============= | |
| 1076 | + | |
| 1077 | +This parameter can be used to control the soft lockup detector. | |
| 1078 | + | |
| 1079 | += ================================= | |
| 1080 | +0 Disable the soft lockup detector. | |
| 1081 | +1 Enable the soft lockup detector. | |
| 1082 | += ================================= | |
| 1040 | 1083 | |
| 1041 | 1084 | The soft lockup detector monitors CPUs for threads that are hogging the CPUs |
| 1042 | 1085 | without rescheduling voluntarily, and thus prevent the 'watchdog/N' threads |
| 1043 | 1086 | from running. The mechanism depends on the CPUs ability to respond to timer |
| 1044 | 1087 | interrupts which are needed for the 'watchdog/N' threads to be woken up by |
| 1045 | −the watchdog timer function, otherwise the NMI watchdog - if enabled - can | |
| 1088 | +the watchdog timer function, otherwise the NMI watchdog — if enabled — can | |
| 1046 | 1089 | detect a hard lockup condition. |
| 1047 | 1090 | |
| 1048 | 1091 | |
| 1049 | −stack_erasing: | |
| 1050 | −============== | |
| 1092 | +stack_erasing | |
| 1093 | +============= | |
| 1051 | 1094 | |
| 1052 | 1095 | This parameter can be used to control kernel stack erasing at the end |
| 1053 | −of syscalls for kernels built with CONFIG_GCC_PLUGIN_STACKLEAK. | |
| 1096 | +of syscalls for kernels built with ``CONFIG_GCC_PLUGIN_STACKLEAK``. | |
| 1054 | 1097 | |
| 1055 | 1098 | That erasing reduces the information which kernel stack leak bugs |
| 1056 | 1099 | can reveal and blocks some uninitialized stack variable attacks. |
| 1057 | 1100 | The tradeoff is the performance impact: on a single CPU system kernel |
| 1058 | 1101 | compilation sees a 1% slowdown, other systems and workloads may vary. |
| 1059 | 1102 | |
| 1060 | − 0: kernel stack erasing is disabled, STACKLEAK_METRICS are not updated. | |
| 1103 | += ==================================================================== | |
| 1104 | +0 Kernel stack erasing is disabled, STACKLEAK_METRICS are not updated. | |
| 1105 | +1 Kernel stack erasing is enabled (default), it is performed before | |
| 1106 | + returning to the userspace at the end of syscalls. | |
| 1107 | += ==================================================================== | |
| 1061 | 1108 | |
| 1062 | − 1: kernel stack erasing is enabled (default), it is performed before | |
| 1063 | − returning to the userspace at the end of syscalls. | |
| 1109 | + | |
| 1110 | +stop-a (SPARC only) | |
| 1111 | +=================== | |
| 1112 | + | |
| 1113 | +Controls Stop-A: | |
| 1114 | + | |
| 1115 | += ==================================== | |
| 1116 | +0 Stop-A has no effect. | |
| 1117 | +1 Stop-A breaks to the PROM (default). | |
| 1118 | += ==================================== | |
| 1119 | + | |
| 1120 | +Stop-A is always enabled on a panic, so that the user can return to | |
| 1121 | +the boot PROM. | |
| 1122 | + | |
| 1123 | + | |
| 1124 | +sysrq | |
| 1125 | +===== | |
| 1126 | + | |
| 1127 | +See :doc:`/admin-guide/sysrq`. | |
| 1064 | 1128 | |
| 1065 | 1129 | |
| 1066 | 1130 | tainted |
| @@ -1090,30 +1154,30 @@ ORed together. The letters are seen in "Tainted" line of Oops reports. · 23 unmodified lines | ||
| 1090 | 1154 | 131072 `(T)` The kernel was built with the struct randomization plugin |
| 1091 | 1155 | ====== ===== ============================================================== |
| 1092 | 1156 | |
| 1093 | −See Documentation/admin-guide/tainted-kernels.rst for more information. | |
| 1157 | +See :doc:`/admin-guide/tainted-kernels` for more information. | |
| 1094 | 1158 | |
| 1095 | 1159 | |
| 1096 | −threads-max: | |
| 1097 | −============ | |
| 1160 | +threads-max | |
| 1161 | +=========== | |
| 1098 | 1162 | |
| 1099 | 1163 | This value controls the maximum number of threads that can be created |
| 1100 | −using fork(). | |
| 1164 | +using ``fork()``. | |
| 1101 | 1165 | |
| 1102 | 1166 | During initialization the kernel sets this value such that even if the |
| 1103 | 1167 | maximum number of threads is created, the thread structures occupy only |
| 1104 | 1168 | a part (1/8th) of the available RAM pages. |
| 1105 | 1169 | |
| 1106 | −The minimum value that can be written to threads-max is 1. | |
| 1170 | +The minimum value that can be written to ``threads-max`` is 1. | |
| 1107 | 1171 | |
| 1108 | −The maximum value that can be written to threads-max is given by the | |
| 1109 | −constant FUTEX_TID_MASK (0x3fffffff). | |
| 1172 | +The maximum value that can be written to ``threads-max`` is given by the | |
| 1173 | +constant ``FUTEX_TID_MASK`` (0x3fffffff). | |
| 1110 | 1174 | |
| 1111 | −If a value outside of this range is written to threads-max an error | |
| 1112 | −EINVAL occurs. | |
| 1175 | +If a value outside of this range is written to ``threads-max`` an | |
| 1176 | +``EINVAL`` error occurs. | |
| 1113 | 1177 | |
| 1114 | 1178 | |
| 1115 | −unknown_nmi_panic: | |
| 1116 | −================== | |
| 1179 | +unknown_nmi_panic | |
| 1180 | +================= | |
| 1117 | 1181 | |
| 1118 | 1182 | The value in this file affects behavior of handling NMI. When the |
| 1119 | 1183 | value is non-zero, unknown NMI is trapped and then panic occurs. At |
| @@ -1123,37 +1187,39 @@ NMI switch that most IA32 servers have fires unknown NMI up, for · 3 unmodified lines | ||
| 1123 | 1187 | example. If a system hangs up, try pressing the NMI switch. |
| 1124 | 1188 | |
| 1125 | 1189 | |
| 1126 | −watchdog: | |
| 1127 | −========= | |
| 1190 | +watchdog | |
| 1191 | +======== | |
| 1128 | 1192 | |
| 1129 | 1193 | This parameter can be used to disable or enable the soft lockup detector |
| 1130 | −_and_ the NMI watchdog (i.e. the hard lockup detector) at the same time. | |
| 1131 | − | |
| 1132 | − 0 - disable both lockup detectors | |
| 1194 | +*and* the NMI watchdog (i.e. the hard lockup detector) at the same time. | |
| 1133 | 1195 | |
| 1134 | − 1 - enable both lockup detectors | |
| 1196 | += ============================== | |
| 1197 | +0 Disable both lockup detectors. | |
| 1198 | +1 Enable both lockup detectors. | |
| 1199 | += ============================== | |
| 1135 | 1200 | |
| 1136 | 1201 | The soft lockup detector and the NMI watchdog can also be disabled or |
| 1137 | −enabled individually, using the soft_watchdog and nmi_watchdog parameters. | |
| 1138 | −If the watchdog parameter is read, for example by executing:: | |
| 1202 | +enabled individually, using the ``soft_watchdog`` and ``nmi_watchdog`` | |
| 1203 | +parameters. | |
| 1204 | +If the ``watchdog`` parameter is read, for example by executing:: | |
| 1139 | 1205 | |
| 1140 | 1206 | cat /proc/sys/kernel/watchdog |
| 1141 | 1207 | |
| 1142 | −the output of this command (0 or 1) shows the logical OR of soft_watchdog | |
| 1143 | −and nmi_watchdog. | |
| 1208 | +the output of this command (0 or 1) shows the logical OR of | |
| 1209 | +``soft_watchdog`` and ``nmi_watchdog``. | |
| 1144 | 1210 | |
| 1145 | 1211 | |
| 1146 | −watchdog_cpumask: | |
| 1147 | −================= | |
| 1212 | +watchdog_cpumask | |
| 1213 | +================ | |
| 1148 | 1214 | |
| 1149 | 1215 | This value can be used to control on which cpus the watchdog may run. |
| 1150 | −The default cpumask is all possible cores, but if NO_HZ_FULL is | |
| 1216 | +The default cpumask is all possible cores, but if ``NO_HZ_FULL`` is | |
| 1151 | 1217 | enabled in the kernel config, and cores are specified with the |
| 1152 | −nohz_full= boot argument, those cores are excluded by default. | |
| 1218 | +``nohz_full=`` boot argument, those cores are excluded by default. | |
| 1153 | 1219 | Offline cores can be included in this mask, and if the core is later |
| 1154 | 1220 | brought online, the watchdog will be started based on the mask value. |
| 1155 | 1221 | |
| 1156 | −Typically this value would only be touched in the nohz_full case | |
| 1222 | +Typically this value would only be touched in the ``nohz_full`` case | |
| 1157 | 1223 | to re-enable cores that by default were not running the watchdog, |
| 1158 | 1224 | if a kernel lockup was suspected on those cores. |
| 1159 | 1225 | |
| @@ -1164,12 +1230,12 @@ might say:: · 4 unmodified lines | ||
| 1164 | 1230 | echo 0,2-4 > /proc/sys/kernel/watchdog_cpumask |
| 1165 | 1231 | |
| 1166 | 1232 | |
| 1167 | −watchdog_thresh: | |
| 1168 | −================ | |
| 1233 | +watchdog_thresh | |
| 1234 | +=============== | |
| 1169 | 1235 | |
| 1170 | 1236 | This value can be used to control the frequency of hrtimer and NMI |
| 1171 | 1237 | events and the soft and hard lockup thresholds. The default threshold |
| 1172 | 1238 | is 10 seconds. |
| 1173 | 1239 | |
| 1174 | −The softlockup threshold is (2 * watchdog_thresh). Setting this | |
| 1240 | +The softlockup threshold is (``2 * watchdog_thresh``). Setting this | |
| 1175 | 1241 | tunable to zero will disable lockup detection altogether. |
| @@ -67,7 +67,8 @@ two flavors of JITs, the newer eBPF JIT currently supported on: · 66 unmodified lines | ||
| 67 | 67 | - sparc64 |
| 68 | 68 | - mips64 |
| 69 | 69 | - s390x |
| 70 | − - riscv | |
| 70 | + - riscv64 | |
| 71 | + - riscv32 | |
| 71 | 72 | |
| 72 | 73 | And the older cBPF JIT supported on the following archs: |
| 73 | 74 | |
| @@ -65,6 +65,12 @@ max_pid_namespaces · 64 unmodified lines | ||
| 65 | 65 | The maximum number of pid namespaces that any user in the current |
| 66 | 66 | user namespace may create. |
| 67 | 67 | |
| 68 | +max_time_namespaces | |
| 69 | +=================== | |
| 70 | + | |
| 71 | + The maximum number of time namespaces that any user in the current | |
| 72 | + user namespace may create. | |
| 73 | + | |
| 68 | 74 | max_user_namespaces |
| 69 | 75 | =================== |
| 70 | 76 | |
| @@ -128,6 +128,9 @@ allowed to examine the unevictable lru (mlocked pages) for pages to compact. · 127 unmodified lines | ||
| 128 | 128 | This should be used on systems where stalls for minor page faults are an |
| 129 | 129 | acceptable trade for large contiguous free memory. Set to 0 to prevent |
| 130 | 130 | compaction from moving pages that are unevictable. Default value is 1. |
| 131 | +On CONFIG_PREEMPT_RT the default value is 0 in order to avoid a page fault, due | |
| 132 | +to compaction, which would block the task from becomming active until the fault | |
| 133 | +is resolved. | |
| 131 | 134 | |
| 132 | 135 | |
| 133 | 136 | dirty_background_bytes |
| @@ -48,9 +48,10 @@ always allowed (by a user with admin privileges). · 47 unmodified lines | ||
| 48 | 48 | How do I use the magic SysRq key? |
| 49 | 49 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 50 | 50 | |
| 51 | −On x86 - You press the key combo :kbd:`ALT-SysRq-<command key>`. | |
| 51 | +On x86 | |
| 52 | + You press the key combo :kbd:`ALT-SysRq-<command key>`. | |
| 52 | 53 | |
| 53 | −.. note:: | |
| 54 | + .. note:: | |
| 54 | 55 | Some |
| 55 | 56 | keyboards may not have a key labeled 'SysRq'. The 'SysRq' key is |
| 56 | 57 | also known as the 'Print Screen' key. Also some keyboards cannot |
| @@ -58,14 +59,15 @@ On x86 - You press the key combo :kbd:`ALT-SysRq-<command key>`. · 1 unmodified line | ||
| 58 | 59 | have better luck with press :kbd:`Alt`, press :kbd:`SysRq`, |
| 59 | 60 | release :kbd:`SysRq`, press :kbd:`<command key>`, release everything. |
| 60 | 61 | |
| 61 | −On SPARC - You press :kbd:`ALT-STOP-<command key>`, I believe. | |
| 62 | +On SPARC | |
| 63 | + You press :kbd:`ALT-STOP-<command key>`, I believe. | |
| 62 | 64 | |
| 63 | 65 | On the serial console (PC style standard serial ports only) |
| 64 | 66 | You send a ``BREAK``, then within 5 seconds a command key. Sending |
| 65 | 67 | ``BREAK`` twice is interpreted as a normal BREAK. |
| 66 | 68 | |
| 67 | 69 | On PowerPC |
| 68 | − Press :kbd:`ALT - Print Screen` (or :kbd:`F13`) - :kbd:`<command key>`, | |
| 70 | + Press :kbd:`ALT - Print Screen` (or :kbd:`F13`) - :kbd:`<command key>`. | |
| 69 | 71 | :kbd:`Print Screen` (or :kbd:`F13`) - :kbd:`<command key>` may suffice. |
| 70 | 72 | |
| 71 | 73 | On other |
| @@ -73,7 +75,7 @@ On other · 1 unmodified line | ||
| 73 | 75 | let me know so I can add them to this section. |
| 74 | 76 | |
| 75 | 77 | On all |
| 76 | − write a character to /proc/sysrq-trigger. e.g.:: | |
| 78 | + Write a character to /proc/sysrq-trigger. e.g.:: | |
| 77 | 79 | |
| 78 | 80 | echo t > /proc/sysrq-trigger |
| 79 | 81 | |
| @@ -282,7 +284,7 @@ Just ask them on the linux-kernel mailing list: · 202 unmodified lines | ||
| 282 | 284 | Credits |
| 283 | 285 | ~~~~~~~ |
| 284 | 286 | |
| 285 | −Written by Mydraal <vulpyne@vulpyne.net> | |
| 286 | −Updated by Adam Sulmicki <adam@cfar.umd.edu> | |
| 287 | −Updated by Jeremy M. Dolan <jmd@turbogeek.org> 2001/01/28 10:15:59 | |
| 288 | −Added to by Crutcher Dunnavant <crutcher+kernel@datastacks.com> | |
| 287 | +- Written by Mydraal <vulpyne@vulpyne.net> | |
| 288 | +- Updated by Adam Sulmicki <adam@cfar.umd.edu> | |
| 289 | +- Updated by Jeremy M. Dolan <jmd@turbogeek.org> 2001/01/28 10:15:59 | |
| 290 | +- Added to by Crutcher Dunnavant <crutcher+kernel@datastacks.com> | |
| @@ -4,18 +4,18 @@ ARM TCM (Tightly-Coupled Memory) handling in Linux · 3 unmodified lines | ||
| 4 | 4 | |
| 5 | 5 | Written by Linus Walleij <linus.walleij@stericsson.com> |
| 6 | 6 | |
| 7 | −Some ARM SoC:s have a so-called TCM (Tightly-Coupled Memory). | |
| 7 | +Some ARM SoCs have a so-called TCM (Tightly-Coupled Memory). | |
| 8 | 8 | This is usually just a few (4-64) KiB of RAM inside the ARM |
| 9 | 9 | processor. |
| 10 | 10 | |
| 11 | −Due to being embedded inside the CPU The TCM has a | |
| 11 | +Due to being embedded inside the CPU, the TCM has a | |
| 12 | 12 | Harvard-architecture, so there is an ITCM (instruction TCM) |
| 13 | 13 | and a DTCM (data TCM). The DTCM can not contain any |
| 14 | 14 | instructions, but the ITCM can actually contain data. |
| 15 | 15 | The size of DTCM or ITCM is minimum 4KiB so the typical |
| 16 | 16 | minimum configuration is 4KiB ITCM and 4KiB DTCM. |
| 17 | 17 | |
| 18 | −ARM CPU:s have special registers to read out status, physical | |
| 18 | +ARM CPUs have special registers to read out status, physical | |
| 19 | 19 | location and size of TCM memories. arch/arm/include/asm/cputype.h |
| 20 | 20 | defines a CPUID_TCM register that you can read out from the |
| 21 | 21 | system control coprocessor. Documentation from ARM can be found |
| @@ -0,0 +1,112 @@ | ||
| 1 | +======================================================= | |
| 2 | +Activity Monitors Unit (AMU) extension in AArch64 Linux | |
| 3 | +======================================================= | |
| 4 | + | |
| 5 | +Author: Ionela Voinescu <ionela.voinescu@arm.com> | |
| 6 | + | |
| 7 | +Date: 2019-09-10 | |
| 8 | + | |
| 9 | +This document briefly describes the provision of Activity Monitors Unit | |
| 10 | +support in AArch64 Linux. | |
| 11 | + | |
| 12 | + | |
| 13 | +Architecture overview | |
| 14 | +--------------------- | |
| 15 | + | |
| 16 | +The activity monitors extension is an optional extension introduced by the | |
| 17 | +ARMv8.4 CPU architecture. | |
| 18 | + | |
| 19 | +The activity monitors unit, implemented in each CPU, provides performance | |
| 20 | +counters intended for system management use. The AMU extension provides a | |
| 21 | +system register interface to the counter registers and also supports an | |
| 22 | +optional external memory-mapped interface. | |
| 23 | + | |
| 24 | +Version 1 of the Activity Monitors architecture implements a counter group | |
| 25 | +of four fixed and architecturally defined 64-bit event counters. | |
| 26 | + - CPU cycle counter: increments at the frequency of the CPU. | |
| 27 | + - Constant counter: increments at the fixed frequency of the system | |
| 28 | + clock. | |
| 29 | + - Instructions retired: increments with every architecturally executed | |
| 30 | + instruction. | |
| 31 | + - Memory stall cycles: counts instruction dispatch stall cycles caused by | |
| 32 | + misses in the last level cache within the clock domain. | |
| 33 | + | |
| 34 | +When in WFI or WFE these counters do not increment. | |
| 35 | + | |
| 36 | +The Activity Monitors architecture provides space for up to 16 architected | |
| 37 | +event counters. Future versions of the architecture may use this space to | |
| 38 | +implement additional architected event counters. | |
| 39 | + | |
| 40 | +Additionally, version 1 implements a counter group of up to 16 auxiliary | |
| 41 | +64-bit event counters. | |
| 42 | + | |
| 43 | +On cold reset all counters reset to 0. | |
| 44 | + | |
| 45 | + | |
| 46 | +Basic support | |
| 47 | +------------- | |
| 48 | + | |
| 49 | +The kernel can safely run a mix of CPUs with and without support for the | |
| 50 | +activity monitors extension. Therefore, when CONFIG_ARM64_AMU_EXTN is | |
| 51 | +selected we unconditionally enable the capability to allow any late CPU | |
| 52 | +(secondary or hotplugged) to detect and use the feature. | |
| 53 | + | |
| 54 | +When the feature is detected on a CPU, we flag the availability of the | |
| 55 | +feature but this does not guarantee the correct functionality of the | |
| 56 | +counters, only the presence of the extension. | |
| 57 | + | |
| 58 | +Firmware (code running at higher exception levels, e.g. arm-tf) support is | |
| 59 | +needed to: | |
| 60 | + - Enable access for lower exception levels (EL2 and EL1) to the AMU | |
| 61 | + registers. | |
| 62 | + - Enable the counters. If not enabled these will read as 0. | |
| 63 | + - Save/restore the counters before/after the CPU is being put/brought up | |
| 64 | + from the 'off' power state. | |
| 65 | + | |
| 66 | +When using kernels that have this feature enabled but boot with broken | |
| 67 | +firmware the user may experience panics or lockups when accessing the | |
| 68 | +counter registers. Even if these symptoms are not observed, the values | |
| 69 | +returned by the register reads might not correctly reflect reality. Most | |
| 70 | +commonly, the counters will read as 0, indicating that they are not | |
| 71 | +enabled. | |
| 72 | + | |
| 73 | +If proper support is not provided in firmware it's best to disable | |
| 74 | +CONFIG_ARM64_AMU_EXTN. To be noted that for security reasons, this does not | |
| 75 | +bypass the setting of AMUSERENR_EL0 to trap accesses from EL0 (userspace) to | |
| 76 | +EL1 (kernel). Therefore, firmware should still ensure accesses to AMU registers | |
| 77 | +are not trapped in EL2/EL3. | |
| 78 | + | |
| 79 | +The fixed counters of AMUv1 are accessible though the following system | |
| 80 | +register definitions: | |
| 81 | + - SYS_AMEVCNTR0_CORE_EL0 | |
| 82 | + - SYS_AMEVCNTR0_CONST_EL0 | |
| 83 | + - SYS_AMEVCNTR0_INST_RET_EL0 | |
| 84 | + - SYS_AMEVCNTR0_MEM_STALL_EL0 | |
| 85 | + | |
| 86 | +Auxiliary platform specific counters can be accessed using | |
| 87 | +SYS_AMEVCNTR1_EL0(n), where n is a value between 0 and 15. | |
| 88 | + | |
| 89 | +Details can be found in: arch/arm64/include/asm/sysreg.h. | |
| 90 | + | |
| 91 | + | |
| 92 | +Userspace access | |
| 93 | +---------------- | |
| 94 | + | |
| 95 | +Currently, access from userspace to the AMU registers is disabled due to: | |
| 96 | + - Security reasons: they might expose information about code executed in | |
| 97 | + secure mode. | |
| 98 | + - Purpose: AMU counters are intended for system management use. | |
| 99 | + | |
| 100 | +Also, the presence of the feature is not visible to userspace. | |
| 101 | + | |
| 102 | + | |
| 103 | +Virtualization | |
| 104 | +-------------- | |
| 105 | + | |
| 106 | +Currently, access from userspace (EL0) and kernelspace (EL1) on the KVM | |
| 107 | +guest side is disabled due to: | |
| 108 | + - Security reasons: they might expose information about code executed | |
| 109 | + by other guests or the host. | |
| 110 | + | |
| 111 | +Any attempt to access the AMU registers will result in an UNDEFINED | |
| 112 | +exception being injected into the guest. | |
| @@ -248,6 +248,20 @@ Before jumping into the kernel, the following conditions must be met: · 247 unmodified lines | ||
| 248 | 248 | - HCR_EL2.APK (bit 40) must be initialised to 0b1 |
| 249 | 249 | - HCR_EL2.API (bit 41) must be initialised to 0b1 |
| 250 | 250 | |
| 251 | + For CPUs with Activity Monitors Unit v1 (AMUv1) extension present: | |
| 252 | + - If EL3 is present: | |
| 253 | + CPTR_EL3.TAM (bit 30) must be initialised to 0b0 | |
| 254 | + CPTR_EL2.TAM (bit 30) must be initialised to 0b0 | |
| 255 | + AMCNTENSET0_EL0 must be initialised to 0b1111 | |
| 256 | + AMCNTENSET1_EL0 must be initialised to a platform specific value | |
| 257 | + having 0b1 set for the corresponding bit for each of the auxiliary | |
| 258 | + counters present. | |
| 259 | + - If the kernel is entered at EL1: | |
| 260 | + AMCNTENSET0_EL0 must be initialised to 0b1111 | |
| 261 | + AMCNTENSET1_EL0 must be initialised to a platform specific value | |
| 262 | + having 0b1 set for the corresponding bit for each of the auxiliary | |
| 263 | + counters present. | |
| 264 | + | |
| 251 | 265 | The requirements described above for CPU mode, caches, MMUs, architected |
| 252 | 266 | timers, coherency and system registers apply to all CPUs. All CPUs must |
| 253 | 267 | enter the kernel in the same exception level. |
| @@ -6,6 +6,7 @@ ARM64 Architecture · 5 unmodified lines | ||
| 6 | 6 | :maxdepth: 1 |
| 7 | 7 | |
| 8 | 8 | acpi_object_usage |
| 9 | + amu | |
| 9 | 10 | arm-acpi |
| 10 | 11 | booting |
| 11 | 12 | cpu-feature-registers |
| @@ -110,6 +110,8 @@ stable kernels. · 109 unmodified lines | ||
| 110 | 110 | +----------------+-----------------+-----------------+-----------------------------+ |
| 111 | 111 | | Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 | |
| 112 | 112 | +----------------+-----------------+-----------------+-----------------------------+ |
| 113 | +| Cavium | ThunderX GICv3 | #38539 | N/A | | |
| 114 | ++----------------+-----------------+-----------------+-----------------------------+ | |
| 113 | 115 | | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 | |
| 114 | 116 | +----------------+-----------------+-----------------+-----------------------------+ |
| 115 | 117 | | Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 | |
| @@ -2,17 +2,9 @@ · 1 unmodified line | ||
| 2 | 2 | Generic Block Device Capability |
| 3 | 3 | =============================== |
| 4 | 4 | |
| 5 | −This file documents the sysfs file block/<disk>/capability | |
| 5 | +This file documents the sysfs file ``block/<disk>/capability``. | |
| 6 | 6 | |
| 7 | −capability is a hex word indicating which capabilities a specific disk | |
| 8 | −supports. For more information on bits not listed here, see | |
| 9 | −include/linux/genhd.h | |
| 7 | +``capability`` is a bitfield, printed in hexadecimal, indicating which | |
| 8 | +capabilities a specific block device supports: | |
| 10 | 9 | |
| 11 | −GENHD_FL_MEDIA_CHANGE_NOTIFY | |
| 12 | −---------------------------- | |
| 13 | − | |
| 14 | −Value: 4 | |
| 15 | − | |
| 16 | −When this bit is set, the disk supports Asynchronous Notification | |
| 17 | −of media change events. These events will be broadcast to user | |
| 18 | −space via kernel uevent. | |
| 10 | +.. kernel-doc:: include/linux/genhd.h | |
| @@ -20,11 +20,11 @@ Reporting bugs · 19 unmodified lines | ||
| 20 | 20 | Q: How do I report bugs for BPF kernel code? |
| 21 | 21 | -------------------------------------------- |
| 22 | 22 | A: Since all BPF kernel development as well as bpftool and iproute2 BPF |
| 23 | −loader development happens through the netdev kernel mailing list, | |
| 23 | +loader development happens through the bpf kernel mailing list, | |
| 24 | 24 | please report any found issues around BPF to the following mailing |
| 25 | 25 | list: |
| 26 | 26 | |
| 27 | − netdev@vger.kernel.org | |
| 27 | + bpf@vger.kernel.org | |
| 28 | 28 | |
| 29 | 29 | This may also include issues related to XDP, BPF tracing, etc. |
| 30 | 30 | |
| @@ -46,17 +46,12 @@ Submitting patches · 15 unmodified lines | ||
| 46 | 46 | |
| 47 | 47 | Q: To which mailing list do I need to submit my BPF patches? |
| 48 | 48 | ------------------------------------------------------------ |
| 49 | −A: Please submit your BPF patches to the netdev kernel mailing list: | |
| 49 | +A: Please submit your BPF patches to the bpf kernel mailing list: | |
| 50 | 50 | |
| 51 | − netdev@vger.kernel.org | |
| 52 | − | |
| 53 | −Historically, BPF came out of networking and has always been maintained | |
| 54 | −by the kernel networking community. Although these days BPF touches | |
| 55 | −many other subsystems as well, the patches are still routed mainly | |
| 56 | −through the networking community. | |
| 51 | + bpf@vger.kernel.org | |
| 57 | 52 | |
| 58 | 53 | In case your patch has changes in various different subsystems (e.g. |
| 59 | −tracing, security, etc), make sure to Cc the related kernel mailing | |
| 54 | +networking, tracing, security, etc), make sure to Cc the related kernel mailing | |
| 60 | 55 | lists and maintainers from there as well, so they are able to review |
| 61 | 56 | the changes and provide their Acked-by's to the patches. |
| 62 | 57 | |
| @@ -168,7 +163,7 @@ a BPF point of view. · 105 unmodified lines | ||
| 168 | 163 | Be aware that this is not a final verdict that the patch will |
| 169 | 164 | automatically get accepted into net or net-next trees eventually: |
| 170 | 165 | |
| 171 | −On the netdev kernel mailing list reviews can come in at any point | |
| 166 | +On the bpf kernel mailing list reviews can come in at any point | |
| 172 | 167 | in time. If discussions around a patch conclude that they cannot |
| 173 | 168 | get included as-is, we will either apply a follow-up fix or drop |
| 174 | 169 | them from the trees entirely. Therefore, we also reserve to rebase |
| @@ -494,15 +489,15 @@ A: You need cmake and gcc-c++ as build requisites for LLVM. Once you have · 319 unmodified lines | ||
| 494 | 489 | that set up, proceed with building the latest LLVM and clang version |
| 495 | 490 | from the git repositories:: |
| 496 | 491 | |
| 497 | − $ git clone http://llvm.org/git/llvm.git | |
| 498 | − $ cd llvm/tools | |
| 499 | − $ git clone --depth 1 http://llvm.org/git/clang.git | |
| 500 | − $ cd ..; mkdir build; cd build | |
| 501 | − $ cmake .. -DLLVM_TARGETS_TO_BUILD="BPF;X86" \ | |
| 492 | + $ git clone https://github.com/llvm/llvm-project.git | |
| 493 | + $ mkdir -p llvm-project/llvm/build/install | |
| 494 | + $ cd llvm-project/llvm/build | |
| 495 | + $ cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="BPF;X86" \ | |
| 496 | + -DLLVM_ENABLE_PROJECTS="clang" \ | |
| 502 | 497 | -DBUILD_SHARED_LIBS=OFF \ |
| 503 | 498 | -DCMAKE_BUILD_TYPE=Release \ |
| 504 | 499 | -DLLVM_BUILD_RUNTIME=OFF |
| 505 | − $ make -j $(getconf _NPROCESSORS_ONLN) | |
| 500 | + $ ninja | |
| 506 | 501 | |
| 507 | 502 | The built binaries can then be found in the build/bin/ directory, where |
| 508 | 503 | you can point the PATH variable to. |
| @@ -0,0 +1,142 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0+ | |
| 2 | +.. Copyright (C) 2020 Google LLC. | |
| 3 | + | |
| 4 | +================ | |
| 5 | +LSM BPF Programs | |
| 6 | +================ | |
| 7 | + | |
| 8 | +These BPF programs allow runtime instrumentation of the LSM hooks by privileged | |
| 9 | +users to implement system-wide MAC (Mandatory Access Control) and Audit | |
| 10 | +policies using eBPF. | |
| 11 | + | |
| 12 | +Structure | |
| 13 | +--------- | |
| 14 | + | |
| 15 | +The example shows an eBPF program that can be attached to the ``file_mprotect`` | |
| 16 | +LSM hook: | |
| 17 | + | |
| 18 | +.. c:function:: int file_mprotect(struct vm_area_struct *vma, unsigned long reqprot, unsigned long prot); | |
| 19 | + | |
| 20 | +Other LSM hooks which can be instrumented can be found in | |
| 21 | +``include/linux/lsm_hooks.h``. | |
| 22 | + | |
| 23 | +eBPF programs that use :doc:`/bpf/btf` do not need to include kernel headers | |
| 24 | +for accessing information from the attached eBPF program's context. They can | |
| 25 | +simply declare the structures in the eBPF program and only specify the fields | |
| 26 | +that need to be accessed. | |
| 27 | + | |
| 28 | +.. code-block:: c | |
| 29 | + | |
| 30 | + struct mm_struct { | |
| 31 | + unsigned long start_brk, brk, start_stack; | |
| 32 | + } __attribute__((preserve_access_index)); | |
| 33 | + | |
| 34 | + struct vm_area_struct { | |
| 35 | + unsigned long start_brk, brk, start_stack; | |
| 36 | + unsigned long vm_start, vm_end; | |
| 37 | + struct mm_struct *vm_mm; | |
| 38 | + } __attribute__((preserve_access_index)); | |
| 39 | + | |
| 40 | + | |
| 41 | +.. note:: The order of the fields is irrelevant. | |
| 42 | + | |
| 43 | +This can be further simplified (if one has access to the BTF information at | |
| 44 | +build time) by generating the ``vmlinux.h`` with: | |
| 45 | + | |
| 46 | +.. code-block:: console | |
| 47 | + | |
| 48 | + # bpftool btf dump file <path-to-btf-vmlinux> format c > vmlinux.h | |
| 49 | + | |
| 50 | +.. note:: ``path-to-btf-vmlinux`` can be ``/sys/kernel/btf/vmlinux`` if the | |
| 51 | + build environment matches the environment the BPF programs are | |
| 52 | + deployed in. | |
| 53 | + | |
| 54 | +The ``vmlinux.h`` can then simply be included in the BPF programs without | |
| 55 | +requiring the definition of the types. | |
| 56 | + | |
| 57 | +The eBPF programs can be declared using the``BPF_PROG`` | |
| 58 | +macros defined in `tools/lib/bpf/bpf_tracing.h`_. In this | |
| 59 | +example: | |
| 60 | + | |
| 61 | + * ``"lsm/file_mprotect"`` indicates the LSM hook that the program must | |
| 62 | + be attached to | |
| 63 | + * ``mprotect_audit`` is the name of the eBPF program | |
| 64 | + | |
| 65 | +.. code-block:: c | |
| 66 | + | |
| 67 | + SEC("lsm/file_mprotect") | |
| 68 | + int BPF_PROG(mprotect_audit, struct vm_area_struct *vma, | |
| 69 | + unsigned long reqprot, unsigned long prot, int ret) | |
| 70 | + { | |
| 71 | + /* ret is the return value from the previous BPF program | |
| 72 | + * or 0 if it's the first hook. | |
| 73 | + */ | |
| 74 | + if (ret != 0) | |
| 75 | + return ret; | |
| 76 | + | |
| 77 | + int is_heap; | |
| 78 | + | |
| 79 | + is_heap = (vma->vm_start >= vma->vm_mm->start_brk && | |
| 80 | + vma->vm_end <= vma->vm_mm->brk); | |
| 81 | + | |
| 82 | + /* Return an -EPERM or write information to the perf events buffer | |
| 83 | + * for auditing | |
| 84 | + */ | |
| 85 | + if (is_heap) | |
| 86 | + return -EPERM; | |
| 87 | + } | |
| 88 | + | |
| 89 | +The ``__attribute__((preserve_access_index))`` is a clang feature that allows | |
| 90 | +the BPF verifier to update the offsets for the access at runtime using the | |
| 91 | +:doc:`/bpf/btf` information. Since the BPF verifier is aware of the types, it | |
| 92 | +also validates all the accesses made to the various types in the eBPF program. | |
| 93 | + | |
| 94 | +Loading | |
| 95 | +------- | |
| 96 | + | |
| 97 | +eBPF programs can be loaded with the :manpage:`bpf(2)` syscall's | |
| 98 | +``BPF_PROG_LOAD`` operation: | |
| 99 | + | |
| 100 | +.. code-block:: c | |
| 101 | + | |
| 102 | + struct bpf_object *obj; | |
| 103 | + | |
| 104 | + obj = bpf_object__open("./my_prog.o"); | |
| 105 | + bpf_object__load(obj); | |
| 106 | + | |
| 107 | +This can be simplified by using a skeleton header generated by ``bpftool``: | |
| 108 | + | |
| 109 | +.. code-block:: console | |
| 110 | + | |
| 111 | + # bpftool gen skeleton my_prog.o > my_prog.skel.h | |
| 112 | + | |
| 113 | +and the program can be loaded by including ``my_prog.skel.h`` and using | |
| 114 | +the generated helper, ``my_prog__open_and_load``. | |
| 115 | + | |
| 116 | +Attachment to LSM Hooks | |
| 117 | +----------------------- | |
| 118 | + | |
| 119 | +The LSM allows attachment of eBPF programs as LSM hooks using :manpage:`bpf(2)` | |
| 120 | +syscall's ``BPF_RAW_TRACEPOINT_OPEN`` operation or more simply by | |
| 121 | +using the libbpf helper ``bpf_program__attach_lsm``. | |
| 122 | + | |
| 123 | +The program can be detached from the LSM hook by *destroying* the ``link`` | |
| 124 | +link returned by ``bpf_program__attach_lsm`` using ``bpf_link__destroy``. | |
| 125 | + | |
| 126 | +One can also use the helpers generated in ``my_prog.skel.h`` i.e. | |
| 127 | +``my_prog__attach`` for attachment and ``my_prog__destroy`` for cleaning up. | |
| 128 | + | |
| 129 | +Examples | |
| 130 | +-------- | |
| 131 | + | |
| 132 | +An example eBPF program can be found in | |
| 133 | +`tools/testing/selftests/bpf/progs/lsm.c`_ and the corresponding | |
| 134 | +userspace code in `tools/testing/selftests/bpf/prog_tests/test_lsm.c`_ | |
| 135 | + | |
| 136 | +.. Links | |
| 137 | +.. _tools/lib/bpf/bpf_tracing.h: | |
| 138 | + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/lib/bpf/bpf_tracing.h | |
| 139 | +.. _tools/testing/selftests/bpf/progs/lsm.c: | |
| 140 | + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/bpf/progs/lsm.c | |
| 141 | +.. _tools/testing/selftests/bpf/prog_tests/test_lsm.c: | |
| 142 | + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/bpf/prog_tests/test_lsm.c | |
| @@ -0,0 +1,213 @@ | ||
| 1 | +.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) | |
| 2 | + | |
| 3 | +============== | |
| 4 | +BPF drgn tools | |
| 5 | +============== | |
| 6 | + | |
| 7 | +drgn scripts is a convenient and easy to use mechanism to retrieve arbitrary | |
| 8 | +kernel data structures. drgn is not relying on kernel UAPI to read the data. | |
| 9 | +Instead it's reading directly from ``/proc/kcore`` or vmcore and pretty prints | |
| 10 | +the data based on DWARF debug information from vmlinux. | |
| 11 | + | |
| 12 | +This document describes BPF related drgn tools. | |
| 13 | + | |
| 14 | +See `drgn/tools`_ for all tools available at the moment and `drgn/doc`_ for | |
| 15 | +more details on drgn itself. | |
| 16 | + | |
| 17 | +bpf_inspect.py | |
| 18 | +-------------- | |
| 19 | + | |
| 20 | +Description | |
| 21 | +=========== | |
| 22 | + | |
| 23 | +`bpf_inspect.py`_ is a tool intended to inspect BPF programs and maps. It can | |
| 24 | +iterate over all programs and maps in the system and print basic information | |
| 25 | +about these objects, including id, type and name. | |
| 26 | + | |
| 27 | +The main use-case `bpf_inspect.py`_ covers is to show BPF programs of types | |
| 28 | +``BPF_PROG_TYPE_EXT`` and ``BPF_PROG_TYPE_TRACING`` attached to other BPF | |
| 29 | +programs via ``freplace``/``fentry``/``fexit`` mechanisms, since there is no | |
| 30 | +user-space API to get this information. | |
| 31 | + | |
| 32 | +Getting started | |
| 33 | +=============== | |
| 34 | + | |
| 35 | +List BPF programs (full names are obtained from BTF):: | |
| 36 | + | |
| 37 | + % sudo bpf_inspect.py prog | |
| 38 | + 27: BPF_PROG_TYPE_TRACEPOINT tracepoint__tcp__tcp_send_reset | |
| 39 | + 4632: BPF_PROG_TYPE_CGROUP_SOCK_ADDR tw_ipt_bind | |
| 40 | + 49464: BPF_PROG_TYPE_RAW_TRACEPOINT raw_tracepoint__sched_process_exit | |
| 41 | + | |
| 42 | +List BPF maps:: | |
| 43 | + | |
| 44 | + % sudo bpf_inspect.py map | |
| 45 | + 2577: BPF_MAP_TYPE_HASH tw_ipt_vips | |
| 46 | + 4050: BPF_MAP_TYPE_STACK_TRACE stack_traces | |
| 47 | + 4069: BPF_MAP_TYPE_PERCPU_ARRAY ned_dctcp_cntr | |
| 48 | + | |
| 49 | +Find BPF programs attached to BPF program ``test_pkt_access``:: | |
| 50 | + | |
| 51 | + % sudo bpf_inspect.py p | grep test_pkt_access | |
| 52 | + 650: BPF_PROG_TYPE_SCHED_CLS test_pkt_access | |
| 53 | + 654: BPF_PROG_TYPE_TRACING test_main linked:[650->25: BPF_TRAMP_FEXIT test_pkt_access->test_pkt_access()] | |
| 54 | + 655: BPF_PROG_TYPE_TRACING test_subprog1 linked:[650->29: BPF_TRAMP_FEXIT test_pkt_access->test_pkt_access_subprog1()] | |
| 55 | + 656: BPF_PROG_TYPE_TRACING test_subprog2 linked:[650->31: BPF_TRAMP_FEXIT test_pkt_access->test_pkt_access_subprog2()] | |
| 56 | + 657: BPF_PROG_TYPE_TRACING test_subprog3 linked:[650->21: BPF_TRAMP_FEXIT test_pkt_access->test_pkt_access_subprog3()] | |
| 57 | + 658: BPF_PROG_TYPE_EXT new_get_skb_len linked:[650->16: BPF_TRAMP_REPLACE test_pkt_access->get_skb_len()] | |
| 58 | + 659: BPF_PROG_TYPE_EXT new_get_skb_ifindex linked:[650->23: BPF_TRAMP_REPLACE test_pkt_access->get_skb_ifindex()] | |
| 59 | + 660: BPF_PROG_TYPE_EXT new_get_constant linked:[650->19: BPF_TRAMP_REPLACE test_pkt_access->get_constant()] | |
| 60 | + | |
| 61 | +It can be seen that there is a program ``test_pkt_access``, id 650 and there | |
| 62 | +are multiple other tracing and ext programs attached to functions in | |
| 63 | +``test_pkt_access``. | |
| 64 | + | |
| 65 | +For example the line:: | |
| 66 | + | |
| 67 | + 658: BPF_PROG_TYPE_EXT new_get_skb_len linked:[650->16: BPF_TRAMP_REPLACE test_pkt_access->get_skb_len()] | |
| 68 | + | |
| 69 | +, means that BPF program id 658, type ``BPF_PROG_TYPE_EXT``, name | |
| 70 | +``new_get_skb_len`` replaces (``BPF_TRAMP_REPLACE``) function ``get_skb_len()`` | |
| 71 | +that has BTF id 16 in BPF program id 650, name ``test_pkt_access``. | |
| 72 | + | |
| 73 | +Getting help: | |
| 74 | + | |
| 75 | +.. code-block:: none | |
| 76 | + | |
| 77 | + % sudo bpf_inspect.py | |
| 78 | + usage: bpf_inspect.py [-h] {prog,p,map,m} ... | |
| 79 | + | |
| 80 | + drgn script to list BPF programs or maps and their properties | |
| 81 | + unavailable via kernel API. | |
| 82 | + | |
| 83 | + See https://github.com/osandov/drgn/ for more details on drgn. | |
| 84 | + | |
| 85 | + optional arguments: | |
| 86 | + -h, --help show this help message and exit | |
| 87 | + | |
| 88 | + subcommands: | |
| 89 | + {prog,p,map,m} | |
| 90 | + prog (p) list BPF programs | |
| 91 | + map (m) list BPF maps | |
| 92 | + | |
| 93 | +Customization | |
| 94 | +============= | |
| 95 | + | |
| 96 | +The script is intended to be customized by developers to print relevant | |
| 97 | +information about BPF programs, maps and other objects. | |
| 98 | + | |
| 99 | +For example, to print ``struct bpf_prog_aux`` for BPF program id 53077: | |
| 100 | + | |
| 101 | +.. code-block:: none | |
| 102 | + | |
| 103 | + % git diff | |
| 104 | + diff --git a/tools/bpf_inspect.py b/tools/bpf_inspect.py | |
| 105 | + index 650e228..aea2357 100755 | |
| 106 | + --- a/tools/bpf_inspect.py | |
| 107 | + +++ b/tools/bpf_inspect.py | |
| 108 | + @@ -112,7 +112,9 @@ def list_bpf_progs(args): | |
| 109 | + if linked: | |
| 110 | + linked = f" linked:[{linked}]" | |
| 111 | + | |
| 112 | + - print(f"{id_:>6}: {type_:32} {name:32} {linked}") | |
| 113 | + + if id_ == 53077: | |
| 114 | + + print(f"{id_:>6}: {type_:32} {name:32}") | |
| 115 | + + print(f"{bpf_prog.aux}") | |
| 116 | + | |
| 117 | + | |
| 118 | + def list_bpf_maps(args): | |
| 119 | + | |
| 120 | +It produces the output:: | |
| 121 | + | |
| 122 | + % sudo bpf_inspect.py p | |
| 123 | + 53077: BPF_PROG_TYPE_XDP tw_xdp_policer | |
| 124 | + *(struct bpf_prog_aux *)0xffff8893fad4b400 = { | |
| 125 | + .refcnt = (atomic64_t){ | |
| 126 | + .counter = (long)58, | |
| 127 | + }, | |
| 128 | + .used_map_cnt = (u32)1, | |
| 129 | + .max_ctx_offset = (u32)8, | |
| 130 | + .max_pkt_offset = (u32)15, | |
| 131 | + .max_tp_access = (u32)0, | |
| 132 | + .stack_depth = (u32)8, | |
| 133 | + .id = (u32)53077, | |
| 134 | + .func_cnt = (u32)0, | |
| 135 | + .func_idx = (u32)0, | |
| 136 | + .attach_btf_id = (u32)0, | |
| 137 | + .linked_prog = (struct bpf_prog *)0x0, | |
| 138 | + .verifier_zext = (bool)0, | |
| 139 | + .offload_requested = (bool)0, | |
| 140 | + .attach_btf_trace = (bool)0, | |
| 141 | + .func_proto_unreliable = (bool)0, | |
| 142 | + .trampoline_prog_type = (enum bpf_tramp_prog_type)BPF_TRAMP_FENTRY, | |
| 143 | + .trampoline = (struct bpf_trampoline *)0x0, | |
| 144 | + .tramp_hlist = (struct hlist_node){ | |
| 145 | + .next = (struct hlist_node *)0x0, | |
| 146 | + .pprev = (struct hlist_node **)0x0, | |
| 147 | + }, | |
| 148 | + .attach_func_proto = (const struct btf_type *)0x0, | |
| 149 | + .attach_func_name = (const char *)0x0, | |
| 150 | + .func = (struct bpf_prog **)0x0, | |
| 151 | + .jit_data = (void *)0x0, | |
| 152 | + .poke_tab = (struct bpf_jit_poke_descriptor *)0x0, | |
| 153 | + .size_poke_tab = (u32)0, | |
| 154 | + .ksym_tnode = (struct latch_tree_node){ | |
| 155 | + .node = (struct rb_node [2]){ | |
| 156 | + { | |
| 157 | + .__rb_parent_color = (unsigned long)18446612956263126665, | |
| 158 | + .rb_right = (struct rb_node *)0x0, | |
| 159 | + .rb_left = (struct rb_node *)0xffff88a0be3d0088, | |
| 160 | + }, | |
| 161 | + { | |
| 162 | + .__rb_parent_color = (unsigned long)18446612956263126689, | |
| 163 | + .rb_right = (struct rb_node *)0x0, | |
| 164 | + .rb_left = (struct rb_node *)0xffff88a0be3d00a0, | |
| 165 | + }, | |
| 166 | + }, | |
| 167 | + }, | |
| 168 | + .ksym_lnode = (struct list_head){ | |
| 169 | + .next = (struct list_head *)0xffff88bf481830b8, | |
| 170 | + .prev = (struct list_head *)0xffff888309f536b8, | |
| 171 | + }, | |
| 172 | + .ops = (const struct bpf_prog_ops *)xdp_prog_ops+0x0 = 0xffffffff820fa350, | |
| 173 | + .used_maps = (struct bpf_map **)0xffff889ff795de98, | |
| 174 | + .prog = (struct bpf_prog *)0xffffc9000cf2d000, | |
| 175 | + .user = (struct user_struct *)root_user+0x0 = 0xffffffff82444820, | |
| 176 | + .load_time = (u64)2408348759285319, | |
| 177 | + .cgroup_storage = (struct bpf_map *[2]){}, | |
| 178 | + .name = (char [16])"tw_xdp_policer", | |
| 179 | + .security = (void *)0xffff889ff795d548, | |
| 180 | + .offload = (struct bpf_prog_offload *)0x0, | |
| 181 | + .btf = (struct btf *)0xffff8890ce6d0580, | |
| 182 | + .func_info = (struct bpf_func_info *)0xffff889ff795d240, | |
| 183 | + .func_info_aux = (struct bpf_func_info_aux *)0xffff889ff795de20, | |
| 184 | + .linfo = (struct bpf_line_info *)0xffff888a707afc00, | |
| 185 | + .jited_linfo = (void **)0xffff8893fad48600, | |
| 186 | + .func_info_cnt = (u32)1, | |
| 187 | + .nr_linfo = (u32)37, | |
| 188 | + .linfo_idx = (u32)0, | |
| 189 | + .num_exentries = (u32)0, | |
| 190 | + .extable = (struct exception_table_entry *)0xffffffffa032d950, | |
| 191 | + .stats = (struct bpf_prog_stats *)0x603fe3a1f6d0, | |
| 192 | + .work = (struct work_struct){ | |
| 193 | + .data = (atomic_long_t){ | |
| 194 | + .counter = (long)0, | |
| 195 | + }, | |
| 196 | + .entry = (struct list_head){ | |
| 197 | + .next = (struct list_head *)0x0, | |
| 198 | + .prev = (struct list_head *)0x0, | |
| 199 | + }, | |
| 200 | + .func = (work_func_t)0x0, | |
| 201 | + }, | |
| 202 | + .rcu = (struct callback_head){ | |
| 203 | + .next = (struct callback_head *)0x0, | |
| 204 | + .func = (void (*)(struct callback_head *))0x0, | |
| 205 | + }, | |
| 206 | + } | |
| 207 | + | |
| 208 | + | |
| 209 | +.. Links | |
| 210 | +.. _drgn/doc: https://drgn.readthedocs.io/en/latest/ | |
| 211 | +.. _drgn/tools: https://github.com/osandov/drgn/tree/master/tools | |
| 212 | +.. _bpf_inspect.py: | |
| 213 | + https://github.com/osandov/drgn/blob/master/tools/bpf_inspect.py | |
| @@ -45,14 +45,16 @@ Program types · 44 unmodified lines | ||
| 45 | 45 | prog_cgroup_sockopt |
| 46 | 46 | prog_cgroup_sysctl |
| 47 | 47 | prog_flow_dissector |
| 48 | + bpf_lsm | |
| 48 | 49 | |
| 49 | 50 | |
| 50 | −Testing BPF | |
| 51 | −=========== | |
| 51 | +Testing and debugging BPF | |
| 52 | +========================= | |
| 52 | 53 | |
| 53 | 54 | .. toctree:: |
| 54 | 55 | :maxdepth: 1 |
| 55 | 56 | |
| 57 | + drgn | |
| 56 | 58 | s390 |
| 57 | 59 | |
| 58 | 60 | |
| @@ -38,7 +38,11 @@ needs_sphinx = '1.3' · 37 unmodified lines | ||
| 38 | 38 | # ones. |
| 39 | 39 | extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', |
| 40 | 40 | 'kfigure', 'sphinx.ext.ifconfig', 'automarkup', |
| 41 | − 'maintainers_include'] | |
| 41 | + 'maintainers_include', 'sphinx.ext.autosectionlabel' ] | |
| 42 | + | |
| 43 | +# Ensure that autosectionlabel will produce unique names | |
| 44 | +autosectionlabel_prefix_document = True | |
| 45 | +autosectionlabel_maxdepth = 2 | |
| 42 | 46 | |
| 43 | 47 | # The name of the math extension changed on Sphinx 1.4 |
| 44 | 48 | if (major == 1 and minor > 3) or (major > 1): |
| @@ -8,41 +8,81 @@ This is the beginning of a manual for core kernel APIs. The conversion · 7 unmodified lines | ||
| 8 | 8 | Core utilities |
| 9 | 9 | ============== |
| 10 | 10 | |
| 11 | +This section has general and "core core" documentation. The first is a | |
| 12 | +massive grab-bag of kerneldoc info left over from the docbook days; it | |
| 13 | +should really be broken up someday when somebody finds the energy to do | |
| 14 | +it. | |
| 15 | + | |
| 11 | 16 | .. toctree:: |
| 12 | 17 | :maxdepth: 1 |
| 13 | 18 | |
| 14 | 19 | kernel-api |
| 20 | + workqueue | |
| 21 | + printk-formats | |
| 22 | + symbol-namespaces | |
| 23 | + | |
| 24 | +Data structures and low-level utilities | |
| 25 | +======================================= | |
| 26 | + | |
| 27 | +Library functionality that is used throughout the kernel. | |
| 28 | + | |
| 29 | +.. toctree:: | |
| 30 | + :maxdepth: 1 | |
| 31 | + | |
| 32 | + kobject | |
| 15 | 33 | assoc_array |
| 34 | + xarray | |
| 35 | + idr | |
| 36 | + circular-buffers | |
| 37 | + generic-radix-tree | |
| 38 | + packing | |
| 39 | + timekeeping | |
| 40 | + errseq | |
| 41 | + | |
| 42 | +Concurrency primitives | |
| 43 | +====================== | |
| 44 | + | |
| 45 | +How Linux keeps everything from happening at the same time. See | |
| 46 | +:doc:`/locking/index` for more related documentation. | |
| 47 | + | |
| 48 | +.. toctree:: | |
| 49 | + :maxdepth: 1 | |
| 50 | + | |
| 16 | 51 | atomic_ops |
| 17 | − cachetlb | |
| 18 | 52 | refcount-vs-atomic |
| 19 | − cpu_hotplug | |
| 20 | − idr | |
| 21 | 53 | local_ops |
| 22 | − workqueue | |
| 54 | + padata | |
| 55 | + ../RCU/index | |
| 56 | + | |
| 57 | +Low-level hardware management | |
| 58 | +============================= | |
| 59 | + | |
| 60 | +Cache management, managing CPU hotplug, etc. | |
| 61 | + | |
| 62 | +.. toctree:: | |
| 63 | + :maxdepth: 1 | |
| 64 | + | |
| 65 | + cachetlb | |
| 66 | + cpu_hotplug | |
| 67 | + memory-hotplug | |
| 23 | 68 | genericirq |
| 24 | − xarray | |
| 25 | − librs | |
| 26 | − genalloc | |
| 27 | − errseq | |
| 28 | − packing | |
| 29 | − printk-formats | |
| 30 | − circular-buffers | |
| 31 | − generic-radix-tree | |
| 69 | + protection-keys | |
| 70 | + | |
| 71 | +Memory management | |
| 72 | +================= | |
| 73 | + | |
| 74 | +How to allocate and use memory in the kernel. Note that there is a lot | |
| 75 | +more memory-management documentation in :doc:`/vm/index`. | |
| 76 | + | |
| 77 | +.. toctree:: | |
| 78 | + :maxdepth: 1 | |
| 79 | + | |
| 32 | 80 | memory-allocation |
| 33 | 81 | mm-api |
| 82 | + genalloc | |
| 34 | 83 | pin_user_pages |
| 35 | − gfp_mask-from-fs-io | |
| 36 | − timekeeping | |
| 37 | 84 | boot-time-mm |
| 38 | − memory-hotplug | |
| 39 | − protection-keys | |
| 40 | − ../RCU/index | |
| 41 | − gcc-plugins | |
| 42 | − symbol-namespaces | |
| 43 | − padata | |
| 44 | − ioctl | |
| 45 | − | |
| 85 | + gfp_mask-from-fs-io | |
| 46 | 86 | |
| 47 | 87 | Interfaces for kernel debugging |
| 48 | 88 | =============================== |
| @@ -53,6 +93,16 @@ Interfaces for kernel debugging · 4 unmodified lines | ||
| 53 | 93 | debug-objects |
| 54 | 94 | tracepoint |
| 55 | 95 | |
| 96 | +Everything else | |
| 97 | +=============== | |
| 98 | + | |
| 99 | +Documents that don't fit elsewhere or which have yet to be categorized. | |
| 100 | + | |
| 101 | +.. toctree:: | |
| 102 | + :maxdepth: 1 | |
| 103 | + | |
| 104 | + librs | |
| 105 | + | |
| 56 | 106 | .. only:: subproject and html |
| 57 | 107 | |
| 58 | 108 | Indices |
| @@ -25,7 +25,7 @@ some terms we will be working with. · 24 unmodified lines | ||
| 25 | 25 | usually embedded within some other structure which contains the stuff |
| 26 | 26 | the code is really interested in. |
| 27 | 27 | |
| 28 | − No structure should EVER have more than one kobject embedded within it. | |
| 28 | + No structure should **EVER** have more than one kobject embedded within it. | |
| 29 | 29 | If it does, the reference counting for the object is sure to be messed |
| 30 | 30 | up and incorrect, and your code will be buggy. So do not do this. |
| 31 | 31 | |
| @@ -55,7 +55,7 @@ a larger, domain-specific object. To this end, kobjects will be found · 23 unmodified lines | ||
| 55 | 55 | embedded in other structures. If you are used to thinking of things in |
| 56 | 56 | object-oriented terms, kobjects can be seen as a top-level, abstract class |
| 57 | 57 | from which other classes are derived. A kobject implements a set of |
| 58 | −capabilities which are not particularly useful by themselves, but which are | |
| 58 | +capabilities which are not particularly useful by themselves, but are | |
| 59 | 59 | nice to have in other objects. The C language does not allow for the |
| 60 | 60 | direct expression of inheritance, so other techniques - such as structure |
| 61 | 61 | embedding - must be used. |
| @@ -65,12 +65,12 @@ this is analogous as to how "list_head" structs are rarely useful on · 3 unmodified lines | ||
| 65 | 65 | their own, but are invariably found embedded in the larger objects of |
| 66 | 66 | interest.) |
| 67 | 67 | |
| 68 | −So, for example, the UIO code in drivers/uio/uio.c has a structure that | |
| 68 | +So, for example, the UIO code in ``drivers/uio/uio.c`` has a structure that | |
| 69 | 69 | defines the memory region associated with a uio device:: |
| 70 | 70 | |
| 71 | 71 | struct uio_map { |
| 72 | − struct kobject kobj; | |
| 73 | − struct uio_mem *mem; | |
| 72 | + struct kobject kobj; | |
| 73 | + struct uio_mem *mem; | |
| 74 | 74 | }; |
| 75 | 75 | |
| 76 | 76 | If you have a struct uio_map structure, finding its embedded kobject is |
| @@ -78,30 +78,30 @@ just a matter of using the kobj member. Code that works with kobjects will · 1 unmodified line | ||
| 78 | 78 | often have the opposite problem, however: given a struct kobject pointer, |
| 79 | 79 | what is the pointer to the containing structure? You must avoid tricks |
| 80 | 80 | (such as assuming that the kobject is at the beginning of the structure) |
| 81 | −and, instead, use the container_of() macro, found in <linux/kernel.h>:: | |
| 81 | +and, instead, use the container_of() macro, found in ``<linux/kernel.h>``:: | |
| 82 | 82 | |
| 83 | 83 | container_of(pointer, type, member) |
| 84 | 84 | |
| 85 | 85 | where: |
| 86 | 86 | |
| 87 | − * "pointer" is the pointer to the embedded kobject, | |
| 88 | − * "type" is the type of the containing structure, and | |
| 89 | − * "member" is the name of the structure field to which "pointer" points. | |
| 87 | + * ``pointer`` is the pointer to the embedded kobject, | |
| 88 | + * ``type`` is the type of the containing structure, and | |
| 89 | + * ``member`` is the name of the structure field to which ``pointer`` points. | |
| 90 | 90 | |
| 91 | 91 | The return value from container_of() is a pointer to the corresponding |
| 92 | −container type. So, for example, a pointer "kp" to a struct kobject | |
| 93 | −embedded *within* a struct uio_map could be converted to a pointer to the | |
| 94 | −*containing* uio_map structure with:: | |
| 92 | +container type. So, for example, a pointer ``kp`` to a struct kobject | |
| 93 | +embedded **within** a struct uio_map could be converted to a pointer to the | |
| 94 | +**containing** uio_map structure with:: | |
| 95 | 95 | |
| 96 | 96 | struct uio_map *u_map = container_of(kp, struct uio_map, kobj); |
| 97 | 97 | |
| 98 | −For convenience, programmers often define a simple macro for "back-casting" | |
| 98 | +For convenience, programmers often define a simple macro for **back-casting** | |
| 99 | 99 | kobject pointers to the containing type. Exactly this happens in the |
| 100 | −earlier drivers/uio/uio.c, as you can see here:: | |
| 100 | +earlier ``drivers/uio/uio.c``, as you can see here:: | |
| 101 | 101 | |
| 102 | 102 | struct uio_map { |
| 103 | − struct kobject kobj; | |
| 104 | − struct uio_mem *mem; | |
| 103 | + struct kobject kobj; | |
| 104 | + struct uio_mem *mem; | |
| 105 | 105 | }; |
| 106 | 106 | |
| 107 | 107 | #define to_map(map) container_of(map, struct uio_map, kobj) |
| @@ -125,7 +125,7 @@ must have an associated kobj_type. After calling kobject_init(), to · 17 unmodified lines | ||
| 125 | 125 | register the kobject with sysfs, the function kobject_add() must be called:: |
| 126 | 126 | |
| 127 | 127 | int kobject_add(struct kobject *kobj, struct kobject *parent, |
| 128 | − const char *fmt, ...); | |
| 128 | + const char *fmt, ...); | |
| 129 | 129 | |
| 130 | 130 | This sets up the parent of the kobject and the name for the kobject |
| 131 | 131 | properly. If the kobject is to be associated with a specific kset, |
| @@ -172,13 +172,13 @@ call to kobject_uevent():: · 40 unmodified lines | ||
| 172 | 172 | |
| 173 | 173 | int kobject_uevent(struct kobject *kobj, enum kobject_action action); |
| 174 | 174 | |
| 175 | −Use the KOBJ_ADD action for when the kobject is first added to the kernel. | |
| 175 | +Use the **KOBJ_ADD** action for when the kobject is first added to the kernel. | |
| 176 | 176 | This should be done only after any attributes or children of the kobject |
| 177 | 177 | have been initialized properly, as userspace will instantly start to look |
| 178 | 178 | for them when this call happens. |
| 179 | 179 | |
| 180 | 180 | When the kobject is removed from the kernel (details on how to do that are |
| 181 | −below), the uevent for KOBJ_REMOVE will be automatically created by the | |
| 181 | +below), the uevent for **KOBJ_REMOVE** will be automatically created by the | |
| 182 | 182 | kobject core, so the caller does not have to worry about doing that by |
| 183 | 183 | hand. |
| 184 | 184 | |
| @@ -238,7 +238,7 @@ Both types of attributes used here, with a kobject that has been created · 53 unmodified lines | ||
| 238 | 238 | with the kobject_create_and_add(), can be of type kobj_attribute, so no |
| 239 | 239 | special custom attribute is needed to be created. |
| 240 | 240 | |
| 241 | −See the example module, samples/kobject/kobject-example.c for an | |
| 241 | +See the example module, ``samples/kobject/kobject-example.c`` for an | |
| 242 | 242 | implementation of a simple kobject and attributes. |
| 243 | 243 | |
| 244 | 244 | |
| @@ -270,10 +270,10 @@ such a method has a form like:: · 25 unmodified lines | ||
| 270 | 270 | |
| 271 | 271 | void my_object_release(struct kobject *kobj) |
| 272 | 272 | { |
| 273 | − struct my_object *mine = container_of(kobj, struct my_object, kobj); | |
| 273 | + struct my_object *mine = container_of(kobj, struct my_object, kobj); | |
| 274 | 274 | |
| 275 | − /* Perform any additional cleanup on this object, then... */ | |
| 276 | − kfree(mine); | |
| 275 | + /* Perform any additional cleanup on this object, then... */ | |
| 276 | + kfree(mine); | |
| 277 | 277 | } |
| 278 | 278 | |
| 279 | 279 | One important point cannot be overstated: every kobject must have a |
| @@ -297,11 +297,11 @@ instead, it is associated with the ktype. So let us introduce struct · 17 unmodified lines | ||
| 297 | 297 | kobj_type:: |
| 298 | 298 | |
| 299 | 299 | struct kobj_type { |
| 300 | − void (*release)(struct kobject *kobj); | |
| 301 | − const struct sysfs_ops *sysfs_ops; | |
| 302 | − struct attribute **default_attrs; | |
| 303 | − const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj); | |
| 304 | − const void *(*namespace)(struct kobject *kobj); | |
| 300 | + void (*release)(struct kobject *kobj); | |
| 301 | + const struct sysfs_ops *sysfs_ops; | |
| 302 | + struct attribute **default_attrs; | |
| 303 | + const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj); | |
| 304 | + const void *(*namespace)(struct kobject *kobj); | |
| 305 | 305 | }; |
| 306 | 306 | |
| 307 | 307 | This structure is used to describe a particular type of kobject (or, more |
| @@ -352,8 +352,8 @@ created and never declared statically or on the stack. To create a new · 44 unmodified lines | ||
| 352 | 352 | kset use:: |
| 353 | 353 | |
| 354 | 354 | struct kset *kset_create_and_add(const char *name, |
| 355 | − struct kset_uevent_ops *u, | |
| 356 | − struct kobject *parent); | |
| 355 | + struct kset_uevent_ops *u, | |
| 356 | + struct kobject *parent); | |
| 357 | 357 | |
| 358 | 358 | When you are finished with the kset, call:: |
| 359 | 359 | |
| @@ -365,16 +365,16 @@ Because other references to the kset may still exist, the release may happen · 5 unmodified lines | ||
| 365 | 365 | after kset_unregister() returns. |
| 366 | 366 | |
| 367 | 367 | An example of using a kset can be seen in the |
| 368 | −samples/kobject/kset-example.c file in the kernel tree. | |
| 368 | +``samples/kobject/kset-example.c`` file in the kernel tree. | |
| 369 | 369 | |
| 370 | 370 | If a kset wishes to control the uevent operations of the kobjects |
| 371 | 371 | associated with it, it can use the struct kset_uevent_ops to handle it:: |
| 372 | 372 | |
| 373 | 373 | struct kset_uevent_ops { |
| 374 | − int (*filter)(struct kset *kset, struct kobject *kobj); | |
| 375 | − const char *(*name)(struct kset *kset, struct kobject *kobj); | |
| 376 | − int (*uevent)(struct kset *kset, struct kobject *kobj, | |
| 377 | − struct kobj_uevent_env *env); | |
| 374 | + int (*filter)(struct kset *kset, struct kobject *kobj); | |
| 375 | + const char *(*name)(struct kset *kset, struct kobject *kobj); | |
| 376 | + int (*uevent)(struct kset *kset, struct kobject *kobj, | |
| 377 | + struct kobj_uevent_env *env); | |
| 378 | 378 | }; |
| 379 | 379 | |
| 380 | 380 | |
| @@ -408,8 +408,8 @@ Kobject removal · 27 unmodified lines | ||
| 408 | 408 | After a kobject has been registered with the kobject core successfully, it |
| 409 | 409 | must be cleaned up when the code is finished with it. To do that, call |
| 410 | 410 | kobject_put(). By doing this, the kobject core will automatically clean up |
| 411 | −all of the memory allocated by this kobject. If a KOBJ_ADD uevent has been | |
| 412 | −sent for the object, a corresponding KOBJ_REMOVE uevent will be sent, and | |
| 411 | +all of the memory allocated by this kobject. If a ``KOBJ_ADD`` uevent has been | |
| 412 | +sent for the object, a corresponding ``KOBJ_REMOVE`` uevent will be sent, and | |
| 413 | 413 | any other sysfs housekeeping will be handled for the caller properly. |
| 414 | 414 | |
| 415 | 415 | If you need to do a two-stage delete of the kobject (say you are not |
| @@ -430,5 +430,5 @@ Example code to copy from · 14 unmodified lines | ||
| 430 | 430 | ========================= |
| 431 | 431 | |
| 432 | 432 | For a more complete example of using ksets and kobjects properly, see the |
| 433 | −example programs samples/kobject/{kobject-example.c,kset-example.c}, | |
| 434 | −which will be built as loadable modules if you select CONFIG_SAMPLE_KOBJECT. | |
| 433 | +example programs ``samples/kobject/{kobject-example.c,kset-example.c}``, | |
| 434 | +which will be built as loadable modules if you select ``CONFIG_SAMPLE_KOBJECT``. | |
| @@ -73,6 +73,9 @@ File Mapping and Page Cache · 72 unmodified lines | ||
| 73 | 73 | .. kernel-doc:: mm/truncate.c |
| 74 | 74 | :export: |
| 75 | 75 | |
| 76 | +.. kernel-doc:: include/linux/pagemap.h | |
| 77 | + :internal: | |
| 78 | + | |
| 76 | 79 | Memory pools |
| 77 | 80 | ============ |
| 78 | 81 | |
| @@ -52,8 +52,22 @@ Which flags are set by each wrapper · 51 unmodified lines | ||
| 52 | 52 | |
| 53 | 53 | For these pin_user_pages*() functions, FOLL_PIN is OR'd in with whatever gup |
| 54 | 54 | flags the caller provides. The caller is required to pass in a non-null struct |
| 55 | −pages* array, and the function then pin pages by incrementing each by a special | |
| 56 | −value. For now, that value is +1, just like get_user_pages*().:: | |
| 55 | +pages* array, and the function then pins pages by incrementing each by a special | |
| 56 | +value: GUP_PIN_COUNTING_BIAS. | |
| 57 | + | |
| 58 | +For huge pages (and in fact, any compound page of more than 2 pages), the | |
| 59 | +GUP_PIN_COUNTING_BIAS scheme is not used. Instead, an exact form of pin counting | |
| 60 | +is achieved, by using the 3rd struct page in the compound page. A new struct | |
| 61 | +page field, hpage_pinned_refcount, has been added in order to support this. | |
| 62 | + | |
| 63 | +This approach for compound pages avoids the counting upper limit problems that | |
| 64 | +are discussed below. Those limitations would have been aggravated severely by | |
| 65 | +huge pages, because each tail page adds a refcount to the head page. And in | |
| 66 | +fact, testing revealed that, without a separate hpage_pinned_refcount field, | |
| 67 | +page overflows were seen in some huge page stress tests. | |
| 68 | + | |
| 69 | +This also means that huge pages and compound pages (of order > 1) do not suffer | |
| 70 | +from the false positives problem that is mentioned below.:: | |
| 57 | 71 | |
| 58 | 72 | Function |
| 59 | 73 | -------- |
| @@ -99,27 +113,6 @@ pages: · 39 unmodified lines | ||
| 99 | 113 | This also leads to limitations: there are only 31-10==21 bits available for a |
| 100 | 114 | counter that increments 10 bits at a time. |
| 101 | 115 | |
| 102 | −TODO: for 1GB and larger huge pages, this is cutting it close. That's because | |
| 103 | −when pin_user_pages() follows such pages, it increments the head page by "1" | |
| 104 | −(where "1" used to mean "+1" for get_user_pages(), but now means "+1024" for | |
| 105 | −pin_user_pages()) for each tail page. So if you have a 1GB huge page: | |
| 106 | − | |
| 107 | −* There are 256K (18 bits) worth of 4 KB tail pages. | |
| 108 | −* There are 21 bits available to count up via GUP_PIN_COUNTING_BIAS (that is, | |
| 109 | − 10 bits at a time) | |
| 110 | −* There are 21 - 18 == 3 bits available to count. Except that there aren't, | |
| 111 | − because you need to allow for a few normal get_page() calls on the head page, | |
| 112 | − as well. Fortunately, the approach of using addition, rather than "hard" | |
| 113 | − bitfields, within page->_refcount, allows for sharing these bits gracefully. | |
| 114 | − But we're still looking at about 8 references. | |
| 115 | − | |
| 116 | −This, however, is a missing feature more than anything else, because it's easily | |
| 117 | −solved by addressing an obvious inefficiency in the original get_user_pages() | |
| 118 | −approach of retrieving pages: stop treating all the pages as if they were | |
| 119 | −PAGE_SIZE. Retrieve huge pages as huge pages. The callers need to be aware of | |
| 120 | −this, so some work is required. Once that's in place, this limitation mostly | |
| 121 | −disappears from view, because there will be ample refcounting range available. | |
| 122 | − | |
| 123 | 116 | * Callers must specifically request "dma-pinned tracking of pages". In other |
| 124 | 117 | words, just calling get_user_pages() will not suffice; a new set of functions, |
| 125 | 118 | pin_user_page() and related, must be used. |
| @@ -173,8 +166,8 @@ CASE 4: Pinning for struct page manipulation only · 47 unmodified lines | ||
| 173 | 166 | ------------------------------------------------- |
| 174 | 167 | Here, normal GUP calls are sufficient, so neither flag needs to be set. |
| 175 | 168 | |
| 176 | −page_dma_pinned(): the whole point of pinning | |
| 177 | −============================================= | |
| 169 | +page_maybe_dma_pinned(): the whole point of pinning | |
| 170 | +=================================================== | |
| 178 | 171 | |
| 179 | 172 | The whole point of marking pages as "DMA-pinned" or "gup-pinned" is to be able |
| 180 | 173 | to query, "is this page DMA-pinned?" That allows code such as page_mkclean() |
| @@ -186,7 +179,7 @@ and debates (see the References at the end of this document). It's a TODO item · 5 unmodified lines | ||
| 186 | 179 | here: fill in the details once that's worked out. Meanwhile, it's safe to say |
| 187 | 180 | that having this available: :: |
| 188 | 181 | |
| 189 | − static inline bool page_dma_pinned(struct page *page) | |
| 182 | + static inline bool page_maybe_dma_pinned(struct page *page) | |
| 190 | 183 | |
| 191 | 184 | ...is a prerequisite to solving the long-running gup+DMA problem. |
| 192 | 185 | |
| @@ -215,12 +208,42 @@ has the following new calls to exercise the new pin*() wrapper functions: · 22 unmodified lines | ||
| 215 | 208 | You can monitor how many total dma-pinned pages have been acquired and released |
| 216 | 209 | since the system was booted, via two new /proc/vmstat entries: :: |
| 217 | 210 | |
| 218 | − /proc/vmstat/nr_foll_pin_requested | |
| 219 | − /proc/vmstat/nr_foll_pin_requested | |
| 211 | + /proc/vmstat/nr_foll_pin_acquired | |
| 212 | + /proc/vmstat/nr_foll_pin_released | |
| 213 | + | |
| 214 | +Under normal conditions, these two values will be equal unless there are any | |
| 215 | +long-term [R]DMA pins in place, or during pin/unpin transitions. | |
| 216 | + | |
| 217 | +* nr_foll_pin_acquired: This is the number of logical pins that have been | |
| 218 | + acquired since the system was powered on. For huge pages, the head page is | |
| 219 | + pinned once for each page (head page and each tail page) within the huge page. | |
| 220 | + This follows the same sort of behavior that get_user_pages() uses for huge | |
| 221 | + pages: the head page is refcounted once for each tail or head page in the huge | |
| 222 | + page, when get_user_pages() is applied to a huge page. | |
| 223 | + | |
| 224 | +* nr_foll_pin_released: The number of logical pins that have been released since | |
| 225 | + the system was powered on. Note that pages are released (unpinned) on a | |
| 226 | + PAGE_SIZE granularity, even if the original pin was applied to a huge page. | |
| 227 | + Becaused of the pin count behavior described above in "nr_foll_pin_acquired", | |
| 228 | + the accounting balances out, so that after doing this:: | |
| 229 | + | |
| 230 | + pin_user_pages(huge_page); | |
| 231 | + for (each page in huge_page) | |
| 232 | + unpin_user_page(page); | |
| 233 | + | |
| 234 | +...the following is expected:: | |
| 235 | + | |
| 236 | + nr_foll_pin_released == nr_foll_pin_acquired | |
| 237 | + | |
| 238 | +(...unless it was already out of balance due to a long-term RDMA pin being in | |
| 239 | +place.) | |
| 240 | + | |
| 241 | +Other diagnostics | |
| 242 | +================= | |
| 220 | 243 | |
| 221 | −Those are both going to show zero, unless CONFIG_DEBUG_VM is set. This is | |
| 222 | −because there is a noticeable performance drop in unpin_user_page(), when they | |
| 223 | −are activated. | |
| 244 | +dump_page() has been enhanced slightly, to handle these new counting fields, and | |
| 245 | +to better report on compound pages in general. Specifically, for compound pages | |
| 246 | +with order > 1, the exact (hpage_pinned_refcount) pincount is reported. | |
| 224 | 247 | |
| 225 | 248 | References |
| 226 | 249 | ========== |
| @@ -228,5 +251,6 @@ References · 1 unmodified line | ||
| 228 | 251 | * `Some slow progress on get_user_pages() (Apr 2, 2019) <https://lwn.net/Articles/784574/>`_ |
| 229 | 252 | * `DMA and get_user_pages() (LPC: Dec 12, 2018) <https://lwn.net/Articles/774411/>`_ |
| 230 | 253 | * `The trouble with get_user_pages() (Apr 30, 2018) <https://lwn.net/Articles/753027/>`_ |
| 254 | +* `LWN kernel index: get_user_pages() <https://lwn.net/Kernel/Index/#Memory_management-get_user_pages>`_ | |
| 231 | 255 | |
| 232 | 256 | John Hubbard, October, 2019 |
| @@ -1,38 +0,0 @@ | ||
| 1 | − | |
| 2 | −PowerNow! and Cool'n'Quiet are AMD names for frequency | |
| 3 | −management capabilities in AMD processors. As the hardware | |
| 4 | −implementation changes in new generations of the processors, | |
| 5 | −there is a different cpu-freq driver for each generation. | |
| 6 | − | |
| 7 | −Note that the driver's will not load on the "wrong" hardware, | |
| 8 | −so it is safe to try each driver in turn when in doubt as to | |
| 9 | −which is the correct driver. | |
| 10 | − | |
| 11 | −Note that the functionality to change frequency (and voltage) | |
| 12 | −is not available in all processors. The drivers will refuse | |
| 13 | −to load on processors without this capability. The capability | |
| 14 | −is detected with the cpuid instruction. | |
| 15 | − | |
| 16 | −The drivers use BIOS supplied tables to obtain frequency and | |
| 17 | −voltage information appropriate for a particular platform. | |
| 18 | −Frequency transitions will be unavailable if the BIOS does | |
| 19 | −not supply these tables. | |
| 20 | − | |
| 21 | −6th Generation: powernow-k6 | |
| 22 | − | |
| 23 | −7th Generation: powernow-k7: Athlon, Duron, Geode. | |
| 24 | − | |
| 25 | −8th Generation: powernow-k8: Athlon, Athlon 64, Opteron, Sempron. | |
| 26 | −Documentation on this functionality in 8th generation processors | |
| 27 | −is available in the "BIOS and Kernel Developer's Guide", publication | |
| 28 | −26094, in chapter 9, available for download from www.amd.com. | |
| 29 | − | |
| 30 | −BIOS supplied data, for powernow-k7 and for powernow-k8, may be | |
| 31 | −from either the PSB table or from ACPI objects. The ACPI support | |
| 32 | −is only available if the kernel config sets CONFIG_ACPI_PROCESSOR. | |
| 33 | −The powernow-k8 driver will attempt to use ACPI if so configured, | |
| 34 | −and fall back to PST if that fails. | |
| 35 | −The powernow-k7 driver will try to use the PSB support first, and | |
| 36 | −fall back to ACPI if the PSB support fails. A module parameter, | |
| 37 | −acpi_force, is provided to force ACPI support to be used instead | |
| 38 | −of PSB support. | |
| @@ -1,31 +1,23 @@ | ||
| 1 | − CPU frequency and voltage scaling code in the Linux(TM) kernel | |
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | 2 | |
| 3 | +============================================================= | |
| 4 | +General description of the CPUFreq core and CPUFreq notifiers | |
| 5 | +============================================================= | |
| 3 | 6 | |
| 4 | − L i n u x C P U F r e q | |
| 7 | +Authors: | |
| 8 | + - Dominik Brodowski <linux@brodo.de> | |
| 9 | + - David Kimdon <dwhedon@debian.org> | |
| 10 | + - Rafael J. Wysocki <rafael.j.wysocki@intel.com> | |
| 11 | + - Viresh Kumar <viresh.kumar@linaro.org> | |
| 5 | 12 | |
| 6 | − C P U F r e q C o r e | |
| 13 | +.. Contents: | |
| 7 | 14 | |
| 8 | − | |
| 9 | − Dominik Brodowski <linux@brodo.de> | |
| 10 | − David Kimdon <dwhedon@debian.org> | |
| 11 | − Rafael J. Wysocki <rafael.j.wysocki@intel.com> | |
| 12 | − Viresh Kumar <viresh.kumar@linaro.org> | |
| 13 | − | |
| 14 | − | |
| 15 | − | |
| 16 | − Clock scaling allows you to change the clock speed of the CPUs on the | |
| 17 | − fly. This is a nice method to save battery power, because the lower | |
| 18 | − the clock speed, the less power the CPU consumes. | |
| 19 | − | |
| 20 | − | |
| 21 | −Contents: | |
| 22 | −--------- | |
| 23 | −1. CPUFreq core and interfaces | |
| 24 | −2. CPUFreq notifiers | |
| 25 | −3. CPUFreq Table Generation with Operating Performance Point (OPP) | |
| 15 | + 1. CPUFreq core and interfaces | |
| 16 | + 2. CPUFreq notifiers | |
| 17 | + 3. CPUFreq Table Generation with Operating Performance Point (OPP) | |
| 26 | 18 | |
| 27 | 19 | 1. General Information |
| 28 | −======================= | |
| 20 | +====================== | |
| 29 | 21 | |
| 30 | 22 | The CPUFreq core code is located in drivers/cpufreq/cpufreq.c. This |
| 31 | 23 | cpufreq code offers a standardized interface for the CPUFreq |
| @@ -63,7 +55,7 @@ The phase is specified in the second argument to the notifier. The phase is · 31 unmodified lines | ||
| 63 | 55 | CPUFREQ_CREATE_POLICY when the policy is first created and it is |
| 64 | 56 | CPUFREQ_REMOVE_POLICY when the policy is removed. |
| 65 | 57 | |
| 66 | −The third argument, a void *pointer, points to a struct cpufreq_policy | |
| 58 | +The third argument, a ``void *pointer``, points to a struct cpufreq_policy | |
| 67 | 59 | consisting of several values, including min, max (the lower and upper |
| 68 | 60 | frequencies (in kHz) of the new policy). |
| 69 | 61 | |
| @@ -80,10 +72,13 @@ CPUFREQ_POSTCHANGE. · 10 unmodified lines | ||
| 80 | 72 | |
| 81 | 73 | The third argument is a struct cpufreq_freqs with the following |
| 82 | 74 | values: |
| 83 | −cpu - number of the affected CPU | |
| 84 | −old - old frequency | |
| 85 | −new - new frequency | |
| 86 | −flags - flags of the cpufreq driver | |
| 75 | + | |
| 76 | +===== =========================== | |
| 77 | +cpu number of the affected CPU | |
| 78 | +old old frequency | |
| 79 | +new new frequency | |
| 80 | +flags flags of the cpufreq driver | |
| 81 | +===== =========================== | |
| 87 | 82 | |
| 88 | 83 | 3. CPUFreq Table Generation with Operating Performance Point (OPP) |
| 89 | 84 | ================================================================== |
| @@ -94,9 +89,12 @@ dev_pm_opp_init_cpufreq_table - · 4 unmodified lines | ||
| 94 | 89 | the OPP layer's internal information about the available frequencies |
| 95 | 90 | into a format readily providable to cpufreq. |
| 96 | 91 | |
| 97 | − WARNING: Do not use this function in interrupt context. | |
| 92 | + .. Warning:: | |
| 93 | + | |
| 94 | + Do not use this function in interrupt context. | |
| 95 | + | |
| 96 | + Example:: | |
| 98 | 97 | |
| 99 | − Example: | |
| 100 | 98 | soc_pm_init() |
| 101 | 99 | { |
| 102 | 100 | /* Do things */ |
| @@ -106,7 +104,10 @@ dev_pm_opp_init_cpufreq_table - · 3 unmodified lines | ||
| 106 | 104 | /* Do other things */ |
| 107 | 105 | } |
| 108 | 106 | |
| 109 | − NOTE: This function is available only if CONFIG_CPU_FREQ is enabled in | |
| 110 | − addition to CONFIG_PM_OPP. | |
| 107 | + .. note:: | |
| 108 | + | |
| 109 | + This function is available only if CONFIG_CPU_FREQ is enabled in | |
| 110 | + addition to CONFIG_PM_OPP. | |
| 111 | 111 | |
| 112 | −dev_pm_opp_free_cpufreq_table - Free up the table allocated by dev_pm_opp_init_cpufreq_table | |
| 112 | +dev_pm_opp_free_cpufreq_table | |
| 113 | + Free up the table allocated by dev_pm_opp_init_cpufreq_table | |
| @@ -1,35 +1,27 @@ | ||
| 1 | − CPU frequency and voltage scaling code in the Linux(TM) kernel | |
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | 2 | |
| 3 | +=============================================== | |
| 4 | +How to Implement a new CPUFreq Processor Driver | |
| 5 | +=============================================== | |
| 3 | 6 | |
| 4 | − L i n u x C P U F r e q | |
| 7 | +Authors: | |
| 5 | 8 | |
| 6 | − C P U D r i v e r s | |
| 7 | 9 | |
| 8 | − - information for developers - | |
| 10 | + - Dominik Brodowski <linux@brodo.de> | |
| 11 | + - Rafael J. Wysocki <rafael.j.wysocki@intel.com> | |
| 12 | + - Viresh Kumar <viresh.kumar@linaro.org> | |
| 9 | 13 | |
| 14 | +.. Contents | |
| 10 | 15 | |
| 11 | − Dominik Brodowski <linux@brodo.de> | |
| 12 | − Rafael J. Wysocki <rafael.j.wysocki@intel.com> | |
| 13 | − Viresh Kumar <viresh.kumar@linaro.org> | |
| 14 | − | |
| 15 | − | |
| 16 | − | |
| 17 | − Clock scaling allows you to change the clock speed of the CPUs on the | |
| 18 | − fly. This is a nice method to save battery power, because the lower | |
| 19 | − the clock speed, the less power the CPU consumes. | |
| 20 | − | |
| 21 | − | |
| 22 | −Contents: | |
| 23 | −--------- | |
| 24 | −1. What To Do? | |
| 25 | −1.1 Initialization | |
| 26 | −1.2 Per-CPU Initialization | |
| 27 | −1.3 verify | |
| 28 | −1.4 target/target_index or setpolicy? | |
| 29 | −1.5 target/target_index | |
| 30 | −1.6 setpolicy | |
| 31 | −1.7 get_intermediate and target_intermediate | |
| 32 | −2. Frequency Table Helpers | |
| 16 | + 1. What To Do? | |
| 17 | + 1.1 Initialization | |
| 18 | + 1.2 Per-CPU Initialization | |
| 19 | + 1.3 verify | |
| 20 | + 1.4 target/target_index or setpolicy? | |
| 21 | + 1.5 target/target_index | |
| 22 | + 1.6 setpolicy | |
| 23 | + 1.7 get_intermediate and target_intermediate | |
| 24 | + 2. Frequency Table Helpers | |
| 33 | 25 | |
| 34 | 26 | |
| 35 | 27 | |
| @@ -49,7 +41,7 @@ function check whether this kernel runs on the right CPU and the right · 13 unmodified lines | ||
| 49 | 41 | chipset. If so, register a struct cpufreq_driver with the CPUfreq core |
| 50 | 42 | using cpufreq_register_driver() |
| 51 | 43 | |
| 52 | −What shall this struct cpufreq_driver contain? | |
| 44 | +What shall this struct cpufreq_driver contain? | |
| 53 | 45 | |
| 54 | 46 | .name - The name of this driver. |
| 55 | 47 | |
| @@ -108,37 +100,42 @@ Whenever a new CPU is registered with the device model, or after the · 52 unmodified lines | ||
| 108 | 100 | cpufreq driver registers itself, the per-policy initialization function |
| 109 | 101 | cpufreq_driver.init is called if no cpufreq policy existed for the CPU. |
| 110 | 102 | Note that the .init() and .exit() routines are called only once for the |
| 111 | −policy and not for each CPU managed by the policy. It takes a struct | |
| 112 | −cpufreq_policy *policy as argument. What to do now? | |
| 103 | +policy and not for each CPU managed by the policy. It takes a ``struct | |
| 104 | +cpufreq_policy *policy`` as argument. What to do now? | |
| 113 | 105 | |
| 114 | 106 | If necessary, activate the CPUfreq support on your CPU. |
| 115 | 107 | |
| 116 | 108 | Then, the driver must fill in the following values: |
| 117 | 109 | |
| 118 | −policy->cpuinfo.min_freq _and_ | |
| 119 | −policy->cpuinfo.max_freq - the minimum and maximum frequency | |
| 120 | − (in kHz) which is supported by | |
| 121 | − this CPU | |
| 122 | −policy->cpuinfo.transition_latency the time it takes on this CPU to | |
| 123 | − switch between two frequencies in | |
| 124 | − nanoseconds (if appropriate, else | |
| 125 | − specify CPUFREQ_ETERNAL) | |
| 126 | − | |
| 127 | −policy->cur The current operating frequency of | |
| 128 | − this CPU (if appropriate) | |
| 129 | −policy->min, | |
| 130 | −policy->max, | |
| 131 | −policy->policy and, if necessary, | |
| 132 | −policy->governor must contain the "default policy" for | |
| 133 | − this CPU. A few moments later, | |
| 134 | − cpufreq_driver.verify and either | |
| 135 | − cpufreq_driver.setpolicy or | |
| 136 | − cpufreq_driver.target/target_index is called | |
| 137 | − with these values. | |
| 138 | −policy->cpus Update this with the masks of the | |
| 139 | − (online + offline) CPUs that do DVFS | |
| 140 | − along with this CPU (i.e. that share | |
| 141 | − clock/voltage rails with it). | |
| 110 | ++-----------------------------------+--------------------------------------+ | |
| 111 | +|policy->cpuinfo.min_freq _and_ | | | |
| 112 | +|policy->cpuinfo.max_freq | the minimum and maximum frequency | | |
| 113 | +| | (in kHz) which is supported by | | |
| 114 | +| | this CPU | | |
| 115 | ++-----------------------------------+--------------------------------------+ | |
| 116 | +|policy->cpuinfo.transition_latency | the time it takes on this CPU to | | |
| 117 | +| | switch between two frequencies in | | |
| 118 | +| | nanoseconds (if appropriate, else | | |
| 119 | +| | specify CPUFREQ_ETERNAL) | | |
| 120 | ++-----------------------------------+--------------------------------------+ | |
| 121 | +|policy->cur | The current operating frequency of | | |
| 122 | +| | this CPU (if appropriate) | | |
| 123 | ++-----------------------------------+--------------------------------------+ | |
| 124 | +|policy->min, | | | |
| 125 | +|policy->max, | | | |
| 126 | +|policy->policy and, if necessary, | | | |
| 127 | +|policy->governor | must contain the "default policy" for| | |
| 128 | +| | this CPU. A few moments later, | | |
| 129 | +| | cpufreq_driver.verify and either | | |
| 130 | +| | cpufreq_driver.setpolicy or | | |
| 131 | +| | cpufreq_driver.target/target_index is| | |
| 132 | +| | called with these values. | | |
| 133 | ++-----------------------------------+--------------------------------------+ | |
| 134 | +|policy->cpus | Update this with the masks of the | | |
| 135 | +| | (online + offline) CPUs that do DVFS | | |
| 136 | +| | along with this CPU (i.e. that share| | |
| 137 | +| | clock/voltage rails with it). | | |
| 138 | ++-----------------------------------+--------------------------------------+ | |
| 142 | 139 | |
| 143 | 140 | For setting some of these values (cpuinfo.min[max]_freq, policy->min[max]), the |
| 144 | 141 | frequency table helpers might be helpful. See the section 2 for more information |
| @@ -151,8 +148,8 @@ on them. · 6 unmodified lines | ||
| 151 | 148 | When the user decides a new policy (consisting of |
| 152 | 149 | "policy,governor,min,max") shall be set, this policy must be validated |
| 153 | 150 | so that incompatible values can be corrected. For verifying these |
| 154 | −values cpufreq_verify_within_limits(struct cpufreq_policy *policy, | |
| 155 | −unsigned int min_freq, unsigned int max_freq) function might be helpful. | |
| 151 | +values cpufreq_verify_within_limits(``struct cpufreq_policy *policy``, | |
| 152 | +``unsigned int min_freq``, ``unsigned int max_freq``) function might be helpful. | |
| 156 | 153 | See section 2 for details on frequency table helpers. |
| 157 | 154 | |
| 158 | 155 | You need to make sure that at least one valid frequency (or operating |
| @@ -163,7 +160,7 @@ policy->max first, and only if this is no solution, decrease policy->min. · 4 unmodified lines | ||
| 163 | 160 | 1.4 target or target_index or setpolicy or fast_switch? |
| 164 | 161 | ------------------------------------------------------- |
| 165 | 162 | |
| 166 | −Most cpufreq drivers or even most cpu frequency scaling algorithms | |
| 163 | +Most cpufreq drivers or even most cpu frequency scaling algorithms | |
| 167 | 164 | only allow the CPU frequency to be set to predefined fixed values. For |
| 168 | 165 | these, you use the ->target(), ->target_index() or ->fast_switch() |
| 169 | 166 | callbacks. |
| @@ -175,8 +172,8 @@ limits on their own. These shall use the ->setpolicy() callback. · 5 unmodified lines | ||
| 175 | 172 | 1.5. target/target_index |
| 176 | 173 | ------------------------ |
| 177 | 174 | |
| 178 | −The target_index call has two arguments: struct cpufreq_policy *policy, | |
| 179 | −and unsigned int index (into the exposed frequency table). | |
| 175 | +The target_index call has two arguments: ``struct cpufreq_policy *policy``, | |
| 176 | +and ``unsigned int`` index (into the exposed frequency table). | |
| 180 | 177 | |
| 181 | 178 | The CPUfreq driver must set the new frequency when called here. The |
| 182 | 179 | actual frequency must be determined by freq_table[index].frequency. |
| @@ -184,9 +181,9 @@ actual frequency must be determined by freq_table[index].frequency. · 1 unmodified line | ||
| 184 | 181 | It should always restore to earlier frequency (i.e. policy->restore_freq) in |
| 185 | 182 | case of errors, even if we switched to intermediate frequency earlier. |
| 186 | 183 | |
| 187 | −Deprecated: | |
| 184 | +Deprecated | |
| 188 | 185 | ---------- |
| 189 | −The target call has three arguments: struct cpufreq_policy *policy, | |
| 186 | +The target call has three arguments: ``struct cpufreq_policy *policy``, | |
| 190 | 187 | unsigned int target_frequency, unsigned int relation. |
| 191 | 188 | |
| 192 | 189 | The CPUfreq driver must set the new frequency when called here. The |
| @@ -210,14 +207,14 @@ Not all drivers are expected to implement it, as sleeping from within · 17 unmodified lines | ||
| 210 | 207 | this callback isn't allowed. This callback must be highly optimized to |
| 211 | 208 | do switching as fast as possible. |
| 212 | 209 | |
| 213 | −This function has two arguments: struct cpufreq_policy *policy and | |
| 214 | −unsigned int target_frequency. | |
| 210 | +This function has two arguments: ``struct cpufreq_policy *policy`` and | |
| 211 | +``unsigned int target_frequency``. | |
| 215 | 212 | |
| 216 | 213 | |
| 217 | 214 | 1.7 setpolicy |
| 218 | 215 | ------------- |
| 219 | 216 | |
| 220 | −The setpolicy call only takes a struct cpufreq_policy *policy as | |
| 217 | +The setpolicy call only takes a ``struct cpufreq_policy *policy`` as | |
| 221 | 218 | argument. You need to set the lower limit of the in-processor or |
| 222 | 219 | in-chipset dynamic frequency switching to policy->min, the upper limit |
| 223 | 220 | to policy->max, and -if supported- select a performance-oriented |
| @@ -278,10 +275,10 @@ table. · 54 unmodified lines | ||
| 278 | 275 | |
| 279 | 276 | cpufreq_for_each_valid_entry(pos, table) - iterates over all entries, |
| 280 | 277 | excluding CPUFREQ_ENTRY_INVALID frequencies. |
| 281 | −Use arguments "pos" - a cpufreq_frequency_table * as a loop cursor and | |
| 282 | −"table" - the cpufreq_frequency_table * you want to iterate over. | |
| 278 | +Use arguments "pos" - a ``cpufreq_frequency_table *`` as a loop cursor and | |
| 279 | +"table" - the ``cpufreq_frequency_table *`` you want to iterate over. | |
| 283 | 280 | |
| 284 | −For example: | |
| 281 | +For example:: | |
| 285 | 282 | |
| 286 | 283 | struct cpufreq_frequency_table *pos, *driver_freq_table; |
| 287 | 284 | |
| @@ -1,19 +0,0 @@ | ||
| 1 | − | |
| 2 | −The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 platforms. | |
| 3 | − | |
| 4 | −This works better than on other platforms, because the FSB of the CPU | |
| 5 | −can be controlled independently from the PCI/AGP clock. | |
| 6 | − | |
| 7 | −The module has two options: | |
| 8 | − | |
| 9 | − fid: multiplier * 10 (for example 8.5 = 85) | |
| 10 | − min_fsb: minimum FSB | |
| 11 | − | |
| 12 | −If not set, fid is calculated from the current CPU speed and the FSB. | |
| 13 | −min_fsb defaults to FSB at boot time - 50 MHz. | |
| 14 | − | |
| 15 | −IMPORTANT: The available range is limited downwards! | |
| 16 | − Also the minimum available FSB can differ, for systems | |
| 17 | − booting with 200 MHz, 150 should always work. | |
| 18 | − | |
| 19 | − | |
| @@ -1,21 +1,23 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 1 | 2 | |
| 2 | − CPU frequency and voltage scaling statistics in the Linux(TM) kernel | |
| 3 | +========================================== | |
| 4 | +General Description of sysfs CPUFreq Stats | |
| 5 | +========================================== | |
| 3 | 6 | |
| 7 | +information for users | |
| 4 | 8 | |
| 5 | − L i n u x c p u f r e q - s t a t s d r i v e r | |
| 6 | 9 | |
| 7 | − - information for users - | |
| 10 | +Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> | |
| 8 | 11 | |
| 12 | +.. Contents | |
| 9 | 13 | |
| 10 | − Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> | |
| 11 | − | |
| 12 | −Contents | |
| 13 | −1. Introduction | |
| 14 | −2. Statistics Provided (with example) | |
| 15 | −3. Configuring cpufreq-stats | |
| 14 | + 1. Introduction | |
| 15 | + 2. Statistics Provided (with example) | |
| 16 | + 3. Configuring cpufreq-stats | |
| 16 | 17 | |
| 17 | 18 | |
| 18 | 19 | 1. Introduction |
| 20 | +=============== | |
| 19 | 21 | |
| 20 | 22 | cpufreq-stats is a driver that provides CPU frequency statistics for each CPU. |
| 21 | 23 | These statistics are provided in /sysfs as a bunch of read_only interfaces. This |
| @@ -28,8 +30,10 @@ that may be running on your CPU. So, it will work with any cpufreq_driver. · 6 unmodified lines | ||
| 28 | 30 | |
| 29 | 31 | |
| 30 | 32 | 2. Statistics Provided (with example) |
| 33 | +===================================== | |
| 31 | 34 | |
| 32 | 35 | cpufreq stats provides following statistics (explained in detail below). |
| 36 | + | |
| 33 | 37 | - time_in_state |
| 34 | 38 | - total_trans |
| 35 | 39 | - trans_table |
| @@ -39,53 +43,57 @@ All the statistics will be from the time the stats driver has been inserted · 3 unmodified lines | ||
| 39 | 43 | statistic is done. Obviously, stats driver will not have any information |
| 40 | 44 | about the frequency transitions before the stats driver insertion. |
| 41 | 45 | |
| 42 | −-------------------------------------------------------------------------------- | |
| 43 | −<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # ls -l | |
| 44 | −total 0 | |
| 45 | −drwxr-xr-x 2 root root 0 May 14 16:06 . | |
| 46 | −drwxr-xr-x 3 root root 0 May 14 15:58 .. | |
| 47 | −--w------- 1 root root 4096 May 14 16:06 reset | |
| 48 | −-r--r--r-- 1 root root 4096 May 14 16:06 time_in_state | |
| 49 | −-r--r--r-- 1 root root 4096 May 14 16:06 total_trans | |
| 50 | −-r--r--r-- 1 root root 4096 May 14 16:06 trans_table | |
| 51 | −-------------------------------------------------------------------------------- | |
| 52 | − | |
| 53 | −- reset | |
| 46 | +:: | |
| 47 | + | |
| 48 | + <mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # ls -l | |
| 49 | + total 0 | |
| 50 | + drwxr-xr-x 2 root root 0 May 14 16:06 . | |
| 51 | + drwxr-xr-x 3 root root 0 May 14 15:58 .. | |
| 52 | + --w------- 1 root root 4096 May 14 16:06 reset | |
| 53 | + -r--r--r-- 1 root root 4096 May 14 16:06 time_in_state | |
| 54 | + -r--r--r-- 1 root root 4096 May 14 16:06 total_trans | |
| 55 | + -r--r--r-- 1 root root 4096 May 14 16:06 trans_table | |
| 56 | + | |
| 57 | +- **reset** | |
| 58 | + | |
| 54 | 59 | Write-only attribute that can be used to reset the stat counters. This can be |
| 55 | 60 | useful for evaluating system behaviour under different governors without the |
| 56 | 61 | need for a reboot. |
| 57 | 62 | |
| 58 | −- time_in_state | |
| 63 | +- **time_in_state** | |
| 64 | + | |
| 59 | 65 | This gives the amount of time spent in each of the frequencies supported by |
| 60 | 66 | this CPU. The cat output will have "<frequency> <time>" pair in each line, which |
| 61 | 67 | will mean this CPU spent <time> usertime units of time at <frequency>. Output |
| 62 | −will have one line for each of the supported frequencies. usertime units here | |
| 68 | +will have one line for each of the supported frequencies. usertime units here | |
| 63 | 69 | is 10mS (similar to other time exported in /proc). |
| 64 | 70 | |
| 65 | −-------------------------------------------------------------------------------- | |
| 66 | −<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat time_in_state | |
| 67 | −3600000 2089 | |
| 68 | −3400000 136 | |
| 69 | −3200000 34 | |
| 70 | −3000000 67 | |
| 71 | −2800000 172488 | |
| 72 | −-------------------------------------------------------------------------------- | |
| 71 | +:: | |
| 73 | 72 | |
| 73 | + <mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat time_in_state | |
| 74 | + 3600000 2089 | |
| 75 | + 3400000 136 | |
| 76 | + 3200000 34 | |
| 77 | + 3000000 67 | |
| 78 | + 2800000 172488 | |
| 74 | 79 | |
| 75 | −- total_trans | |
| 76 | −This gives the total number of frequency transitions on this CPU. The cat | |
| 80 | + | |
| 81 | +- **total_trans** | |
| 82 | + | |
| 83 | +This gives the total number of frequency transitions on this CPU. The cat | |
| 77 | 84 | output will have a single count which is the total number of frequency |
| 78 | 85 | transitions. |
| 79 | 86 | |
| 80 | −-------------------------------------------------------------------------------- | |
| 81 | −<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat total_trans | |
| 82 | −20 | |
| 83 | −-------------------------------------------------------------------------------- | |
| 87 | +:: | |
| 88 | + | |
| 89 | + <mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat total_trans | |
| 90 | + 20 | |
| 91 | + | |
| 92 | +- **trans_table** | |
| 84 | 93 | |
| 85 | −- trans_table | |
| 86 | 94 | This will give a fine grained information about all the CPU frequency |
| 87 | 95 | transitions. The cat output here is a two dimensional matrix, where an entry |
| 88 | −<i,j> (row i, column j) represents the count of number of transitions from | |
| 96 | +<i,j> (row i, column j) represents the count of number of transitions from | |
| 89 | 97 | Freq_i to Freq_j. Freq_i rows and Freq_j columns follow the sorting order in |
| 90 | 98 | which the driver has provided the frequency table initially to the cpufreq core |
| 91 | 99 | and so can be sorted (ascending or descending) or unsorted. The output here |
| @@ -95,26 +103,27 @@ readability. · 3 unmodified lines | ||
| 95 | 103 | If the transition table is bigger than PAGE_SIZE, reading this will |
| 96 | 104 | return an -EFBIG error. |
| 97 | 105 | |
| 98 | −-------------------------------------------------------------------------------- | |
| 99 | −<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat trans_table | |
| 100 | − From : To | |
| 101 | − : 3600000 3400000 3200000 3000000 2800000 | |
| 102 | − 3600000: 0 5 0 0 0 | |
| 103 | − 3400000: 4 0 2 0 0 | |
| 104 | − 3200000: 0 1 0 2 0 | |
| 105 | − 3000000: 0 0 1 0 3 | |
| 106 | − 2800000: 0 0 0 2 0 | |
| 107 | −-------------------------------------------------------------------------------- | |
| 106 | +:: | |
| 108 | 107 | |
| 108 | + <mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat trans_table | |
| 109 | + From : To | |
| 110 | + : 3600000 3400000 3200000 3000000 2800000 | |
| 111 | + 3600000: 0 5 0 0 0 | |
| 112 | + 3400000: 4 0 2 0 0 | |
| 113 | + 3200000: 0 1 0 2 0 | |
| 114 | + 3000000: 0 0 1 0 3 | |
| 115 | + 2800000: 0 0 0 2 0 | |
| 109 | 116 | |
| 110 | 117 | 3. Configuring cpufreq-stats |
| 118 | +============================ | |
| 119 | + | |
| 120 | +To configure cpufreq-stats in your kernel:: | |
| 111 | 121 | |
| 112 | −To configure cpufreq-stats in your kernel | |
| 113 | −Config Main Menu | |
| 114 | − Power management options (ACPI, APM) ---> | |
| 115 | − CPU Frequency scaling ---> | |
| 116 | − [*] CPU Frequency scaling | |
| 117 | − [*] CPU frequency translation statistics | |
| 122 | + Config Main Menu | |
| 123 | + Power management options (ACPI, APM) ---> | |
| 124 | + CPU Frequency scaling ---> | |
| 125 | + [*] CPU Frequency scaling | |
| 126 | + [*] CPU frequency translation statistics | |
| 118 | 127 | |
| 119 | 128 | |
| 120 | 129 | "CPU Frequency scaling" (CONFIG_CPU_FREQ) should be enabled to configure |
| @@ -0,0 +1,39 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +============================================================================== | |
| 4 | +Linux CPUFreq - CPU frequency and voltage scaling code in the Linux(TM) kernel | |
| 5 | +============================================================================== | |
| 6 | + | |
| 7 | +Author: Dominik Brodowski <linux@brodo.de> | |
| 8 | + | |
| 9 | + Clock scaling allows you to change the clock speed of the CPUs on the | |
| 10 | + fly. This is a nice method to save battery power, because the lower | |
| 11 | + the clock speed, the less power the CPU consumes. | |
| 12 | + | |
| 13 | + | |
| 14 | +.. toctree:: | |
| 15 | + :maxdepth: 1 | |
| 16 | + | |
| 17 | + core | |
| 18 | + cpu-drivers | |
| 19 | + cpufreq-stats | |
| 20 | + | |
| 21 | +Mailing List | |
| 22 | +------------ | |
| 23 | +There is a CPU frequency changing CVS commit and general list where | |
| 24 | +you can report bugs, problems or submit patches. To post a message, | |
| 25 | +send an email to linux-pm@vger.kernel.org. | |
| 26 | + | |
| 27 | +Links | |
| 28 | +----- | |
| 29 | +the FTP archives: | |
| 30 | +* ftp://ftp.linux.org.uk/pub/linux/cpufreq/ | |
| 31 | + | |
| 32 | +how to access the CVS repository: | |
| 33 | +* http://cvs.arm.linux.org.uk/ | |
| 34 | + | |
| 35 | +the CPUFreq Mailing list: | |
| 36 | +* http://vger.kernel.org/vger-lists.html#linux-pm | |
| 37 | + | |
| 38 | +Clock and voltage scaling for the SA-1100: | |
| 39 | +* http://www.lartmaker.nl/projects/scaling | |
| @@ -1,56 +0,0 @@ | ||
| 1 | − CPU frequency and voltage scaling code in the Linux(TM) kernel | |
| 2 | − | |
| 3 | − | |
| 4 | − L i n u x C P U F r e q | |
| 5 | − | |
| 6 | − | |
| 7 | − | |
| 8 | − | |
| 9 | − Dominik Brodowski <linux@brodo.de> | |
| 10 | − | |
| 11 | − | |
| 12 | − | |
| 13 | − Clock scaling allows you to change the clock speed of the CPUs on the | |
| 14 | − fly. This is a nice method to save battery power, because the lower | |
| 15 | − the clock speed, the less power the CPU consumes. | |
| 16 | − | |
| 17 | − | |
| 18 | − | |
| 19 | −Documents in this directory: | |
| 20 | −---------------------------- | |
| 21 | − | |
| 22 | −amd-powernow.txt - AMD powernow driver specific file. | |
| 23 | − | |
| 24 | −core.txt - General description of the CPUFreq core and | |
| 25 | − of CPUFreq notifiers. | |
| 26 | − | |
| 27 | −cpu-drivers.txt - How to implement a new cpufreq processor driver. | |
| 28 | − | |
| 29 | −cpufreq-nforce2.txt - nVidia nForce2 platform specific file. | |
| 30 | − | |
| 31 | −cpufreq-stats.txt - General description of sysfs cpufreq stats. | |
| 32 | − | |
| 33 | −index.txt - File index, Mailing list and Links (this document) | |
| 34 | − | |
| 35 | −pcc-cpufreq.txt - PCC cpufreq driver specific file. | |
| 36 | − | |
| 37 | − | |
| 38 | −Mailing List | |
| 39 | −------------ | |
| 40 | −There is a CPU frequency changing CVS commit and general list where | |
| 41 | −you can report bugs, problems or submit patches. To post a message, | |
| 42 | −send an email to linux-pm@vger.kernel.org. | |
| 43 | − | |
| 44 | −Links | |
| 45 | −----- | |
| 46 | −the FTP archives: | |
| 47 | −* ftp://ftp.linux.org.uk/pub/linux/cpufreq/ | |
| 48 | − | |
| 49 | −how to access the CVS repository: | |
| 50 | −* http://cvs.arm.linux.org.uk/ | |
| 51 | − | |
| 52 | −the CPUFreq Mailing list: | |
| 53 | −* http://vger.kernel.org/vger-lists.html#linux-pm | |
| 54 | − | |
| 55 | −Clock and voltage scaling for the SA-1100: | |
| 56 | −* http://www.lartmaker.nl/projects/scaling | |
| @@ -1,207 +0,0 @@ | ||
| 1 | −/* | |
| 2 | − * pcc-cpufreq.txt - PCC interface documentation | |
| 3 | − * | |
| 4 | − * Copyright (C) 2009 Red Hat, Matthew Garrett <mjg@redhat.com> | |
| 5 | − * Copyright (C) 2009 Hewlett-Packard Development Company, L.P. | |
| 6 | − * Nagananda Chumbalkar <nagananda.chumbalkar@hp.com> | |
| 7 | − * | |
| 8 | − * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 9 | − * | |
| 10 | − * This program is free software; you can redistribute it and/or modify | |
| 11 | − * it under the terms of the GNU General Public License as published by | |
| 12 | − * the Free Software Foundation; version 2 of the License. | |
| 13 | − * | |
| 14 | − * This program is distributed in the hope that it will be useful, but | |
| 15 | − * WITHOUT ANY WARRANTY; without even the implied warranty of | |
| 16 | − * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or NON | |
| 17 | − * INFRINGEMENT. See the GNU General Public License for more details. | |
| 18 | − * | |
| 19 | − * You should have received a copy of the GNU General Public License along | |
| 20 | − * with this program; if not, write to the Free Software Foundation, Inc., | |
| 21 | − * 675 Mass Ave, Cambridge, MA 02139, USA. | |
| 22 | − * | |
| 23 | − * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 24 | − */ | |
| 25 | − | |
| 26 | − | |
| 27 | − Processor Clocking Control Driver | |
| 28 | − --------------------------------- | |
| 29 | − | |
| 30 | −Contents: | |
| 31 | −--------- | |
| 32 | −1. Introduction | |
| 33 | −1.1 PCC interface | |
| 34 | −1.1.1 Get Average Frequency | |
| 35 | −1.1.2 Set Desired Frequency | |
| 36 | −1.2 Platforms affected | |
| 37 | −2. Driver and /sys details | |
| 38 | −2.1 scaling_available_frequencies | |
| 39 | −2.2 cpuinfo_transition_latency | |
| 40 | −2.3 cpuinfo_cur_freq | |
| 41 | −2.4 related_cpus | |
| 42 | −3. Caveats | |
| 43 | − | |
| 44 | −1. Introduction: | |
| 45 | −---------------- | |
| 46 | −Processor Clocking Control (PCC) is an interface between the platform | |
| 47 | −firmware and OSPM. It is a mechanism for coordinating processor | |
| 48 | −performance (ie: frequency) between the platform firmware and the OS. | |
| 49 | − | |
| 50 | −The PCC driver (pcc-cpufreq) allows OSPM to take advantage of the PCC | |
| 51 | −interface. | |
| 52 | − | |
| 53 | −OS utilizes the PCC interface to inform platform firmware what frequency the | |
| 54 | −OS wants for a logical processor. The platform firmware attempts to achieve | |
| 55 | −the requested frequency. If the request for the target frequency could not be | |
| 56 | −satisfied by platform firmware, then it usually means that power budget | |
| 57 | −conditions are in place, and "power capping" is taking place. | |
| 58 | − | |
| 59 | −1.1 PCC interface: | |
| 60 | −------------------ | |
| 61 | −The complete PCC specification is available here: | |
| 62 | −http://www.acpica.org/download/Processor-Clocking-Control-v1p0.pdf | |
| 63 | − | |
| 64 | −PCC relies on a shared memory region that provides a channel for communication | |
| 65 | −between the OS and platform firmware. PCC also implements a "doorbell" that | |
| 66 | −is used by the OS to inform the platform firmware that a command has been | |
| 67 | −sent. | |
| 68 | − | |
| 69 | −The ACPI PCCH() method is used to discover the location of the PCC shared | |
| 70 | −memory region. The shared memory region header contains the "command" and | |
| 71 | −"status" interface. PCCH() also contains details on how to access the platform | |
| 72 | −doorbell. | |
| 73 | − | |
| 74 | −The following commands are supported by the PCC interface: | |
| 75 | −* Get Average Frequency | |
| 76 | −* Set Desired Frequency | |
| 77 | − | |
| 78 | −The ACPI PCCP() method is implemented for each logical processor and is | |
| 79 | −used to discover the offsets for the input and output buffers in the shared | |
| 80 | −memory region. | |
| 81 | − | |
| 82 | −When PCC mode is enabled, the platform will not expose processor performance | |
| 83 | −or throttle states (_PSS, _TSS and related ACPI objects) to OSPM. Therefore, | |
| 84 | −the native P-state driver (such as acpi-cpufreq for Intel, powernow-k8 for | |
| 85 | −AMD) will not load. | |
| 86 | − | |
| 87 | −However, OSPM remains in control of policy. The governor (eg: "ondemand") | |
| 88 | −computes the required performance for each processor based on server workload. | |
| 89 | −The PCC driver fills in the command interface, and the input buffer and | |
| 90 | −communicates the request to the platform firmware. The platform firmware is | |
| 91 | −responsible for delivering the requested performance. | |
| 92 | − | |
| 93 | −Each PCC command is "global" in scope and can affect all the logical CPUs in | |
| 94 | −the system. Therefore, PCC is capable of performing "group" updates. With PCC | |
| 95 | −the OS is capable of getting/setting the frequency of all the logical CPUs in | |
| 96 | −the system with a single call to the BIOS. | |
| 97 | − | |
| 98 | −1.1.1 Get Average Frequency: | |
| 99 | −---------------------------- | |
| 100 | −This command is used by the OSPM to query the running frequency of the | |
| 101 | −processor since the last time this command was completed. The output buffer | |
| 102 | −indicates the average unhalted frequency of the logical processor expressed as | |
| 103 | −a percentage of the nominal (ie: maximum) CPU frequency. The output buffer | |
| 104 | −also signifies if the CPU frequency is limited by a power budget condition. | |
| 105 | − | |
| 106 | −1.1.2 Set Desired Frequency: | |
| 107 | −---------------------------- | |
| 108 | −This command is used by the OSPM to communicate to the platform firmware the | |
| 109 | −desired frequency for a logical processor. The output buffer is currently | |
| 110 | −ignored by OSPM. The next invocation of "Get Average Frequency" will inform | |
| 111 | −OSPM if the desired frequency was achieved or not. | |
| 112 | − | |
| 113 | −1.2 Platforms affected: | |
| 114 | −----------------------- | |
| 115 | −The PCC driver will load on any system where the platform firmware: | |
| 116 | −* supports the PCC interface, and the associated PCCH() and PCCP() methods | |
| 117 | −* assumes responsibility for managing the hardware clocking controls in order | |
| 118 | −to deliver the requested processor performance | |
| 119 | − | |
| 120 | −Currently, certain HP ProLiant platforms implement the PCC interface. On those | |
| 121 | −platforms PCC is the "default" choice. | |
| 122 | − | |
| 123 | −However, it is possible to disable this interface via a BIOS setting. In | |
| 124 | −such an instance, as is also the case on platforms where the PCC interface | |
| 125 | −is not implemented, the PCC driver will fail to load silently. | |
| 126 | − | |
| 127 | −2. Driver and /sys details: | |
| 128 | −--------------------------- | |
| 129 | −When the driver loads, it merely prints the lowest and the highest CPU | |
| 130 | −frequencies supported by the platform firmware. | |
| 131 | − | |
| 132 | −The PCC driver loads with a message such as: | |
| 133 | −pcc-cpufreq: (v1.00.00) driver loaded with frequency limits: 1600 MHz, 2933 | |
| 134 | −MHz | |
| 135 | − | |
| 136 | −This means that the OPSM can request the CPU to run at any frequency in | |
| 137 | −between the limits (1600 MHz, and 2933 MHz) specified in the message. | |
| 138 | − | |
| 139 | −Internally, there is no need for the driver to convert the "target" frequency | |
| 140 | −to a corresponding P-state. | |
| 141 | − | |
| 142 | −The VERSION number for the driver will be of the format v.xy.ab. | |
| 143 | −eg: 1.00.02 | |
| 144 | − ----- -- | |
| 145 | − | | | |
| 146 | − | -- this will increase with bug fixes/enhancements to the driver | |
| 147 | − |-- this is the version of the PCC specification the driver adheres to | |
| 148 | − | |
| 149 | − | |
| 150 | −The following is a brief discussion on some of the fields exported via the | |
| 151 | −/sys filesystem and how their values are affected by the PCC driver: | |
| 152 | − | |
| 153 | −2.1 scaling_available_frequencies: | |
| 154 | −---------------------------------- | |
| 155 | −scaling_available_frequencies is not created in /sys. No intermediate | |
| 156 | −frequencies need to be listed because the BIOS will try to achieve any | |
| 157 | −frequency, within limits, requested by the governor. A frequency does not have | |
| 158 | −to be strictly associated with a P-state. | |
| 159 | − | |
| 160 | −2.2 cpuinfo_transition_latency: | |
| 161 | −------------------------------- | |
| 162 | −The cpuinfo_transition_latency field is 0. The PCC specification does | |
| 163 | −not include a field to expose this value currently. | |
| 164 | − | |
| 165 | −2.3 cpuinfo_cur_freq: | |
| 166 | −--------------------- | |
| 167 | −A) Often cpuinfo_cur_freq will show a value different than what is declared | |
| 168 | −in the scaling_available_frequencies or scaling_cur_freq, or scaling_max_freq. | |
| 169 | −This is due to "turbo boost" available on recent Intel processors. If certain | |
| 170 | −conditions are met the BIOS can achieve a slightly higher speed than requested | |
| 171 | −by OSPM. An example: | |
| 172 | − | |
| 173 | −scaling_cur_freq : 2933000 | |
| 174 | −cpuinfo_cur_freq : 3196000 | |
| 175 | − | |
| 176 | −B) There is a round-off error associated with the cpuinfo_cur_freq value. | |
| 177 | −Since the driver obtains the current frequency as a "percentage" (%) of the | |
| 178 | −nominal frequency from the BIOS, sometimes, the values displayed by | |
| 179 | −scaling_cur_freq and cpuinfo_cur_freq may not match. An example: | |
| 180 | − | |
| 181 | −scaling_cur_freq : 1600000 | |
| 182 | −cpuinfo_cur_freq : 1583000 | |
| 183 | − | |
| 184 | −In this example, the nominal frequency is 2933 MHz. The driver obtains the | |
| 185 | −current frequency, cpuinfo_cur_freq, as 54% of the nominal frequency: | |
| 186 | − | |
| 187 | − 54% of 2933 MHz = 1583 MHz | |
| 188 | − | |
| 189 | −Nominal frequency is the maximum frequency of the processor, and it usually | |
| 190 | −corresponds to the frequency of the P0 P-state. | |
| 191 | − | |
| 192 | −2.4 related_cpus: | |
| 193 | −----------------- | |
| 194 | −The related_cpus field is identical to affected_cpus. | |
| 195 | − | |
| 196 | −affected_cpus : 4 | |
| 197 | −related_cpus : 4 | |
| 198 | − | |
| 199 | −Currently, the PCC driver does not evaluate _PSD. The platforms that support | |
| 200 | −PCC do not implement SW_ALL. So OSPM doesn't need to perform any coordination | |
| 201 | −to ensure that the same frequency is requested of all dependent CPUs. | |
| 202 | − | |
| 203 | −3. Caveats: | |
| 204 | −----------- | |
| 205 | −The "cpufreq_stats" module in its present form cannot be loaded and | |
| 206 | −expected to work with the PCC driver. Since the "cpufreq_stats" module | |
| 207 | −provides information wrt each P-state, it is not applicable to the PCC driver. | |
| @@ -1,22 +0,0 @@ | ||
| 1 | −Debugging Modules after 2.6.3 | |
| 2 | −----------------------------- | |
| 3 | − | |
| 4 | −In almost all distributions, the kernel asks for modules which don't | |
| 5 | −exist, such as "net-pf-10" or whatever. Changing "modprobe -q" to | |
| 6 | −"succeed" in this case is hacky and breaks some setups, and also we | |
| 7 | −want to know if it failed for the fallback code for old aliases in | |
| 8 | −fs/char_dev.c, for example. | |
| 9 | − | |
| 10 | −In the past a debugging message which would fill people's logs was | |
| 11 | −emitted. This debugging message has been removed. The correct way | |
| 12 | −of debugging module problems is something like this: | |
| 13 | − | |
| 14 | −echo '#! /bin/sh' > /tmp/modprobe | |
| 15 | −echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe | |
| 16 | −echo 'exec /sbin/modprobe "$@"' >> /tmp/modprobe | |
| 17 | −chmod a+x /tmp/modprobe | |
| 18 | −echo /tmp/modprobe > /proc/sys/kernel/modprobe | |
| 19 | − | |
| 20 | −Note that the above applies only when the *kernel* is requesting | |
| 21 | −that the module be loaded -- it won't have any effect if that module | |
| 22 | −is being loaded explicitly using "modprobe" from userspace. | |
| @@ -203,7 +203,7 @@ Cause · 202 unmodified lines | ||
| 203 | 203 | may not correctly copy files from sysfs. |
| 204 | 204 | |
| 205 | 205 | Solution |
| 206 | − Use ``cat``' to read ``.gcda`` files and ``cp -d`` to copy links. | |
| 206 | + Use ``cat`` to read ``.gcda`` files and ``cp -d`` to copy links. | |
| 207 | 207 | Alternatively use the mechanism shown in Appendix B. |
| 208 | 208 | |
| 209 | 209 | |
| @@ -8,7 +8,8 @@ with the difference that the orphan objects are not freed but only · 7 unmodified lines | ||
| 8 | 8 | reported via /sys/kernel/debug/kmemleak. A similar method is used by the |
| 9 | 9 | Valgrind tool (``memcheck --leak-check``) to detect the memory leaks in |
| 10 | 10 | user-space applications. |
| 11 | −Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze, ppc, mips, s390 and tile. | |
| 11 | +Kmemleak is supported on x86, arm, arm64, powerpc, sparc, sh, microblaze, mips, | |
| 12 | +s390, nds32, arc and xtensa. | |
| 12 | 13 | |
| 13 | 14 | Usage |
| 14 | 15 | ----- |
| @@ -17,14 +17,23 @@ What is KUnit? · 16 unmodified lines | ||
| 17 | 17 | ============== |
| 18 | 18 | |
| 19 | 19 | KUnit is a lightweight unit testing and mocking framework for the Linux kernel. |
| 20 | −These tests are able to be run locally on a developer's workstation without a VM | |
| 21 | −or special hardware. | |
| 22 | 20 | |
| 23 | 21 | KUnit is heavily inspired by JUnit, Python's unittest.mock, and |
| 24 | 22 | Googletest/Googlemock for C++. KUnit provides facilities for defining unit test |
| 25 | 23 | cases, grouping related test cases into test suites, providing common |
| 26 | 24 | infrastructure for running tests, and much more. |
| 27 | 25 | |
| 26 | +KUnit consists of a kernel component, which provides a set of macros for easily | |
| 27 | +writing unit tests. Tests written against KUnit will run on kernel boot if | |
| 28 | +built-in, or when loaded if built as a module. These tests write out results to | |
| 29 | +the kernel log in `TAP <https://testanything.org/>`_ format. | |
| 30 | + | |
| 31 | +To make running these tests (and reading the results) easier, KUnit offers | |
| 32 | +:doc:`kunit_tool <kunit-tool>`, which builds a `User Mode Linux | |
| 33 | +<http://user-mode-linux.sourceforge.net>`_ kernel, runs it, and parses the test | |
| 34 | +results. This provides a quick way of running KUnit tests during development, | |
| 35 | +without requiring a virtual machine or separate hardware. | |
| 36 | + | |
| 28 | 37 | Get started now: :doc:`start` |
| 29 | 38 | |
| 30 | 39 | Why KUnit? |
| @@ -36,21 +45,20 @@ allow all possible code paths to be tested in the code under test; this is only · 5 unmodified lines | ||
| 36 | 45 | possible if the code under test is very small and does not have any external |
| 37 | 46 | dependencies outside of the test's control like hardware. |
| 38 | 47 | |
| 39 | −Outside of KUnit, there are no testing frameworks currently | |
| 40 | −available for the kernel that do not require installing the kernel on a test | |
| 41 | −machine or in a VM and all require tests to be written in userspace running on | |
| 42 | −the kernel; this is true for Autotest, and kselftest, disqualifying | |
| 43 | −any of them from being considered unit testing frameworks. | |
| 48 | +KUnit provides a common framework for unit tests within the kernel. | |
| 49 | + | |
| 50 | +KUnit tests can be run on most architectures, and most tests are architecture | |
| 51 | +independent. All built-in KUnit tests run on kernel startup. Alternatively, | |
| 52 | +KUnit and KUnit tests can be built as modules and tests will run when the test | |
| 53 | +module is loaded. | |
| 44 | 54 | |
| 45 | −KUnit addresses the problem of being able to run tests without needing a virtual | |
| 46 | −machine or actual hardware with User Mode Linux. User Mode Linux is a Linux | |
| 47 | −architecture, like ARM or x86; however, unlike other architectures it compiles | |
| 48 | −to a standalone program that can be run like any other program directly inside | |
| 49 | −of a host operating system; to be clear, it does not require any virtualization | |
| 50 | −support; it is just a regular program. | |
| 55 | +.. note:: | |
| 51 | 56 | |
| 52 | −Alternatively, kunit and kunit tests can be built as modules and tests will | |
| 53 | −run when the test module is loaded. | |
| 57 | + KUnit can also run tests without needing a virtual machine or actual | |
| 58 | + hardware under User Mode Linux. User Mode Linux is a Linux architecture, | |
| 59 | + like ARM or x86, which compiles the kernel as a Linux executable. KUnit | |
| 60 | + can be used with UML either by building with ``ARCH=um`` (like any other | |
| 61 | + architecture), or by using :doc:`kunit_tool <kunit-tool>`. | |
| 54 | 62 | |
| 55 | 63 | KUnit is fast. Excluding build time, from invocation to completion KUnit can run |
| 56 | 64 | several dozen tests in only 10 to 20 seconds; this might not sound like a big |
| @@ -81,3 +89,5 @@ How do I use it? · 24 unmodified lines | ||
| 81 | 89 | * :doc:`start` - for new users of KUnit |
| 82 | 90 | * :doc:`usage` - for a more detailed explanation of KUnit features |
| 83 | 91 | * :doc:`api/index` - for the list of KUnit APIs used for testing |
| 92 | +* :doc:`kunit-tool` - for more information on the kunit_tool helper script | |
| 93 | +* :doc:`faq` - for answers to some common questions about KUnit | |
| @@ -12,6 +12,13 @@ the Linux kernel as UML (`User Mode Linux · 11 unmodified lines | ||
| 12 | 12 | <http://user-mode-linux.sourceforge.net/>`_), running KUnit tests, parsing |
| 13 | 13 | the test results and displaying them in a user friendly manner. |
| 14 | 14 | |
| 15 | +kunit_tool addresses the problem of being able to run tests without needing a | |
| 16 | +virtual machine or actual hardware with User Mode Linux. User Mode Linux is a | |
| 17 | +Linux architecture, like ARM or x86; however, unlike other architectures it | |
| 18 | +compiles the kernel as a standalone Linux executable that can be run like any | |
| 19 | +other program directly inside of a host operating system. To be clear, it does | |
| 20 | +not require any virtualization support: it is just a regular program. | |
| 21 | + | |
| 15 | 22 | What is a kunitconfig? |
| 16 | 23 | ====================== |
| 17 | 24 | |
| @@ -9,11 +9,10 @@ Installing dependencies · 8 unmodified lines | ||
| 9 | 9 | KUnit has the same dependencies as the Linux kernel. As long as you can build |
| 10 | 10 | the kernel, you can run KUnit. |
| 11 | 11 | |
| 12 | −KUnit Wrapper | |
| 13 | −============= | |
| 14 | −Included with KUnit is a simple Python wrapper that helps format the output to | |
| 15 | −easily use and read KUnit output. It handles building and running the kernel, as | |
| 16 | −well as formatting the output. | |
| 12 | +Running tests with the KUnit Wrapper | |
| 13 | +==================================== | |
| 14 | +Included with KUnit is a simple Python wrapper which runs tests under User Mode | |
| 15 | +Linux, and formats the test results. | |
| 17 | 16 | |
| 18 | 17 | The wrapper can be run with: |
| 19 | 18 | |
| @@ -21,22 +20,42 @@ The wrapper can be run with: · 1 unmodified line | ||
| 21 | 20 | |
| 22 | 21 | ./tools/testing/kunit/kunit.py run --defconfig |
| 23 | 22 | |
| 24 | −For more information on this wrapper (also called kunit_tool) checkout the | |
| 23 | +For more information on this wrapper (also called kunit_tool) check out the | |
| 25 | 24 | :doc:`kunit-tool` page. |
| 26 | 25 | |
| 27 | 26 | Creating a .kunitconfig |
| 28 | −======================= | |
| 29 | −The Python script is a thin wrapper around Kbuild. As such, it needs to be | |
| 30 | −configured with a ``.kunitconfig`` file. This file essentially contains the | |
| 31 | −regular Kernel config, with the specific test targets as well. | |
| 32 | − | |
| 27 | +----------------------- | |
| 28 | +If you want to run a specific set of tests (rather than those listed in the | |
| 29 | +KUnit defconfig), you can provide Kconfig options in the ``.kunitconfig`` file. | |
| 30 | +This file essentially contains the regular Kernel config, with the specific | |
| 31 | +test targets as well. The ``.kunitconfig`` should also contain any other config | |
| 32 | +options required by the tests. | |
| 33 | + | |
| 34 | +A good starting point for a ``.kunitconfig`` is the KUnit defconfig: | |
| 33 | 35 | .. code-block:: bash |
| 34 | 36 | |
| 35 | 37 | cd $PATH_TO_LINUX_REPO |
| 36 | 38 | cp arch/um/configs/kunit_defconfig .kunitconfig |
| 37 | 39 | |
| 38 | −Verifying KUnit Works | |
| 39 | −--------------------- | |
| 40 | +You can then add any other Kconfig options you wish, e.g.: | |
| 41 | +.. code-block:: none | |
| 42 | + | |
| 43 | + CONFIG_LIST_KUNIT_TEST=y | |
| 44 | + | |
| 45 | +:doc:`kunit_tool <kunit-tool>` will ensure that all config options set in | |
| 46 | +``.kunitconfig`` are set in the kernel ``.config`` before running the tests. | |
| 47 | +It'll warn you if you haven't included the dependencies of the options you're | |
| 48 | +using. | |
| 49 | + | |
| 50 | +.. note:: | |
| 51 | + Note that removing something from the ``.kunitconfig`` will not trigger a | |
| 52 | + rebuild of the ``.config`` file: the configuration is only updated if the | |
| 53 | + ``.kunitconfig`` is not a subset of ``.config``. This means that you can use | |
| 54 | + other tools (such as make menuconfig) to adjust other config options. | |
| 55 | + | |
| 56 | + | |
| 57 | +Running the tests | |
| 58 | +----------------- | |
| 40 | 59 | |
| 41 | 60 | To make sure that everything is set up correctly, simply invoke the Python |
| 42 | 61 | wrapper from your kernel repo: |
| @@ -62,6 +81,41 @@ followed by a list of tests that are run. All of them should be passing. · 19 unmodified lines | ||
| 62 | 81 | Because it is building a lot of sources for the first time, the |
| 63 | 82 | ``Building KUnit kernel`` step may take a while. |
| 64 | 83 | |
| 84 | +Running tests without the KUnit Wrapper | |
| 85 | +======================================= | |
| 86 | + | |
| 87 | +If you'd rather not use the KUnit Wrapper (if, for example, you need to | |
| 88 | +integrate with other systems, or use an architecture other than UML), KUnit can | |
| 89 | +be included in any kernel, and the results read out and parsed manually. | |
| 90 | + | |
| 91 | +.. note:: | |
| 92 | + KUnit is not designed for use in a production system, and it's possible that | |
| 93 | + tests may reduce the stability or security of the system. | |
| 94 | + | |
| 95 | + | |
| 96 | + | |
| 97 | +Configuring the kernel | |
| 98 | +---------------------- | |
| 99 | + | |
| 100 | +In order to enable KUnit itself, you simply need to enable the ``CONFIG_KUNIT`` | |
| 101 | +Kconfig option (it's under Kernel Hacking/Kernel Testing and Coverage in | |
| 102 | +menuconfig). From there, you can enable any KUnit tests you want: they usually | |
| 103 | +have config options ending in ``_KUNIT_TEST``. | |
| 104 | + | |
| 105 | +KUnit and KUnit tests can be compiled as modules: in this case the tests in a | |
| 106 | +module will be run when the module is loaded. | |
| 107 | + | |
| 108 | +Running the tests | |
| 109 | +----------------- | |
| 110 | + | |
| 111 | +Build and run your kernel as usual. Test output will be written to the kernel | |
| 112 | +log in `TAP <https://testanything.org/>`_ format. | |
| 113 | + | |
| 114 | +.. note:: | |
| 115 | + It's possible that there will be other lines and/or data interspersed in the | |
| 116 | + TAP output. | |
| 117 | + | |
| 118 | + | |
| 65 | 119 | Writing your first test |
| 66 | 120 | ======================= |
| 67 | 121 | |
| @@ -591,3 +591,17 @@ able to run one test case per invocation. · 590 unmodified lines | ||
| 591 | 591 | |
| 592 | 592 | .. TODO(brendanhiggins@google.com): Add an actual example of an architecture |
| 593 | 593 | dependent KUnit test. |
| 594 | + | |
| 595 | +KUnit debugfs representation | |
| 596 | +============================ | |
| 597 | +When kunit test suites are initialized, they create an associated directory | |
| 598 | +in /sys/kernel/debug/kunit/<test-suite>. The directory contains one file | |
| 599 | + | |
| 600 | +- results: "cat results" displays results of each test case and the results | |
| 601 | + of the entire suite for the last test run. | |
| 602 | + | |
| 603 | +The debugfs representation is primarily of use when kunit test suites are | |
| 604 | +run in a native environment, either as modules or builtin. Having a way | |
| 605 | +to display results like this is valuable as otherwise results can be | |
| 606 | +intermixed with other events in dmesg output. The maximum size of each | |
| 607 | +results file is KUNIT_LOG_SIZE bytes (defined in include/kunit/test.h). | |
| @@ -1,2 +1,3 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0-only | |
| 1 | 2 | *.example.dts |
| 2 | −processed-schema.yaml | |
| 3 | +processed-schema*.yaml | |
| @@ -2,7 +2,6 @@ · 1 unmodified line | ||
| 2 | 2 | DT_DOC_CHECKER ?= dt-doc-validate |
| 3 | 3 | DT_EXTRACT_EX ?= dt-extract-example |
| 4 | 4 | DT_MK_SCHEMA ?= dt-mk-schema |
| 5 | −DT_MK_SCHEMA_FLAGS := $(if $(DT_SCHEMA_FILES), -u) | |
| 6 | 5 | |
| 7 | 6 | quiet_cmd_chk_binding = CHKDT $(patsubst $(srctree)/%,%,$<) |
| 8 | 7 | cmd_chk_binding = $(DT_DOC_CHECKER) -u $(srctree)/$(src) $< ; \ |
| @@ -11,26 +10,35 @@ quiet_cmd_chk_binding = CHKDT $(patsubst $(srctree)/%,%,$<) · 2 unmodified lines | ||
| 11 | 10 | $(obj)/%.example.dts: $(src)/%.yaml FORCE |
| 12 | 11 | $(call if_changed,chk_binding) |
| 13 | 12 | |
| 14 | −DT_TMP_SCHEMA := processed-schema.yaml | |
| 13 | +# Use full schemas when checking %.example.dts | |
| 14 | +DT_TMP_SCHEMA := $(obj)/processed-schema-examples.yaml | |
| 15 | 15 | |
| 16 | 16 | quiet_cmd_mk_schema = SCHEMA $@ |
| 17 | 17 | cmd_mk_schema = $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ $(real-prereqs) |
| 18 | 18 | |
| 19 | −DT_DOCS = $(shell \ | |
| 19 | +DT_DOCS = $(addprefix $(src)/, \ | |
| 20 | + $(shell \ | |
| 20 | 21 | cd $(srctree)/$(src) && \ |
| 21 | 22 | find * \( -name '*.yaml' ! \ |
| 22 | − -name $(DT_TMP_SCHEMA) ! \ | |
| 23 | + -name 'processed-schema*' ! \ | |
| 23 | 24 | -name '*.example.dt.yaml' \) \ |
| 24 | − ) | |
| 25 | + )) | |
| 25 | 26 | |
| 26 | −DT_SCHEMA_FILES ?= $(addprefix $(src)/,$(DT_DOCS)) | |
| 27 | +DT_SCHEMA_FILES ?= $(DT_DOCS) | |
| 27 | 28 | |
| 28 | −ifeq ($(CHECK_DTBS),) | |
| 29 | −extra-y += $(patsubst $(src)/%.yaml,%.example.dts, $(DT_SCHEMA_FILES)) | |
| 30 | −extra-y += $(patsubst $(src)/%.yaml,%.example.dt.yaml, $(DT_SCHEMA_FILES)) | |
| 31 | −endif | |
| 29 | +extra-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dts, $(DT_SCHEMA_FILES)) | |
| 30 | +extra-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dt.yaml, $(DT_SCHEMA_FILES)) | |
| 31 | +extra-$(CHECK_DT_BINDING) += processed-schema-examples.yaml | |
| 32 | 32 | |
| 33 | −$(obj)/$(DT_TMP_SCHEMA): $(DT_SCHEMA_FILES) FORCE | |
| 33 | +override DTC_FLAGS := \ | |
| 34 | + -Wno-avoid_unnecessary_addr_size \ | |
| 35 | + -Wno-graph_child_address | |
| 36 | + | |
| 37 | +$(obj)/processed-schema-examples.yaml: $(DT_DOCS) FORCE | |
| 38 | + $(call if_changed,mk_schema) | |
| 39 | + | |
| 40 | +$(obj)/processed-schema.yaml: DT_MK_SCHEMA_FLAGS := -u | |
| 41 | +$(obj)/processed-schema.yaml: $(DT_SCHEMA_FILES) FORCE | |
| 34 | 42 | $(call if_changed,mk_schema) |
| 35 | 43 | |
| 36 | −extra-y += $(DT_TMP_SCHEMA) | |
| 44 | +extra-y += processed-schema.yaml | |
| @@ -21,6 +21,8 @@ properties: · 20 unmodified lines | ||
| 21 | 21 | required: |
| 22 | 22 | - compatible |
| 23 | 23 | |
| 24 | +additionalProperties: false | |
| 25 | + | |
| 24 | 26 | examples: |
| 25 | 27 | - | |
| 26 | 28 | clkmgr@ffd04000 { |
| @@ -43,6 +43,8 @@ required: · 42 unmodified lines | ||
| 43 | 43 | - compatible |
| 44 | 44 | - reg |
| 45 | 45 | |
| 46 | +additionalProperties: false | |
| 47 | + | |
| 46 | 48 | examples: |
| 47 | 49 | - | |
| 48 | 50 | ao-secure@140 { |
| @@ -0,0 +1,86 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/arm/arm,integrator.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: ARM Integrator Boards Device Tree Bindings | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Linus Walleij <linus.walleij@linaro.org> | |
| 11 | + | |
| 12 | +description: |+ | |
| 13 | + These were the first ARM platforms officially supported by ARM Ltd. | |
| 14 | + They are ARMv4, ARMv5 and ARMv6-capable using different core tiles, | |
| 15 | + so the system is modular and can host a variety of CPU tiles called | |
| 16 | + "core tiles" and referred to in the device tree as "core modules". | |
| 17 | + | |
| 18 | +properties: | |
| 19 | + $nodename: | |
| 20 | + const: '/' | |
| 21 | + compatible: | |
| 22 | + oneOf: | |
| 23 | + - description: ARM Integrator Application Platform, this board has a PCI | |
| 24 | + host and several PCI slots, as well as a number of slots for logical | |
| 25 | + expansion modules, it is referred to as an "ASIC Development | |
| 26 | + Motherboard" and is extended with custom FPGA and is intended for | |
| 27 | + rapid prototyping. See ARM DUI 0098B. This board can physically come | |
| 28 | + pre-packaged in a PC Tower form factor called Integrator/PP1 or a | |
| 29 | + special metal fixture called Integrator/PP2, see ARM DUI 0169A. | |
| 30 | + items: | |
| 31 | + - const: arm,integrator-ap | |
| 32 | + - description: ARM Integrator Compact Platform (HBI-0086), this board has | |
| 33 | + a compact form factor and mainly consists of the bare minimum | |
| 34 | + peripherals to make use of the core module. See ARM DUI 0159B. | |
| 35 | + items: | |
| 36 | + - const: arm,integrator-cp | |
| 37 | + - description: ARM Integrator Standard Development Board (SDB) Platform, | |
| 38 | + this board is a PCI-based board conforming to the Microsoft SDB | |
| 39 | + (HARP) specification. See ARM DUI 0099A. | |
| 40 | + items: | |
| 41 | + - const: arm,integrator-sp | |
| 42 | + | |
| 43 | + core-module@10000000: | |
| 44 | + type: object | |
| 45 | + description: the root node in the Integrator platforms must contain | |
| 46 | + a core module child node. They are always at physical address | |
| 47 | + 0x10000000 in all the Integrator variants. | |
| 48 | + properties: | |
| 49 | + compatible: | |
| 50 | + items: | |
| 51 | + - const: arm,core-module-integrator | |
| 52 | + - const: syscon | |
| 53 | + - const: simple-mfd | |
| 54 | + reg: | |
| 55 | + maxItems: 1 | |
| 56 | + | |
| 57 | + required: | |
| 58 | + - compatible | |
| 59 | + - reg | |
| 60 | + | |
| 61 | +patternProperties: | |
| 62 | + "^syscon@[0-9a-f]+$": | |
| 63 | + description: All Integrator boards must provide a system controller as a | |
| 64 | + node in the root of the device tree. | |
| 65 | + type: object | |
| 66 | + properties: | |
| 67 | + compatible: | |
| 68 | + items: | |
| 69 | + - enum: | |
| 70 | + - arm,integrator-ap-syscon | |
| 71 | + - arm,integrator-cp-syscon | |
| 72 | + - arm,integrator-sp-syscon | |
| 73 | + - const: syscon | |
| 74 | + reg: | |
| 75 | + maxItems: 1 | |
| 76 | + | |
| 77 | + required: | |
| 78 | + - compatible | |
| 79 | + - reg | |
| 80 | + | |
| 81 | + | |
| 82 | +required: | |
| 83 | + - compatible | |
| 84 | + - core-module@10000000 | |
| 85 | + | |
| 86 | +... | |
| @@ -0,0 +1,123 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/arm/arm,realview.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: ARM RealView Boards Device Tree Bindings | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Linus Walleij <linus.walleij@linaro.org> | |
| 11 | + | |
| 12 | +description: |+ | |
| 13 | + The ARM RealView series of reference designs were built to explore the ARM | |
| 14 | + 11, Cortex A-8 and Cortex A-9 CPUs. This included new features compared to | |
| 15 | + the earlier CPUs such as TrustZone and multicore (MPCore). | |
| 16 | + | |
| 17 | +properties: | |
| 18 | + $nodename: | |
| 19 | + const: '/' | |
| 20 | + compatible: | |
| 21 | + oneOf: | |
| 22 | + - description: ARM RealView Emulation Baseboard (HBI-0140) was created | |
| 23 | + as a generic platform to test different FPGA designs, and has | |
| 24 | + pluggable CPU modules, see ARM DUI 0303E. | |
| 25 | + items: | |
| 26 | + - const: arm,realview-eb | |
| 27 | + - description: ARM RealView Platform Baseboard for ARM1176JZF-S | |
| 28 | + (HBI-0147) was created as a development board to test ARM TrustZone, | |
| 29 | + CoreSight and Intelligent Energy Management (IEM) see ARM DUI 0425F. | |
| 30 | + items: | |
| 31 | + - const: arm,realview-pb1176 | |
| 32 | + - description: ARM RealView Platform Baseboard for ARM 11 MPCore | |
| 33 | + (HBI-0159, HBI-0175 and HBI-0176) was created to showcase | |
| 34 | + multiprocessing with ARM11 using MPCore using symmetric | |
| 35 | + multiprocessing (SMP). See ARM DUI 0351E. | |
| 36 | + items: | |
| 37 | + - const: arm,realview-pb11mp | |
| 38 | + - description: ARM RealView Platform Baseboard for Cortex-A8 (HBI-0178, | |
| 39 | + HBI-0176 and HBI-0175) was the first reference platform for the | |
| 40 | + Cortex CPU family, including a Cortex-A8 test chip. | |
| 41 | + items: | |
| 42 | + - const: arm,realview-pba8 | |
| 43 | + - description: ARM RealView Platform Baseboard Explore for Cortex-A9 | |
| 44 | + (HBI-0182 and HBI-0183) was the reference platform for the Cortex-A9 | |
| 45 | + CPU. | |
| 46 | + items: | |
| 47 | + - const: arm,realview-pbx | |
| 48 | + | |
| 49 | + soc: | |
| 50 | + description: All RealView boards must provide a soc node in the root of the | |
| 51 | + device tree, representing the System-on-Chip since these test chips are | |
| 52 | + rather complex. | |
| 53 | + type: object | |
| 54 | + properties: | |
| 55 | + compatible: | |
| 56 | + oneOf: | |
| 57 | + - items: | |
| 58 | + - const: arm,realview-eb-soc | |
| 59 | + - const: simple-bus | |
| 60 | + - items: | |
| 61 | + - const: arm,realview-pb1176-soc | |
| 62 | + - const: simple-bus | |
| 63 | + - items: | |
| 64 | + - const: arm,realview-pb11mp-soc | |
| 65 | + - const: simple-bus | |
| 66 | + - items: | |
| 67 | + - const: arm,realview-pba8-soc | |
| 68 | + - const: simple-bus | |
| 69 | + - items: | |
| 70 | + - const: arm,realview-pbx-soc | |
| 71 | + - const: simple-bus | |
| 72 | + | |
| 73 | + patternProperties: | |
| 74 | + "^.*syscon@[0-9a-f]+$": | |
| 75 | + type: object | |
| 76 | + description: All RealView boards must provide a syscon system controller | |
| 77 | + node inside the soc node. | |
| 78 | + properties: | |
| 79 | + compatible: | |
| 80 | + oneOf: | |
| 81 | + - items: | |
| 82 | + - const: arm,realview-eb11mp-revb-syscon | |
| 83 | + - const: arm,realview-eb-syscon | |
| 84 | + - const: syscon | |
| 85 | + - const: simple-mfd | |
| 86 | + - items: | |
| 87 | + - const: arm,realview-eb11mp-revc-syscon | |
| 88 | + - const: arm,realview-eb-syscon | |
| 89 | + - const: syscon | |
| 90 | + - const: simple-mfd | |
| 91 | + - items: | |
| 92 | + - const: arm,realview-eb-syscon | |
| 93 | + - const: syscon | |
| 94 | + - const: simple-mfd | |
| 95 | + - items: | |
| 96 | + - const: arm,realview-pb1176-syscon | |
| 97 | + - const: syscon | |
| 98 | + - const: simple-mfd | |
| 99 | + - items: | |
| 100 | + - const: arm,realview-pb11mp-syscon | |
| 101 | + - const: syscon | |
| 102 | + - const: simple-mfd | |
| 103 | + - items: | |
| 104 | + - const: arm,realview-pba8-syscon | |
| 105 | + - const: syscon | |
| 106 | + - const: simple-mfd | |
| 107 | + - items: | |
| 108 | + - const: arm,realview-pbx-syscon | |
| 109 | + - const: syscon | |
| 110 | + - const: simple-mfd | |
| 111 | + | |
| 112 | + required: | |
| 113 | + - compatible | |
| 114 | + - reg | |
| 115 | + | |
| 116 | + required: | |
| 117 | + - compatible | |
| 118 | + | |
| 119 | +required: | |
| 120 | + - compatible | |
| 121 | + - soc | |
| 122 | + | |
| 123 | +... | |
| @@ -0,0 +1,71 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/arm/arm,versatile.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: ARM Versatile Boards Device Tree Bindings | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Linus Walleij <linus.walleij@linaro.org> | |
| 11 | + | |
| 12 | +description: |+ | |
| 13 | + The ARM Versatile boards are two variants of ARM926EJ-S evaluation boards | |
| 14 | + with various pluggable interface boards, in essence the Versatile PB version | |
| 15 | + is a superset of the Versatile AB version. | |
| 16 | + | |
| 17 | +properties: | |
| 18 | + $nodename: | |
| 19 | + const: '/' | |
| 20 | + compatible: | |
| 21 | + oneOf: | |
| 22 | + - description: The ARM Versatile Application Baseboard (HBI-0118) is an | |
| 23 | + evaluation board specifically for the ARM926EJ-S. It can be connected | |
| 24 | + to an IB1 interface board for a touchscreen-type use case or an IB2 | |
| 25 | + for a candybar phone-type use case. See ARM DUI 0225D. | |
| 26 | + items: | |
| 27 | + - const: arm,versatile-ab | |
| 28 | + - description: The ARM Versatile Platform Baseboard (HBI-0117) is an | |
| 29 | + extension of the Versatile Application Baseboard that includes a | |
| 30 | + PCI host controller. Like the sibling board, it is done specifically | |
| 31 | + for ARM926EJ-S. See ARM DUI 0224B. | |
| 32 | + items: | |
| 33 | + - const: arm,versatile-pb | |
| 34 | + | |
| 35 | + core-module@10000000: | |
| 36 | + type: object | |
| 37 | + description: the root node in the Versatile platforms must contain | |
| 38 | + a core module child node. They are always at physical address | |
| 39 | + 0x10000000 in all the Versatile variants. | |
| 40 | + properties: | |
| 41 | + compatible: | |
| 42 | + items: | |
| 43 | + - const: arm,core-module-versatile | |
| 44 | + - const: syscon | |
| 45 | + - const: simple-mfd | |
| 46 | + reg: | |
| 47 | + maxItems: 1 | |
| 48 | + | |
| 49 | + required: | |
| 50 | + - compatible | |
| 51 | + - reg | |
| 52 | + | |
| 53 | +patternProperties: | |
| 54 | + "^syscon@[0-9a-f]+$": | |
| 55 | + type: object | |
| 56 | + description: When fitted with the IB2 Interface Board, the Versatile | |
| 57 | + AB will present an optional system controller node which controls the | |
| 58 | + extra peripherals on the interface board. | |
| 59 | + properties: | |
| 60 | + compatible: | |
| 61 | + contains: | |
| 62 | + const: arm,versatile-ib2-syscon | |
| 63 | + required: | |
| 64 | + - compatible | |
| 65 | + - reg | |
| 66 | + | |
| 67 | +required: | |
| 68 | + - compatible | |
| 69 | + - core-module@10000000 | |
| 70 | + | |
| 71 | +... | |
| @@ -0,0 +1,223 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/arm/arm,vexpress-juno.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: ARM Versatile Express and Juno Boards Device Tree Bindings | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Sudeep Holla <sudeep.holla@arm.com> | |
| 11 | + - Linus Walleij <linus.walleij@linaro.org> | |
| 12 | + | |
| 13 | +description: |+ | |
| 14 | + ARM's Versatile Express platform were built as reference designs for exploring | |
| 15 | + multicore Cortex-A class systems. The Versatile Express family contains both | |
| 16 | + 32 bit (Aarch32) and 64 bit (Aarch64) systems. | |
| 17 | + | |
| 18 | + The board consist of a motherboard and one or more daughterboards (tiles). The | |
| 19 | + motherboard provides a set of peripherals. Processor and RAM "live" on the | |
| 20 | + tiles. | |
| 21 | + | |
| 22 | + The motherboard and each core tile should be described by a separate Device | |
| 23 | + Tree source file, with the tile's description including the motherboard file | |
| 24 | + using an include directive. As the motherboard can be initialized in one of | |
| 25 | + two different configurations ("memory maps"), care must be taken to include | |
| 26 | + the correct one. | |
| 27 | + | |
| 28 | + When a new generation of boards were introduced under the name "Juno", these | |
| 29 | + shared to many common characteristics with the Versatile Express that the | |
| 30 | + "arm,vexpress" compatible was retained in the root node, and these are | |
| 31 | + included in this binding schema as well. | |
| 32 | + | |
| 33 | + The root node indicates the CPU SoC on the core tile, and this | |
| 34 | + is a daughterboard to the main motherboard. The name used in the compatible | |
| 35 | + string shall match the name given in the core tile's technical reference | |
| 36 | + manual, followed by "arm,vexpress" as an additional compatible value. If | |
| 37 | + further subvariants are released of the core tile, even more fine-granular | |
| 38 | + compatible strings with up to three compatible strings are used. | |
| 39 | + | |
| 40 | +properties: | |
| 41 | + $nodename: | |
| 42 | + const: '/' | |
| 43 | + compatible: | |
| 44 | + oneOf: | |
| 45 | + - description: CoreTile Express A9x4 (V2P-CA9) has 4 Cortex A9 CPU cores | |
| 46 | + in MPCore configuration in a test chip on the core tile. See ARM | |
| 47 | + DUI 0448I. This was the first Versatile Express platform. | |
| 48 | + items: | |
| 49 | + - const: arm,vexpress,v2p-ca9 | |
| 50 | + - const: arm,vexpress | |
| 51 | + - description: CoreTile Express A5x2 (V2P-CA5s) has 2 Cortex A5 CPU cores | |
| 52 | + in a test chip on the core tile. It is intended to evaluate NEON, FPU | |
| 53 | + and Jazelle support in the Cortex A5 family. See ARM DUI 0541C. | |
| 54 | + items: | |
| 55 | + - const: arm,vexpress,v2p-ca5s | |
| 56 | + - const: arm,vexpress | |
| 57 | + - description: Coretile Express A15x2 (V2P-CA15) has 2 Cortex A15 CPU | |
| 58 | + cores in a MPCore configuration in a test chip on the core tile. See | |
| 59 | + ARM DUI 0604F. | |
| 60 | + items: | |
| 61 | + - const: arm,vexpress,v2p-ca15 | |
| 62 | + - const: arm,vexpress | |
| 63 | + - description: CoreTile Express A15x4 (V2P-CA15, HBI-0237A) has 4 Cortex | |
| 64 | + A15 CPU cores in a test chip on the core tile. This is the first test | |
| 65 | + chip called "TC1". | |
| 66 | + items: | |
| 67 | + - const: arm,vexpress,v2p-ca15,tc1 | |
| 68 | + - const: arm,vexpress,v2p-ca15 | |
| 69 | + - const: arm,vexpress | |
| 70 | + - description: Coretile Express A15x2 A7x3 (V2P-CA15_A7) has 2 Cortex A15 | |
| 71 | + CPU cores and 3 Cortex A7 cores in a big.LITTLE MPCore configuration | |
| 72 | + in a test chip on the core tile. See ARM DDI 0503I. | |
| 73 | + items: | |
| 74 | + - const: arm,vexpress,v2p-ca15_a7 | |
| 75 | + - const: arm,vexpress | |
| 76 | + - description: LogicTile Express 20MG (V2F-1XV7) has 2 Cortex A53 CPU | |
| 77 | + cores in a test chip on the core tile. See ARM DDI 0498D. | |
| 78 | + items: | |
| 79 | + - const: arm,vexpress,v2f-1xv7,ca53x2 | |
| 80 | + - const: arm,vexpress,v2f-1xv7 | |
| 81 | + - const: arm,vexpress | |
| 82 | + - description: Arm Versatile Express Juno "r0" (the first Juno board, | |
| 83 | + V2M-Juno) was introduced as a vehicle for evaluating big.LITTLE on | |
| 84 | + AArch64 CPU cores. It has 2 Cortex A57 CPU cores and 4 Cortex A53 | |
| 85 | + cores in a big.LITTLE configuration. It also features the MALI T624 | |
| 86 | + GPU. See ARM document 100113_0000_07_en. | |
| 87 | + items: | |
| 88 | + - const: arm,juno | |
| 89 | + - const: arm,vexpress | |
| 90 | + - description: Arm Versatile Express Juno r1 Development Platform | |
| 91 | + (V2M-Juno r1) was introduced mainly aimed at development of PCIe | |
| 92 | + based systems. Juno r1 also has support for AXI masters placed on | |
| 93 | + the TLX connectors to join the coherency domain. Otherwise it is the | |
| 94 | + same configuration as Juno r0. See ARM document 100122_0100_06_en. | |
| 95 | + items: | |
| 96 | + - const: arm,juno-r1 | |
| 97 | + - const: arm,juno | |
| 98 | + - const: arm,vexpress | |
| 99 | + - description: Arm Versatile Express Juno r2 Development Platform | |
| 100 | + (V2M-Juno r2). It has the same feature set as Juno r0 and r1. See | |
| 101 | + ARM document 100114_0200_04_en. | |
| 102 | + items: | |
| 103 | + - const: arm,juno-r2 | |
| 104 | + - const: arm,juno | |
| 105 | + - const: arm,vexpress | |
| 106 | + - description: Arm AEMv8a Versatile Express Real-Time System Model | |
| 107 | + (VE RTSM) is a programmers view of the Versatile Express with Arm | |
| 108 | + v8A hardware. See ARM DUI 0575D. | |
| 109 | + items: | |
| 110 | + - const: arm,rtsm_ve,aemv8a | |
| 111 | + - const: arm,vexpress | |
| 112 | + - description: Arm FVP (Fixed Virtual Platform) base model revision C | |
| 113 | + See ARM Document 100964_1190_00_en. | |
| 114 | + items: | |
| 115 | + - const: arm,fvp-base-revc | |
| 116 | + - const: arm,vexpress | |
| 117 | + - description: Arm Foundation model for Aarch64 | |
| 118 | + items: | |
| 119 | + - const: arm,foundation-aarch64 | |
| 120 | + - const: arm,vexpress | |
| 121 | + | |
| 122 | + arm,hbi: | |
| 123 | + $ref: '/schemas/types.yaml#/definitions/uint32' | |
| 124 | + description: This indicates the ARM HBI (Hardware Board ID), this is | |
| 125 | + ARM's unique board model ID, visible on the PCB's silkscreen. | |
| 126 | + | |
| 127 | + arm,vexpress,site: | |
| 128 | + description: As Versatile Express can be configured in number of physically | |
| 129 | + different setups, the device tree should describe platform topology. | |
| 130 | + For this reason the root node and main motherboard node must define this | |
| 131 | + property, describing the physical location of the children nodes. | |
| 132 | + 0 means motherboard site, while 1 and 2 are daughterboard sites, and | |
| 133 | + 0xf means "sisterboard" which is the site containing the main CPU tile. | |
| 134 | + allOf: | |
| 135 | + - $ref: '/schemas/types.yaml#/definitions/uint32' | |
| 136 | + - minimum: 0 | |
| 137 | + maximum: 15 | |
| 138 | + | |
| 139 | + arm,vexpress,position: | |
| 140 | + description: When daughterboards are stacked on one site, their position | |
| 141 | + in the stack be be described this attribute. | |
| 142 | + allOf: | |
| 143 | + - $ref: '/schemas/types.yaml#/definitions/uint32' | |
| 144 | + - minimum: 0 | |
| 145 | + maximum: 3 | |
| 146 | + | |
| 147 | + arm,vexpress,dcc: | |
| 148 | + description: When describing tiles consisting of more than one DCC, its | |
| 149 | + number can be specified with this attribute. | |
| 150 | + allOf: | |
| 151 | + - $ref: '/schemas/types.yaml#/definitions/uint32' | |
| 152 | + - minimum: 0 | |
| 153 | + maximum: 3 | |
| 154 | + | |
| 155 | +patternProperties: | |
| 156 | + "^bus@[0-9a-f]+$": | |
| 157 | + description: Static Memory Bus (SMB) node, if this exists it describes | |
| 158 | + the connection between the motherboard and any tiles. Sometimes the | |
| 159 | + compatible is placed directly under this node, sometimes it is placed | |
| 160 | + in a subnode named "motherboard". Sometimes the compatible includes | |
| 161 | + "arm,vexpress,v2?-p1" sometimes (on software models) is is just | |
| 162 | + "simple-bus". If the compatible is placed in the "motherboard" node, | |
| 163 | + it is stricter and always has two compatibles. | |
| 164 | + type: object | |
| 165 | + allOf: | |
| 166 | + - $ref: '/schemas/simple-bus.yaml' | |
| 167 | + | |
| 168 | + properties: | |
| 169 | + compatible: | |
| 170 | + oneOf: | |
| 171 | + - items: | |
| 172 | + - enum: | |
| 173 | + - arm,vexpress,v2m-p1 | |
| 174 | + - arm,vexpress,v2p-p1 | |
| 175 | + - const: simple-bus | |
| 176 | + - const: simple-bus | |
| 177 | + motherboard: | |
| 178 | + type: object | |
| 179 | + description: The motherboard description provides a single "motherboard" | |
| 180 | + node using 2 address cells corresponding to the Static Memory Bus | |
| 181 | + used between the motherboard and the tile. The first cell defines the | |
| 182 | + Chip Select (CS) line number, the second cell address offset within | |
| 183 | + the CS. All interrupt lines between the motherboard and the tile | |
| 184 | + are active high and are described using single cell. | |
| 185 | + properties: | |
| 186 | + "#address-cells": | |
| 187 | + const: 2 | |
| 188 | + "#size-cells": | |
| 189 | + const: 1 | |
| 190 | + compatible: | |
| 191 | + items: | |
| 192 | + - enum: | |
| 193 | + - arm,vexpress,v2m-p1 | |
| 194 | + - arm,vexpress,v2p-p1 | |
| 195 | + - const: simple-bus | |
| 196 | + arm,v2m-memory-map: | |
| 197 | + description: This describes the memory map type. | |
| 198 | + allOf: | |
| 199 | + - $ref: '/schemas/types.yaml#/definitions/string' | |
| 200 | + - enum: | |
| 201 | + - rs1 | |
| 202 | + - rs2 | |
| 203 | + required: | |
| 204 | + - compatible | |
| 205 | + required: | |
| 206 | + - compatible | |
| 207 | + | |
| 208 | +allOf: | |
| 209 | + - if: | |
| 210 | + properties: | |
| 211 | + compatible: | |
| 212 | + contains: | |
| 213 | + enum: | |
| 214 | + - arm,vexpress,v2p-ca9 | |
| 215 | + - arm,vexpress,v2p-ca5s | |
| 216 | + - arm,vexpress,v2p-ca15 | |
| 217 | + - arm,vexpress,v2p-ca15_a7 | |
| 218 | + - arm,vexpress,v2f-1xv7,ca53x2 | |
| 219 | + then: | |
| 220 | + required: | |
| 221 | + - arm,hbi | |
| 222 | + | |
| 223 | +... | |
| @@ -1,237 +0,0 @@ | ||
| 1 | −ARM Integrator/AP (Application Platform) and Integrator/CP (Compact Platform) | |
| 2 | −----------------------------------------------------------------------------- | |
| 3 | −ARM's oldest Linux-supported platform with connectors for different core | |
| 4 | −tiles of ARMv4, ARMv5 and ARMv6 type. | |
| 5 | − | |
| 6 | −Required properties (in root node): | |
| 7 | − compatible = "arm,integrator-ap"; /* Application Platform */ | |
| 8 | − compatible = "arm,integrator-cp"; /* Compact Platform */ | |
| 9 | − | |
| 10 | −FPGA type interrupt controllers, see the versatile-fpga-irq binding doc. | |
| 11 | − | |
| 12 | −Required nodes: | |
| 13 | − | |
| 14 | −- core-module: the root node to the Integrator platforms must have | |
| 15 | − a core-module with regs and the compatible string | |
| 16 | − "arm,core-module-integrator" | |
| 17 | −- external-bus-interface: the root node to the Integrator platforms | |
| 18 | − must have an external bus interface with regs and the | |
| 19 | − compatible-string "arm,external-bus-interface" | |
| 20 | − | |
| 21 | − Required properties for the core module: | |
| 22 | − - regs: the location and size of the core module registers, one | |
| 23 | − range of 0x200 bytes. | |
| 24 | − | |
| 25 | −- syscon: the root node of the Integrator platforms must have a | |
| 26 | − system controller node pointing to the control registers, | |
| 27 | − with the compatible string | |
| 28 | − "arm,integrator-ap-syscon" | |
| 29 | − "arm,integrator-cp-syscon" | |
| 30 | − respectively. | |
| 31 | − | |
| 32 | − Required properties for the system controller: | |
| 33 | − - regs: the location and size of the system controller registers, | |
| 34 | − one range of 0x100 bytes. | |
| 35 | − | |
| 36 | − Required properties for the AP system controller: | |
| 37 | − - interrupts: the AP syscon node must include the logical module | |
| 38 | − interrupts, stated in order of module instance <module 0>, | |
| 39 | − <module 1>, <module 2> ... for the CP system controller this | |
| 40 | − is not required not of any use. | |
| 41 | − | |
| 42 | −/dts-v1/; | |
| 43 | −/include/ "integrator.dtsi" | |
| 44 | − | |
| 45 | −/ { | |
| 46 | − model = "ARM Integrator/AP"; | |
| 47 | − compatible = "arm,integrator-ap"; | |
| 48 | − | |
| 49 | − core-module@10000000 { | |
| 50 | − compatible = "arm,core-module-integrator"; | |
| 51 | − reg = <0x10000000 0x200>; | |
| 52 | − }; | |
| 53 | − | |
| 54 | − ebi@12000000 { | |
| 55 | − compatible = "arm,external-bus-interface"; | |
| 56 | − reg = <0x12000000 0x100>; | |
| 57 | − }; | |
| 58 | − | |
| 59 | − syscon { | |
| 60 | − compatible = "arm,integrator-ap-syscon"; | |
| 61 | − reg = <0x11000000 0x100>; | |
| 62 | − interrupt-parent = <&pic>; | |
| 63 | − /* These are the logic module IRQs */ | |
| 64 | − interrupts = <9>, <10>, <11>, <12>; | |
| 65 | − }; | |
| 66 | −}; | |
| 67 | − | |
| 68 | − | |
| 69 | −ARM Versatile Application and Platform Baseboards | |
| 70 | −------------------------------------------------- | |
| 71 | −ARM's development hardware platform with connectors for customizable | |
| 72 | −core tiles. The hardware configuration of the Versatile boards is | |
| 73 | −highly customizable. | |
| 74 | − | |
| 75 | −Required properties (in root node): | |
| 76 | − compatible = "arm,versatile-ab"; /* Application baseboard */ | |
| 77 | − compatible = "arm,versatile-pb"; /* Platform baseboard */ | |
| 78 | − | |
| 79 | −Interrupt controllers: | |
| 80 | −- VIC required properties: | |
| 81 | − compatible = "arm,versatile-vic"; | |
| 82 | − interrupt-controller; | |
| 83 | − #interrupt-cells = <1>; | |
| 84 | − | |
| 85 | −- SIC required properties: | |
| 86 | − compatible = "arm,versatile-sic"; | |
| 87 | − interrupt-controller; | |
| 88 | − #interrupt-cells = <1>; | |
| 89 | − | |
| 90 | −Required nodes: | |
| 91 | − | |
| 92 | −- core-module: the root node to the Versatile platforms must have | |
| 93 | − a core-module with regs and the compatible strings | |
| 94 | − "arm,core-module-versatile", "syscon" | |
| 95 | − | |
| 96 | −Optional nodes: | |
| 97 | − | |
| 98 | −- arm,versatile-ib2-syscon : if the Versatile has an IB2 interface | |
| 99 | − board mounted, this has a separate system controller that is | |
| 100 | − defined in this node. | |
| 101 | − Required properties: | |
| 102 | − compatible = "arm,versatile-ib2-syscon", "syscon" | |
| 103 | − | |
| 104 | −ARM RealView Boards | |
| 105 | −------------------- | |
| 106 | −The RealView boards cover tailored evaluation boards that are used to explore | |
| 107 | −the ARM11 and Cortex A-8 and Cortex A-9 processors. | |
| 108 | − | |
| 109 | −Required properties (in root node): | |
| 110 | − /* RealView Emulation Baseboard */ | |
| 111 | − compatible = "arm,realview-eb"; | |
| 112 | − /* RealView Platform Baseboard for ARM1176JZF-S */ | |
| 113 | − compatible = "arm,realview-pb1176"; | |
| 114 | − /* RealView Platform Baseboard for ARM11 MPCore */ | |
| 115 | − compatible = "arm,realview-pb11mp"; | |
| 116 | − /* RealView Platform Baseboard for Cortex A-8 */ | |
| 117 | − compatible = "arm,realview-pba8"; | |
| 118 | − /* RealView Platform Baseboard Explore for Cortex A-9 */ | |
| 119 | − compatible = "arm,realview-pbx"; | |
| 120 | − | |
| 121 | −Required nodes: | |
| 122 | − | |
| 123 | −- soc: some node of the RealView platforms must be the SoC | |
| 124 | − node that contain the SoC-specific devices, with the compatible | |
| 125 | − string set to one of these tuples: | |
| 126 | − "arm,realview-eb-soc", "simple-bus" | |
| 127 | − "arm,realview-pb1176-soc", "simple-bus" | |
| 128 | − "arm,realview-pb11mp-soc", "simple-bus" | |
| 129 | − "arm,realview-pba8-soc", "simple-bus" | |
| 130 | − "arm,realview-pbx-soc", "simple-bus" | |
| 131 | − | |
| 132 | −- syscon: some subnode of the RealView SoC node must be a | |
| 133 | − system controller node pointing to the control registers, | |
| 134 | − with the compatible string set to one of these: | |
| 135 | − "arm,realview-eb11mp-revb-syscon", "arm,realview-eb-syscon", "syscon" | |
| 136 | − "arm,realview-eb11mp-revc-syscon", "arm,realview-eb-syscon", "syscon" | |
| 137 | − "arm,realview-eb-syscon", "syscon" | |
| 138 | − "arm,realview-pb1176-syscon", "syscon" | |
| 139 | − "arm,realview-pb11mp-syscon", "syscon" | |
| 140 | − "arm,realview-pba8-syscon", "syscon" | |
| 141 | − "arm,realview-pbx-syscon", "syscon" | |
| 142 | − | |
| 143 | − Required properties for the system controller: | |
| 144 | − - regs: the location and size of the system controller registers, | |
| 145 | − one range of 0x1000 bytes. | |
| 146 | − | |
| 147 | −Example: | |
| 148 | − | |
| 149 | −/dts-v1/; | |
| 150 | −#include <dt-bindings/interrupt-controller/irq.h> | |
| 151 | − | |
| 152 | −/ { | |
| 153 | − model = "ARM RealView PB1176 with device tree"; | |
| 154 | − compatible = "arm,realview-pb1176"; | |
| 155 | − #address-cells = <1>; | |
| 156 | − #size-cells = <1>; | |
| 157 | − | |
| 158 | − soc { | |
| 159 | − #address-cells = <1>; | |
| 160 | − #size-cells = <1>; | |
| 161 | − compatible = "arm,realview-pb1176-soc", "simple-bus"; | |
| 162 | − ranges; | |
| 163 | − | |
| 164 | − syscon: syscon@10000000 { | |
| 165 | − compatible = "arm,realview-syscon", "syscon"; | |
| 166 | − reg = <0x10000000 0x1000>; | |
| 167 | − }; | |
| 168 | − | |
| 169 | − }; | |
| 170 | −}; | |
| 171 | − | |
| 172 | −ARM Versatile Express Boards | |
| 173 | −----------------------------- | |
| 174 | −For details on the device tree bindings for ARM Versatile Express boards | |
| 175 | −please consult the vexpress.txt file in the same directory as this file. | |
| 176 | − | |
| 177 | −ARM Juno Boards | |
| 178 | −---------------- | |
| 179 | −The Juno boards are targeting development for AArch64 systems. The first | |
| 180 | −iteration, Juno r0, is a vehicle for evaluating big.LITTLE on AArch64, | |
| 181 | −with the second iteration, Juno r1, mainly aimed at development of PCIe | |
| 182 | −based systems. Juno r1 also has support for AXI masters placed on the TLX | |
| 183 | −connectors to join the coherency domain. | |
| 184 | − | |
| 185 | −Juno boards are described in a similar way to ARM Versatile Express boards, | |
| 186 | −with the motherboard part of the hardware being described in a separate file | |
| 187 | −to highlight the fact that is part of the support infrastructure for the SoC. | |
| 188 | −Juno device tree bindings also share the Versatile Express bindings as | |
| 189 | −described under the RS1 memory mapping. | |
| 190 | − | |
| 191 | −Required properties (in root node): | |
| 192 | − compatible = "arm,juno"; /* For Juno r0 board */ | |
| 193 | − compatible = "arm,juno-r1"; /* For Juno r1 board */ | |
| 194 | − compatible = "arm,juno-r2"; /* For Juno r2 board */ | |
| 195 | − | |
| 196 | −Required nodes: | |
| 197 | −The description for the board must include: | |
| 198 | − - a "psci" node describing the boot method used for the secondary CPUs. | |
| 199 | − A detailed description of the bindings used for "psci" nodes is present | |
| 200 | − in the psci.yaml file. | |
| 201 | − - a "cpus" node describing the available cores and their associated | |
| 202 | − "enable-method"s. For more details see cpus.yaml file. | |
| 203 | − | |
| 204 | −Example: | |
| 205 | − | |
| 206 | −/dts-v1/; | |
| 207 | −/ { | |
| 208 | − model = "ARM Juno development board (r0)"; | |
| 209 | − compatible = "arm,juno", "arm,vexpress"; | |
| 210 | − interrupt-parent = <&gic>; | |
| 211 | − #address-cells = <2>; | |
| 212 | − #size-cells = <2>; | |
| 213 | − | |
| 214 | − cpus { | |
| 215 | − #address-cells = <2>; | |
| 216 | − #size-cells = <0>; | |
| 217 | − | |
| 218 | − A57_0: cpu@0 { | |
| 219 | − compatible = "arm,cortex-a57"; | |
| 220 | − reg = <0x0 0x0>; | |
| 221 | − device_type = "cpu"; | |
| 222 | − enable-method = "psci"; | |
| 223 | − }; | |
| 224 | − | |
| 225 | − ..... | |
| 226 | − | |
| 227 | − A53_0: cpu@100 { | |
| 228 | − compatible = "arm,cortex-a53"; | |
| 229 | − reg = <0x0 0x100>; | |
| 230 | − device_type = "cpu"; | |
| 231 | − enable-method = "psci"; | |
| 232 | − }; | |
| 233 | − | |
| 234 | − ..... | |
| 235 | − }; | |
| 236 | − | |
| 237 | −}; | |
| @@ -1,36 +0,0 @@ | ||
| 1 | −Broadcom Kona Family CPU Enable Method | |
| 2 | −-------------------------------------- | |
| 3 | −This binding defines the enable method used for starting secondary | |
| 4 | −CPUs in the following Broadcom SoCs: | |
| 5 | − BCM11130, BCM11140, BCM11351, BCM28145, BCM28155, BCM21664 | |
| 6 | − | |
| 7 | −The enable method is specified by defining the following required | |
| 8 | −properties in the "cpu" device tree node: | |
| 9 | − - enable-method = "brcm,bcm11351-cpu-method"; | |
| 10 | − - secondary-boot-reg = <...>; | |
| 11 | − | |
| 12 | −The secondary-boot-reg property is a u32 value that specifies the | |
| 13 | −physical address of the register used to request the ROM holding pen | |
| 14 | −code release a secondary CPU. The value written to the register is | |
| 15 | −formed by encoding the target CPU id into the low bits of the | |
| 16 | −physical start address it should jump to. | |
| 17 | − | |
| 18 | −Example: | |
| 19 | − cpus { | |
| 20 | − #address-cells = <1>; | |
| 21 | − #size-cells = <0>; | |
| 22 | − | |
| 23 | − cpu0: cpu@0 { | |
| 24 | − device_type = "cpu"; | |
| 25 | − compatible = "arm,cortex-a9"; | |
| 26 | − reg = <0>; | |
| 27 | − }; | |
| 28 | − | |
| 29 | − cpu1: cpu@1 { | |
| 30 | − device_type = "cpu"; | |
| 31 | − compatible = "arm,cortex-a9"; | |
| 32 | − reg = <1>; | |
| 33 | − enable-method = "brcm,bcm11351-cpu-method"; | |
| 34 | − secondary-boot-reg = <0x3500417c>; | |
| 35 | − }; | |
| 36 | − }; | |
| @@ -1,10 +0,0 @@ | ||
| 1 | −Broadcom BCM11351 device tree bindings | |
| 2 | −------------------------------------------- | |
| 3 | − | |
| 4 | −Boards with the bcm281xx SoC family (which includes bcm11130, bcm11140, | |
| 5 | −bcm11351, bcm28145, bcm28155 SoCs) shall have the following properties: | |
| 6 | − | |
| 7 | −Required root node property: | |
| 8 | − | |
| 9 | −compatible = "brcm,bcm11351"; | |
| 10 | −DEPRECATED: compatible = "bcm,bcm11351"; | |
| @@ -0,0 +1,21 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm11351.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Broadcom BCM11351 device tree bindings | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Florian Fainelli <f.fainelli@gmail.com> | |
| 11 | + | |
| 12 | +properties: | |
| 13 | + $nodename: | |
| 14 | + const: '/' | |
| 15 | + compatible: | |
| 16 | + items: | |
| 17 | + - enum: | |
| 18 | + - brcm,bcm28155-ap | |
| 19 | + - const: brcm,bcm11351 | |
| 20 | + | |
| 21 | +... | |
| @@ -1,15 +0,0 @@ | ||
| 1 | −Broadcom BCM21664 device tree bindings | |
| 2 | −-------------------------------------- | |
| 3 | − | |
| 4 | −This document describes the device tree bindings for boards with the BCM21664 | |
| 5 | −SoC. | |
| 6 | − | |
| 7 | −Required root node property: | |
| 8 | − - compatible: brcm,bcm21664 | |
| 9 | − | |
| 10 | −Example: | |
| 11 | − / { | |
| 12 | − model = "BCM21664 SoC"; | |
| 13 | − compatible = "brcm,bcm21664"; | |
| 14 | − [...] | |
| 15 | − } | |
| @@ -0,0 +1,21 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm21664.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Broadcom BCM21664 device tree bindings | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Florian Fainelli <f.fainelli@gmail.com> | |
| 11 | + | |
| 12 | +properties: | |
| 13 | + $nodename: | |
| 14 | + const: '/' | |
| 15 | + compatible: | |
| 16 | + items: | |
| 17 | + - enum: | |
| 18 | + - brcm,bcm21664-garnet | |
| 19 | + - const: brcm,bcm21664 | |
| 20 | + | |
| 21 | +... | |
| @@ -1,36 +0,0 @@ | ||
| 1 | −Broadcom Kona Family CPU Enable Method | |
| 2 | −-------------------------------------- | |
| 3 | −This binding defines the enable method used for starting secondary | |
| 4 | −CPUs in the following Broadcom SoCs: | |
| 5 | − BCM23550 | |
| 6 | − | |
| 7 | −The enable method is specified by defining the following required | |
| 8 | −properties in the "cpu" device tree node: | |
| 9 | − - enable-method = "brcm,bcm23550"; | |
| 10 | − - secondary-boot-reg = <...>; | |
| 11 | − | |
| 12 | −The secondary-boot-reg property is a u32 value that specifies the | |
| 13 | −physical address of the register used to request the ROM holding pen | |
| 14 | −code release a secondary CPU. The value written to the register is | |
| 15 | −formed by encoding the target CPU id into the low bits of the | |
| 16 | −physical start address it should jump to. | |
| 17 | − | |
| 18 | −Example: | |
| 19 | − cpus { | |
| 20 | − #address-cells = <1>; | |
| 21 | − #size-cells = <0>; | |
| 22 | − | |
| 23 | − cpu0: cpu@0 { | |
| 24 | − device_type = "cpu"; | |
| 25 | − compatible = "arm,cortex-a9"; | |
| 26 | − reg = <0>; | |
| 27 | − }; | |
| 28 | − | |
| 29 | − cpu1: cpu@1 { | |
| 30 | − device_type = "cpu"; | |
| 31 | − compatible = "arm,cortex-a9"; | |
| 32 | − reg = <1>; | |
| 33 | − enable-method = "brcm,bcm23550"; | |
| 34 | − secondary-boot-reg = <0x3500417c>; | |
| 35 | − }; | |
| 36 | − }; | |
| @@ -1,15 +0,0 @@ | ||
| 1 | −Broadcom BCM23550 device tree bindings | |
| 2 | −-------------------------------------- | |
| 3 | − | |
| 4 | −This document describes the device tree bindings for boards with the BCM23550 | |
| 5 | −SoC. | |
| 6 | − | |
| 7 | −Required root node property: | |
| 8 | − - compatible: brcm,bcm23550 | |
| 9 | − | |
| 10 | −Example: | |
| 11 | − / { | |
| 12 | − model = "BCM23550 SoC"; | |
| 13 | − compatible = "brcm,bcm23550"; | |
| 14 | − [...] | |
| 15 | − } | |
| @@ -0,0 +1,21 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm23550.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Broadcom BCM23550 device tree bindings | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Florian Fainelli <f.fainelli@gmail.com> | |
| 11 | + | |
| 12 | +properties: | |
| 13 | + $nodename: | |
| 14 | + const: '/' | |
| 15 | + compatible: | |
| 16 | + items: | |
| 17 | + - enum: | |
| 18 | + - brcm,bcm23550-sparrow | |
| 19 | + - const: brcm,bcm23550 | |
| 20 | + | |
| 21 | +... | |
| @@ -1,15 +0,0 @@ | ||
| 1 | −Broadcom BCM4708 device tree bindings | |
| 2 | −------------------------------------------- | |
| 3 | − | |
| 4 | −Boards with the BCM4708 SoC shall have the following properties: | |
| 5 | − | |
| 6 | −Required root node property: | |
| 7 | − | |
| 8 | −bcm4708 | |
| 9 | −compatible = "brcm,bcm4708"; | |
| 10 | − | |
| 11 | −bcm4709 | |
| 12 | −compatible = "brcm,bcm4709"; | |
| 13 | − | |
| 14 | −bcm53012 | |
| 15 | −compatible = "brcm,bcm53012"; | |
| @@ -0,0 +1,88 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm4708.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Broadcom BCM4708 device tree bindings | |
| 8 | + | |
| 9 | +description: | |
| 10 | + Broadcom BCM4708/47081/4709/47094/53012 Wi-Fi/network SoCs based | |
| 11 | + on the iProc architecture (Northstar). | |
| 12 | + | |
| 13 | +maintainers: | |
| 14 | + - Florian Fainelli <f.fainelli@gmail.com> | |
| 15 | + - Hauke Mehrtens <hauke@hauke-m.de> | |
| 16 | + - Rafal Milecki <zajec5@gmail.com> | |
| 17 | + | |
| 18 | +properties: | |
| 19 | + $nodename: | |
| 20 | + const: '/' | |
| 21 | + compatible: | |
| 22 | + oneOf: | |
| 23 | + - description: BCM4708 based boards | |
| 24 | + items: | |
| 25 | + - enum: | |
| 26 | + - asus,rt-ac56u | |
| 27 | + - asus,rt-ac68u | |
| 28 | + - buffalo,wzr-1750dhp | |
| 29 | + - linksys,ea6300-v1 | |
| 30 | + - linksys,ea6500-v2 | |
| 31 | + - luxul,xap-1510v1 | |
| 32 | + - luxul,xwc-1000 | |
| 33 | + - netgear,r6250v1 | |
| 34 | + - netgear,r6300v2 | |
| 35 | + - smartrg,sr400ac | |
| 36 | + - brcm,bcm94708 | |
| 37 | + - const: brcm,bcm4708 | |
| 38 | + | |
| 39 | + - description: BCM47081 based boards | |
| 40 | + items: | |
| 41 | + - enum: | |
| 42 | + - asus,rt-n18u | |
| 43 | + - buffalo,wzr-600dhp2 | |
| 44 | + - buffalo,wzr-900dhp | |
| 45 | + - luxul,xap-1410v1 | |
| 46 | + - luxul,xwr-1200v1 | |
| 47 | + - tplink,archer-c5-v2 | |
| 48 | + - const: brcm,bcm47081 | |
| 49 | + - const: brcm,bcm4708 | |
| 50 | + | |
| 51 | + - description: BCM4709 based boards | |
| 52 | + items: | |
| 53 | + - enum: | |
| 54 | + - asus,rt-ac87u | |
| 55 | + - buffalo,wxr-1900dhp | |
| 56 | + - linksys,ea9200 | |
| 57 | + - netgear,r7000 | |
| 58 | + - netgear,r8000 | |
| 59 | + - tplink,archer-c9-v1 | |
| 60 | + - brcm,bcm94709 | |
| 61 | + - const: brcm,bcm4709 | |
| 62 | + - const: brcm,bcm4708 | |
| 63 | + | |
| 64 | + - description: BCM47094 based boards | |
| 65 | + items: | |
| 66 | + - enum: | |
| 67 | + - dlink,dir-885l | |
| 68 | + - linksys,panamera | |
| 69 | + - luxul,abr-4500-v1 | |
| 70 | + - luxul,xap-1610-v1 | |
| 71 | + - luxul,xbr-4500-v1 | |
| 72 | + - luxul,xwc-2000-v1 | |
| 73 | + - luxul,xwr-3100v1 | |
| 74 | + - luxul,xwr-3150-v1 | |
| 75 | + - netgear,r8500 | |
| 76 | + - phicomm,k3 | |
| 77 | + - const: brcm,bcm47094 | |
| 78 | + - const: brcm,bcm4708 | |
| 79 | + | |
| 80 | + - description: BCM53012 based boards | |
| 81 | + items: | |
| 82 | + - enum: | |
| 83 | + - brcm,bcm953012er | |
| 84 | + - brcm,bcm953012hr | |
| 85 | + - brcm,bcm953012k | |
| 86 | + - const: brcm,brcm53012 | |
| 87 | + - const: brcm,bcm4708 | |
| 88 | +... | |
| @@ -1,31 +0,0 @@ | ||
| 1 | −Broadcom Cygnus device tree bindings | |
| 2 | −------------------------------------ | |
| 3 | − | |
| 4 | − | |
| 5 | −Boards with Cygnus SoCs shall have the following properties: | |
| 6 | − | |
| 7 | −Required root node property: | |
| 8 | − | |
| 9 | −BCM11300 | |
| 10 | −compatible = "brcm,bcm11300", "brcm,cygnus"; | |
| 11 | − | |
| 12 | −BCM11320 | |
| 13 | −compatible = "brcm,bcm11320", "brcm,cygnus"; | |
| 14 | − | |
| 15 | −BCM11350 | |
| 16 | −compatible = "brcm,bcm11350", "brcm,cygnus"; | |
| 17 | − | |
| 18 | −BCM11360 | |
| 19 | −compatible = "brcm,bcm11360", "brcm,cygnus"; | |
| 20 | − | |
| 21 | −BCM58300 | |
| 22 | −compatible = "brcm,bcm58300", "brcm,cygnus"; | |
| 23 | − | |
| 24 | −BCM58302 | |
| 25 | −compatible = "brcm,bcm58302", "brcm,cygnus"; | |
| 26 | − | |
| 27 | −BCM58303 | |
| 28 | −compatible = "brcm,bcm58303", "brcm,cygnus"; | |
| 29 | − | |
| 30 | −BCM58305 | |
| 31 | −compatible = "brcm,bcm58305", "brcm,cygnus"; | |
| @@ -0,0 +1,29 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/arm/bcm/brcm,cygnus.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Broadcom Cygnus device tree bindings | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Ray Jui <rjui@broadcom.com> | |
| 11 | + - Scott Branden <sbranden@broadcom.com> | |
| 12 | + | |
| 13 | +properties: | |
| 14 | + $nodename: | |
| 15 | + const: '/' | |
| 16 | + compatible: | |
| 17 | + items: | |
| 18 | + - enum: | |
| 19 | + - brcm,bcm11300 | |
| 20 | + - brcm,bcm11320 | |
| 21 | + - brcm,bcm11350 | |
| 22 | + - brcm,bcm11360 | |
| 23 | + - brcm,bcm58300 | |
| 24 | + - brcm,bcm58302 | |
| 25 | + - brcm,bcm58303 | |
| 26 | + - brcm,bcm58305 | |
| 27 | + - const: brcm,cygnus | |
| 28 | + | |
| 29 | +... | |
| @@ -1,14 +0,0 @@ | ||
| 1 | −Broadcom Hurricane 2 device tree bindings | |
| 2 | −--------------------------------------- | |
| 3 | − | |
| 4 | −Broadcom Hurricane 2 family of SoCs are used for switching control. These SoCs | |
| 5 | −are based on Broadcom's iProc SoC architecture and feature a single core Cortex | |
| 6 | −A9 ARM CPUs, DDR2/DDR3 memory, PCIe GEN-2, USB 2.0 and USB 3.0, serial and NAND | |
| 7 | −flash and a PCIe attached integrated switching engine. | |
| 8 | − | |
| 9 | −Boards with Hurricane SoCs shall have the following properties: | |
| 10 | − | |
| 11 | −Required root node property: | |
| 12 | − | |
| 13 | −BCM53342 | |
| 14 | −compatible = "brcm,bcm53342", "brcm,hr2"; | |
| @@ -0,0 +1,28 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/arm/bcm/brcm,hr2.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Broadcom Hurricane 2 device tree bindings | |
| 8 | + | |
| 9 | +description: | |
| 10 | + Broadcom Hurricane 2 family of SoCs are used for switching control. These SoCs | |
| 11 | + are based on Broadcom's iProc SoC architecture and feature a single core Cortex | |
| 12 | + A9 ARM CPUs, DDR2/DDR3 memory, PCIe GEN-2, USB 2.0 and USB 3.0, serial and NAND | |
| 13 | + flash and a PCIe attached integrated switching engine. | |
| 14 | + | |
| 15 | +maintainers: | |
| 16 | + - Florian Fainelli <f.fainelli@gmail.com> | |
| 17 | + | |
| 18 | +properties: | |
| 19 | + $nodename: | |
| 20 | + const: '/' | |
| 21 | + compatible: | |
| 22 | + items: | |
| 23 | + - enum: | |
| 24 | + - ubnt,unifi-switch8 | |
| 25 | + - const: brcm,bcm53342 | |
| 26 | + - const: brcm,hr2 | |
| 27 | + | |
| 28 | +... | |
| @@ -1,9 +0,0 @@ | ||
| 1 | −Broadcom North Star 2 (NS2) device tree bindings | |
| 2 | −------------------------------------------------ | |
| 3 | − | |
| 4 | −Boards with NS2 shall have the following properties: | |
| 5 | − | |
| 6 | −Required root node property: | |
| 7 | − | |
| 8 | −NS2 SVK board | |
| 9 | −compatible = "brcm,ns2-svk", "brcm,ns2"; | |
| @@ -0,0 +1,23 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/arm/bcm/brcm,ns2.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Broadcom North Star 2 (NS2) device tree bindings | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Ray Jui <rjui@broadcom.com> | |
| 11 | + - Scott Branden <sbranden@broadcom.com> | |
| 12 | + | |
| 13 | +properties: | |
| 14 | + $nodename: | |
| 15 | + const: '/' | |
| 16 | + compatible: | |
| 17 | + items: | |
| 18 | + - enum: | |
| 19 | + - brcm,ns2-svk | |
| 20 | + - brcm,ns2-xmc | |
| 21 | + - const: brcm,ns2 | |
| 22 | + | |
| 23 | +... | |
| @@ -1,39 +0,0 @@ | ||
| 1 | −Broadcom Northstar Plus SoC CPU Enable Method | |
| 2 | −--------------------------------------------- | |
| 3 | −This binding defines the enable method used for starting secondary | |
| 4 | −CPU in the following Broadcom SoCs: | |
| 5 | − BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312 | |
| 6 | − | |
| 7 | −The enable method is specified by defining the following required | |
| 8 | −properties in the corresponding secondary "cpu" device tree node: | |
| 9 | − - enable-method = "brcm,bcm-nsp-smp"; | |
| 10 | − - secondary-boot-reg = <...>; | |
| 11 | − | |
| 12 | −The secondary-boot-reg property is a u32 value that specifies the | |
| 13 | −physical address of the register which should hold the common | |
| 14 | −entry point for a secondary CPU. This entry is cpu node specific | |
| 15 | −and should be added per cpu. E.g., in case of NSP (BCM58625) which | |
| 16 | −is a dual core CPU SoC, this entry should be added to cpu1 node. | |
| 17 | − | |
| 18 | − | |
| 19 | −Example: | |
| 20 | − cpus { | |
| 21 | − #address-cells = <1>; | |
| 22 | − #size-cells = <0>; | |
| 23 | − | |
| 24 | − cpu0: cpu@0 { | |
| 25 | − device_type = "cpu"; | |
| 26 | − compatible = "arm,cortex-a9"; | |
| 27 | − next-level-cache = <&L2>; | |
| 28 | − reg = <0>; | |
| 29 | − }; | |
| 30 | − | |
| 31 | − cpu1: cpu@1 { | |
| 32 | − device_type = "cpu"; | |
| 33 | − compatible = "arm,cortex-a9"; | |
| 34 | − next-level-cache = <&L2>; | |
| 35 | − enable-method = "brcm,bcm-nsp-smp"; | |
| 36 | − secondary-boot-reg = <0xffff042c>; | |
| 37 | − reg = <1>; | |
| 38 | − }; | |
| 39 | − }; | |
| @@ -1,34 +0,0 @@ | ||
| 1 | −Broadcom Northstar Plus device tree bindings | |
| 2 | −-------------------------------------------- | |
| 3 | − | |
| 4 | −Broadcom Northstar Plus family of SoCs are used for switching control | |
| 5 | −and management applications as well as residential router/gateway | |
| 6 | −applications. The SoC features dual core Cortex A9 ARM CPUs, integrating | |
| 7 | −several peripheral interfaces including multiple Gigabit Ethernet PHYs, | |
| 8 | −DDR3 memory, PCIE Gen-2, USB 2.0 and USB 3.0, serial and NAND flash, | |
| 9 | −SATA and several other IO controllers. | |
| 10 | − | |
| 11 | −Boards with Northstar Plus SoCs shall have the following properties: | |
| 12 | − | |
| 13 | −Required root node property: | |
| 14 | − | |
| 15 | −BCM58522 | |
| 16 | −compatible = "brcm,bcm58522", "brcm,nsp"; | |
| 17 | − | |
| 18 | −BCM58525 | |
| 19 | −compatible = "brcm,bcm58525", "brcm,nsp"; | |
| 20 | − | |
| 21 | −BCM58535 | |
| 22 | −compatible = "brcm,bcm58535", "brcm,nsp"; | |
| 23 | − | |
| 24 | −BCM58622 | |
| 25 | −compatible = "brcm,bcm58622", "brcm,nsp"; | |
| 26 | − | |
| 27 | −BCM58623 | |
| 28 | −compatible = "brcm,bcm58623", "brcm,nsp"; | |
| 29 | − | |
| 30 | −BCM58625 | |
| 31 | −compatible = "brcm,bcm58625", "brcm,nsp"; | |
| 32 | − | |
| 33 | −BCM88312 | |
| 34 | −compatible = "brcm,bcm88312", "brcm,nsp"; | |
| @@ -0,0 +1,36 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/arm/bcm/brcm,nsp.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Broadcom Northstar Plus device tree bindings | |
| 8 | + | |
| 9 | +description: | |
| 10 | + Broadcom Northstar Plus family of SoCs are used for switching control | |
| 11 | + and management applications as well as residential router/gateway | |
| 12 | + applications. The SoC features dual core Cortex A9 ARM CPUs, integrating | |
| 13 | + several peripheral interfaces including multiple Gigabit Ethernet PHYs, | |
| 14 | + DDR3 memory, PCIE Gen-2, USB 2.0 and USB 3.0, serial and NAND flash, | |
| 15 | + SATA and several other IO controllers. | |
| 16 | + | |
| 17 | +maintainers: | |
| 18 | + - Ray Jui <rjui@broadcom.com> | |
| 19 | + - Scott Branden <sbranden@broadcom.com> | |
| 20 | + | |
| 21 | +properties: | |
| 22 | + $nodename: | |
| 23 | + const: '/' | |
| 24 | + compatible: | |
| 25 | + items: | |
| 26 | + - enum: | |
| 27 | + - brcm,bcm58522 | |
| 28 | + - brcm,bcm58525 | |
| 29 | + - brcm,bcm58535 | |
| 30 | + - brcm,bcm58622 | |
| 31 | + - brcm,bcm58623 | |
| 32 | + - brcm,bcm58625 | |
| 33 | + - brcm,bcm88312 | |
| 34 | + - const: brcm,nsp | |
| 35 | + | |
| 36 | +... | |
| @@ -1,12 +0,0 @@ | ||
| 1 | −Broadcom Stingray device tree bindings | |
| 2 | −------------------------------------------------ | |
| 3 | − | |
| 4 | −Boards with Stingray shall have the following properties: | |
| 5 | − | |
| 6 | −Required root node property: | |
| 7 | − | |
| 8 | −Stingray Combo SVK board | |
| 9 | −compatible = "brcm,bcm958742k", "brcm,stingray"; | |
| 10 | − | |
| 11 | −Stingray SST100 board | |
| 12 | −compatible = "brcm,bcm958742t", "brcm,stingray"; | |
| @@ -0,0 +1,24 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/arm/bcm/brcm,stingray.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Broadcom Stingray device tree bindings | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Ray Jui <rjui@broadcom.com> | |
| 11 | + - Scott Branden <sbranden@broadcom.com> | |
| 12 | + | |
| 13 | +properties: | |
| 14 | + $nodename: | |
| 15 | + const: '/' | |
| 16 | + compatible: | |
| 17 | + items: | |
| 18 | + - enum: | |
| 19 | + - brcm,bcm958742k | |
| 20 | + - brcm,bcm958742t | |
| 21 | + - brcm,bcm958802a802x | |
| 22 | + - const: brcm,stingray | |
| 23 | + | |
| 24 | +... | |
| @@ -1,10 +0,0 @@ | ||
| 1 | −Broadcom Vulcan device tree bindings | |
| 2 | −------------------------------------ | |
| 3 | − | |
| 4 | −Boards with Broadcom Vulcan shall have the following root property: | |
| 5 | − | |
| 6 | −Broadcom Vulcan Evaluation Board: | |
| 7 | − compatible = "brcm,vulcan-eval", "brcm,vulcan-soc"; | |
| 8 | − | |
| 9 | −Generic Vulcan board: | |
| 10 | − compatible = "brcm,vulcan-soc"; | |
| @@ -0,0 +1,22 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/arm/bcm/brcm,vulcan-soc.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Broadcom Vulcan device tree bindings | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Robert Richter <rrichter@marvell.com> | |
| 11 | + | |
| 12 | +properties: | |
| 13 | + $nodename: | |
| 14 | + const: '/' | |
| 15 | + compatible: | |
| 16 | + items: | |
| 17 | + - enum: | |
| 18 | + - brcm,vulcan-eval | |
| 19 | + - cavium,thunderx2-cn9900 | |
| 20 | + - const: brcm,vulcan-soc | |
| 21 | + | |
| 22 | +... | |
| @@ -0,0 +1,336 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause | |
| 2 | +# Copyright 2019 Linaro Ltd. | |
| 3 | +%YAML 1.2 | |
| 4 | +--- | |
| 5 | +$id: http://devicetree.org/schemas/arm/coresight-cti.yaml# | |
| 6 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 7 | + | |
| 8 | +title: ARM Coresight Cross Trigger Interface (CTI) device. | |
| 9 | + | |
| 10 | +description: | | |
| 11 | + The CoreSight Embedded Cross Trigger (ECT) consists of CTI devices connected | |
| 12 | + to one or more CoreSight components and/or a CPU, with CTIs interconnected in | |
| 13 | + a star topology via the Cross Trigger Matrix (CTM), which is not programmable. | |
| 14 | + The ECT components are not part of the trace generation data path and are thus | |
| 15 | + not part of the CoreSight graph described in the general CoreSight bindings | |
| 16 | + file coresight.txt. | |
| 17 | + | |
| 18 | + The CTI component properties define the connections between the individual | |
| 19 | + CTI and the components it is directly connected to, consisting of input and | |
| 20 | + output hardware trigger signals. CTIs can have a maximum number of input and | |
| 21 | + output hardware trigger signals (8 each for v1 CTI, 32 each for v2 CTI). The | |
| 22 | + number is defined at design time, the maximum of each defined in the DEVID | |
| 23 | + register. | |
| 24 | + | |
| 25 | + CTIs are interconnected in a star topology via the CTM, using a number of | |
| 26 | + programmable channels, usually 4, but again implementation defined and | |
| 27 | + described in the DEVID register. The star topology is not required to be | |
| 28 | + described in the bindings as the actual connections are software | |
| 29 | + programmable. | |
| 30 | + | |
| 31 | + In general the connections between CTI and components via the trigger signals | |
| 32 | + are implementation defined, except when the CTI is connected to an ARM v8 | |
| 33 | + architecture core and optional ETM. | |
| 34 | + | |
| 35 | + In this case the ARM v8 architecture defines the required signal connections | |
| 36 | + between CTI and the CPU core and ETM if present. In the case of a v8 | |
| 37 | + architecturally connected CTI an additional compatible string is used to | |
| 38 | + indicate this feature (arm,coresight-cti-v8-arch). | |
| 39 | + | |
| 40 | + When CTI trigger connection information is unavailable then a minimal driver | |
| 41 | + binding can be declared with no explicit trigger signals. This will result | |
| 42 | + the driver detecting the maximum available triggers and channels from the | |
| 43 | + DEVID register and make them all available for use as a single default | |
| 44 | + connection. Any user / client application will require additional information | |
| 45 | + on the connections between the CTI and other components for correct operation. | |
| 46 | + This information might be found by enabling the Integration Test registers in | |
| 47 | + the driver (set CONFIG_CORESIGHT_CTI_INTEGRATION_TEST in Kernel | |
| 48 | + configuration). These registers may be used to explore the trigger connections | |
| 49 | + between CTI and other CoreSight components. | |
| 50 | + | |
| 51 | + Certain triggers between CoreSight devices and the CTI have specific types | |
| 52 | + and usages. These can be defined along with the signal indexes with the | |
| 53 | + constants defined in <dt-bindings/arm/coresight-cti-dt.h> | |
| 54 | + | |
| 55 | + For example a CTI connected to a core will usually have a DBGREQ signal. This | |
| 56 | + is defined in the binding as type PE_EDBGREQ. These types will appear in an | |
| 57 | + optional array alongside the signal indexes. Omitting types will default all | |
| 58 | + signals to GEN_IO. | |
| 59 | + | |
| 60 | + Note that some hardware trigger signals can be connected to non-CoreSight | |
| 61 | + components (e.g. UART etc) depending on hardware implementation. | |
| 62 | + | |
| 63 | +maintainers: | |
| 64 | + - Mike Leach <mike.leach@linaro.org> | |
| 65 | + | |
| 66 | +allOf: | |
| 67 | + - $ref: /schemas/arm/primecell.yaml# | |
| 68 | + | |
| 69 | +# Need a custom select here or 'arm,primecell' will match on lots of nodes | |
| 70 | +select: | |
| 71 | + properties: | |
| 72 | + compatible: | |
| 73 | + contains: | |
| 74 | + enum: | |
| 75 | + - arm,coresight-cti | |
| 76 | + required: | |
| 77 | + - compatible | |
| 78 | + | |
| 79 | +properties: | |
| 80 | + $nodename: | |
| 81 | + pattern: "^cti(@[0-9a-f]+)$" | |
| 82 | + compatible: | |
| 83 | + oneOf: | |
| 84 | + - items: | |
| 85 | + - const: arm,coresight-cti | |
| 86 | + - const: arm,primecell | |
| 87 | + - items: | |
| 88 | + - const: arm,coresight-cti-v8-arch | |
| 89 | + - const: arm,coresight-cti | |
| 90 | + - const: arm,primecell | |
| 91 | + | |
| 92 | + reg: | |
| 93 | + maxItems: 1 | |
| 94 | + | |
| 95 | + cpu: | |
| 96 | + $ref: /schemas/types.yaml#/definitions/phandle | |
| 97 | + description: | |
| 98 | + Handle to cpu this device is associated with. This must appear in the | |
| 99 | + base cti node if compatible string arm,coresight-cti-v8-arch is used, | |
| 100 | + or may appear in a trig-conns child node when appropriate. | |
| 101 | + | |
| 102 | + arm,cti-ctm-id: | |
| 103 | + $ref: /schemas/types.yaml#/definitions/uint32 | |
| 104 | + description: | |
| 105 | + Defines the CTM this CTI is connected to, in large systems with multiple | |
| 106 | + separate CTI/CTM nets. Typically multi-socket systems where the CTM is | |
| 107 | + propagated between sockets. | |
| 108 | + | |
| 109 | + arm,cs-dev-assoc: | |
| 110 | + $ref: /schemas/types.yaml#/definitions/phandle | |
| 111 | + description: | |
| 112 | + defines a phandle reference to an associated CoreSight trace device. | |
| 113 | + When the associated trace device is enabled, then the respective CTI | |
| 114 | + will be enabled. Use in a trig-conns node, or in CTI base node when | |
| 115 | + compatible string arm,coresight-cti-v8-arch used. If the associated | |
| 116 | + device has not been registered then the node name will be stored as | |
| 117 | + the connection name for later resolution. If the associated device is | |
| 118 | + not a CoreSight device or not registered then the node name will remain | |
| 119 | + the connection name and automatic enabling will not occur. | |
| 120 | + | |
| 121 | + # size cells and address cells required if trig-conns node present. | |
| 122 | + "#size-cells": | |
| 123 | + const: 0 | |
| 124 | + | |
| 125 | + "#address-cells": | |
| 126 | + const: 1 | |
| 127 | + | |
| 128 | +patternProperties: | |
| 129 | + '^trig-conns@([0-9]+)$': | |
| 130 | + type: object | |
| 131 | + description: | |
| 132 | + A trigger connections child node which describes the trigger signals | |
| 133 | + between this CTI and another hardware device. This device may be a CPU, | |
| 134 | + CoreSight device, any other hardware device or simple external IO lines. | |
| 135 | + The connection may have both input and output triggers, or only one or the | |
| 136 | + other. | |
| 137 | + | |
| 138 | + properties: | |
| 139 | + reg: | |
| 140 | + maxItems: 1 | |
| 141 | + | |
| 142 | + arm,trig-in-sigs: | |
| 143 | + allOf: | |
| 144 | + - $ref: /schemas/types.yaml#/definitions/uint32-array | |
| 145 | + minItems: 1 | |
| 146 | + maxItems: 32 | |
| 147 | + description: | |
| 148 | + List of CTI trigger in signal numbers in use by a trig-conns node. | |
| 149 | + | |
| 150 | + arm,trig-in-types: | |
| 151 | + allOf: | |
| 152 | + - $ref: /schemas/types.yaml#/definitions/uint32-array | |
| 153 | + minItems: 1 | |
| 154 | + maxItems: 32 | |
| 155 | + description: | |
| 156 | + List of constants representing the types for the CTI trigger in | |
| 157 | + signals. Types in this array match to the corresponding signal in the | |
| 158 | + arm,trig-in-sigs array. If the -types array is smaller, or omitted | |
| 159 | + completely, then the types will default to GEN_IO. | |
| 160 | + | |
| 161 | + arm,trig-out-sigs: | |
| 162 | + allOf: | |
| 163 | + - $ref: /schemas/types.yaml#/definitions/uint32-array | |
| 164 | + minItems: 1 | |
| 165 | + maxItems: 32 | |
| 166 | + description: | |
| 167 | + List of CTI trigger out signal numbers in use by a trig-conns node. | |
| 168 | + | |
| 169 | + arm,trig-out-types: | |
| 170 | + allOf: | |
| 171 | + - $ref: /schemas/types.yaml#/definitions/uint32-array | |
| 172 | + minItems: 1 | |
| 173 | + maxItems: 32 | |
| 174 | + description: | |
| 175 | + List of constants representing the types for the CTI trigger out | |
| 176 | + signals. Types in this array match to the corresponding signal | |
| 177 | + in the arm,trig-out-sigs array. If the "-types" array is smaller, | |
| 178 | + or omitted completely, then the types will default to GEN_IO. | |
| 179 | + | |
| 180 | + arm,trig-filters: | |
| 181 | + allOf: | |
| 182 | + - $ref: /schemas/types.yaml#/definitions/uint32-array | |
| 183 | + minItems: 1 | |
| 184 | + maxItems: 32 | |
| 185 | + description: | |
| 186 | + List of CTI trigger out signals that will be blocked from becoming | |
| 187 | + active, unless filtering is disabled on the driver. | |
| 188 | + | |
| 189 | + arm,trig-conn-name: | |
| 190 | + allOf: | |
| 191 | + - $ref: /schemas/types.yaml#/definitions/string | |
| 192 | + description: | |
| 193 | + Defines a connection name that will be displayed, if the cpu or | |
| 194 | + arm,cs-dev-assoc properties are not being used in this connection. | |
| 195 | + Principle use for CTI that are connected to non-CoreSight devices, or | |
| 196 | + external IO. | |
| 197 | + | |
| 198 | + anyOf: | |
| 199 | + - required: | |
| 200 | + - arm,trig-in-sigs | |
| 201 | + - required: | |
| 202 | + - arm,trig-out-sigs | |
| 203 | + oneOf: | |
| 204 | + - required: | |
| 205 | + - arm,trig-conn-name | |
| 206 | + - required: | |
| 207 | + - cpu | |
| 208 | + - required: | |
| 209 | + - arm,cs-dev-assoc | |
| 210 | + required: | |
| 211 | + - reg | |
| 212 | + | |
| 213 | +required: | |
| 214 | + - compatible | |
| 215 | + - reg | |
| 216 | + - clocks | |
| 217 | + - clock-names | |
| 218 | + | |
| 219 | +if: | |
| 220 | + properties: | |
| 221 | + compatible: | |
| 222 | + contains: | |
| 223 | + const: arm,coresight-cti-v8-arch | |
| 224 | + | |
| 225 | +then: | |
| 226 | + required: | |
| 227 | + - cpu | |
| 228 | + | |
| 229 | +examples: | |
| 230 | + # minimum CTI definition. DEVID register used to set number of triggers. | |
| 231 | + - | | |
| 232 | + cti@20020000 { | |
| 233 | + compatible = "arm,coresight-cti", "arm,primecell"; | |
| 234 | + reg = <0x20020000 0x1000>; | |
| 235 | + | |
| 236 | + clocks = <&soc_smc50mhz>; | |
| 237 | + clock-names = "apb_pclk"; | |
| 238 | + }; | |
| 239 | + # v8 architecturally defined CTI - CPU + ETM connections generated by the | |
| 240 | + # driver according to the v8 architecture specification. | |
| 241 | + - | | |
| 242 | + cti@859000 { | |
| 243 | + compatible = "arm,coresight-cti-v8-arch", "arm,coresight-cti", | |
| 244 | + "arm,primecell"; | |
| 245 | + reg = <0x859000 0x1000>; | |
| 246 | + | |
| 247 | + clocks = <&soc_smc50mhz>; | |
| 248 | + clock-names = "apb_pclk"; | |
| 249 | + | |
| 250 | + cpu = <&CPU1>; | |
| 251 | + arm,cs-dev-assoc = <&etm1>; | |
| 252 | + }; | |
| 253 | + # Implementation defined CTI - CPU + ETM connections explicitly defined.. | |
| 254 | + # Shows use of type constants from dt-bindings/arm/coresight-cti-dt.h | |
| 255 | + # #size-cells and #address-cells are required if trig-conns@ nodes present. | |
| 256 | + - | | |
| 257 | + #include <dt-bindings/arm/coresight-cti-dt.h> | |
| 258 | + | |
| 259 | + cti@858000 { | |
| 260 | + compatible = "arm,coresight-cti", "arm,primecell"; | |
| 261 | + reg = <0x858000 0x1000>; | |
| 262 | + | |
| 263 | + clocks = <&soc_smc50mhz>; | |
| 264 | + clock-names = "apb_pclk"; | |
| 265 | + | |
| 266 | + arm,cti-ctm-id = <1>; | |
| 267 | + | |
| 268 | + #address-cells = <1>; | |
| 269 | + #size-cells = <0>; | |
| 270 | + | |
| 271 | + trig-conns@0 { | |
| 272 | + reg = <0>; | |
| 273 | + arm,trig-in-sigs = <4 5 6 7>; | |
| 274 | + arm,trig-in-types = <ETM_EXTOUT | |
| 275 | + ETM_EXTOUT | |
| 276 | + ETM_EXTOUT | |
| 277 | + ETM_EXTOUT>; | |
| 278 | + arm,trig-out-sigs = <4 5 6 7>; | |
| 279 | + arm,trig-out-types = <ETM_EXTIN | |
| 280 | + ETM_EXTIN | |
| 281 | + ETM_EXTIN | |
| 282 | + ETM_EXTIN>; | |
| 283 | + arm,cs-dev-assoc = <&etm0>; | |
| 284 | + }; | |
| 285 | + | |
| 286 | + trig-conns@1 { | |
| 287 | + reg = <1>; | |
| 288 | + cpu = <&CPU0>; | |
| 289 | + arm,trig-in-sigs = <0 1>; | |
| 290 | + arm,trig-in-types = <PE_DBGTRIGGER | |
| 291 | + PE_PMUIRQ>; | |
| 292 | + arm,trig-out-sigs=<0 1 2 >; | |
| 293 | + arm,trig-out-types = <PE_EDBGREQ | |
| 294 | + PE_DBGRESTART | |
| 295 | + PE_CTIIRQ>; | |
| 296 | + | |
| 297 | + arm,trig-filters = <0>; | |
| 298 | + }; | |
| 299 | + }; | |
| 300 | + # Implementation defined CTI - non CoreSight component connections. | |
| 301 | + - | | |
| 302 | + cti@20110000 { | |
| 303 | + compatible = "arm,coresight-cti", "arm,primecell"; | |
| 304 | + reg = <0 0x20110000 0 0x1000>; | |
| 305 | + | |
| 306 | + clocks = <&soc_smc50mhz>; | |
| 307 | + clock-names = "apb_pclk"; | |
| 308 | + | |
| 309 | + #address-cells = <1>; | |
| 310 | + #size-cells = <0>; | |
| 311 | + | |
| 312 | + trig-conns@0 { | |
| 313 | + reg = <0>; | |
| 314 | + arm,trig-in-sigs=<0>; | |
| 315 | + arm,trig-in-types=<GEN_INTREQ>; | |
| 316 | + arm,trig-out-sigs=<0>; | |
| 317 | + arm,trig-out-types=<GEN_HALTREQ>; | |
| 318 | + arm,trig-conn-name = "sys_profiler"; | |
| 319 | + }; | |
| 320 | + | |
| 321 | + trig-conns@1 { | |
| 322 | + reg = <1>; | |
| 323 | + arm,trig-out-sigs=<2 3>; | |
| 324 | + arm,trig-out-types=<GEN_HALTREQ GEN_RESTARTREQ>; | |
| 325 | + arm,trig-conn-name = "watchdog"; | |
| 326 | + }; | |
| 327 | + | |
| 328 | + trig-conns@2 { | |
| 329 | + reg = <2>; | |
| 330 | + arm,trig-in-sigs=<1 6>; | |
| 331 | + arm,trig-in-types=<GEN_HALTREQ GEN_RESTARTREQ>; | |
| 332 | + arm,trig-conn-name = "g_counter"; | |
| 333 | + }; | |
| 334 | + }; | |
| 335 | + | |
| 336 | +... | |
| @@ -45,6 +45,10 @@ its hardware characteristcs. · 44 unmodified lines | ||
| 45 | 45 | - Coresight Address Translation Unit (CATU) |
| 46 | 46 | "arm,coresight-catu", "arm,primecell"; |
| 47 | 47 | |
| 48 | + - Coresight Cross Trigger Interface (CTI): | |
| 49 | + "arm,coresight-cti", "arm,primecell"; | |
| 50 | + See coresight-cti.yaml for full CTI definitions. | |
| 51 | + | |
| 48 | 52 | * reg: physical base address and length of the register |
| 49 | 53 | set(s) of the component. |
| 50 | 54 | |
| @@ -72,6 +76,9 @@ its hardware characteristcs. · 21 unmodified lines | ||
| 72 | 76 | * reg-names: the only acceptable values are "stm-base" and |
| 73 | 77 | "stm-stimulus-base", each corresponding to the areas defined in "reg". |
| 74 | 78 | |
| 79 | +* Required properties for Coresight Cross Trigger Interface (CTI) | |
| 80 | + See coresight-cti.yaml for full CTI definitions. | |
| 81 | + | |
| 75 | 82 | * Required properties for devices that don't show up on the AMBA bus, such as |
| 76 | 83 | non-configurable replicators and non-configurable funnels: |
| 77 | 84 | |
| @@ -123,11 +123,18 @@ properties: · 122 unmodified lines | ||
| 123 | 123 | - arm,cortex-a12 |
| 124 | 124 | - arm,cortex-a15 |
| 125 | 125 | - arm,cortex-a17 |
| 126 | + - arm,cortex-a32 | |
| 127 | + - arm,cortex-a34 | |
| 128 | + - arm,cortex-a35 | |
| 126 | 129 | - arm,cortex-a53 |
| 127 | 130 | - arm,cortex-a55 |
| 128 | 131 | - arm,cortex-a57 |
| 132 | + - arm,cortex-a65 | |
| 129 | 133 | - arm,cortex-a72 |
| 130 | 134 | - arm,cortex-a73 |
| 135 | + - arm,cortex-a75 | |
| 136 | + - arm,cortex-a76 | |
| 137 | + - arm,cortex-a77 | |
| 131 | 138 | - arm,cortex-m0 |
| 132 | 139 | - arm,cortex-m0+ |
| 133 | 140 | - arm,cortex-m1 |
| @@ -136,6 +143,8 @@ properties: · 2 unmodified lines | ||
| 136 | 143 | - arm,cortex-r4 |
| 137 | 144 | - arm,cortex-r5 |
| 138 | 145 | - arm,cortex-r7 |
| 146 | + - arm,neoverse-e1 | |
| 147 | + - arm,neoverse-n1 | |
| 139 | 148 | - brcm,brahma-b15 |
| 140 | 149 | - brcm,brahma-b53 |
| 141 | 150 | - brcm,vulcan |
| @@ -155,6 +164,8 @@ properties: · 13 unmodified lines | ||
| 155 | 164 | - nvidia,tegra194-carmel |
| 156 | 165 | - qcom,krait |
| 157 | 166 | - qcom,kryo |
| 167 | + - qcom,kryo260 | |
| 168 | + - qcom,kryo280 | |
| 158 | 169 | - qcom,kryo385 |
| 159 | 170 | - qcom,kryo485 |
| 160 | 171 | - qcom,scorpion |
| @@ -201,6 +212,8 @@ properties: · 40 unmodified lines | ||
| 201 | 212 | - rockchip,rk3066-smp |
| 202 | 213 | - socionext,milbeaut-m10v-smp |
| 203 | 214 | - ste,dbx500-smp |
| 215 | + - ti,am3352 | |
| 216 | + - ti,am4372 | |
| 204 | 217 | |
| 205 | 218 | cpu-release-addr: |
| 206 | 219 | $ref: '/schemas/types.yaml#/definitions/uint64' |
| @@ -287,6 +300,39 @@ properties: · 80 unmodified lines | ||
| 287 | 300 | While optional, it is the preferred way to get access to |
| 288 | 301 | the cpu-core power-domains. |
| 289 | 302 | |
| 303 | + secondary-boot-reg: | |
| 304 | + $ref: '/schemas/types.yaml#/definitions/uint32' | |
| 305 | + description: | | |
| 306 | + Required for systems that have an "enable-method" property value of | |
| 307 | + "brcm,bcm11351-cpu-method", "brcm,bcm23550" or "brcm,bcm-nsp-smp". | |
| 308 | + | |
| 309 | + This includes the following SoCs: | | |
| 310 | + BCM11130, BCM11140, BCM11351, BCM28145, BCM28155, BCM21664, BCM23550 | |
| 311 | + BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312 | |
| 312 | + | |
| 313 | + The secondary-boot-reg property is a u32 value that specifies the | |
| 314 | + physical address of the register used to request the ROM holding pen | |
| 315 | + code release a secondary CPU. The value written to the register is | |
| 316 | + formed by encoding the target CPU id into the low bits of the | |
| 317 | + physical start address it should jump to. | |
| 318 | + | |
| 319 | +if: | |
| 320 | + # If the enable-method property contains one of those values | |
| 321 | + properties: | |
| 322 | + enable-method: | |
| 323 | + contains: | |
| 324 | + enum: | |
| 325 | + - brcm,bcm11351-cpu-method | |
| 326 | + - brcm,bcm23550 | |
| 327 | + - brcm,bcm-nsp-smp | |
| 328 | + # and if enable-method is present | |
| 329 | + required: | |
| 330 | + - enable-method | |
| 331 | + | |
| 332 | +then: | |
| 333 | + required: | |
| 334 | + - secondary-boot-reg | |
| 335 | + | |
| 290 | 336 | required: |
| 291 | 337 | - device_type |
| 292 | 338 | - reg |
| @@ -164,7 +164,18 @@ Required properties: · 163 unmodified lines | ||
| 164 | 164 | - compatible: should be: |
| 165 | 165 | "fsl,imx8qxp-sc-key" |
| 166 | 166 | followed by "fsl,imx-sc-key"; |
| 167 | −- linux,keycodes: See Documentation/devicetree/bindings/input/keys.txt | |
| 167 | +- linux,keycodes: See Documentation/devicetree/bindings/input/input.yaml | |
| 168 | + | |
| 169 | +Thermal bindings based on SCU Message Protocol | |
| 170 | +------------------------------------------------------------ | |
| 171 | + | |
| 172 | +Required properties: | |
| 173 | +- compatible: Should be : | |
| 174 | + "fsl,imx8qxp-sc-thermal" | |
| 175 | + followed by "fsl,imx-sc-thermal"; | |
| 176 | + | |
| 177 | +- #thermal-sensor-cells: See Documentation/devicetree/bindings/thermal/thermal.txt | |
| 178 | + for a description. | |
| 168 | 179 | |
| 169 | 180 | Example (imx8qxp): |
| 170 | 181 | ------------- |
| @@ -238,6 +249,11 @@ firmware { · 67 unmodified lines | ||
| 238 | 249 | compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt"; |
| 239 | 250 | timeout-sec = <60>; |
| 240 | 251 | }; |
| 252 | + | |
| 253 | + tsens: thermal-sensor { | |
| 254 | + compatible = "fsl,imx8qxp-sc-thermal", "fsl,imx-sc-thermal"; | |
| 255 | + #thermal-sensor-cells = <1>; | |
| 256 | + }; | |
| 241 | 257 | }; |
| 242 | 258 | }; |
| 243 | 259 | |
| @@ -119,6 +119,10 @@ properties: · 118 unmodified lines | ||
| 119 | 119 | - fsl,imx6q-sabreauto |
| 120 | 120 | - fsl,imx6q-sabrelite |
| 121 | 121 | - fsl,imx6q-sabresd |
| 122 | + - technexion,imx6q-pico-dwarf # TechNexion i.MX6Q Pico-Dwarf | |
| 123 | + - technexion,imx6q-pico-hobbit # TechNexion i.MX6Q Pico-Hobbit | |
| 124 | + - technexion,imx6q-pico-nymph # TechNexion i.MX6Q Pico-Nymph | |
| 125 | + - technexion,imx6q-pico-pi # TechNexion i.MX6Q Pico-Pi | |
| 122 | 126 | - technologic,imx6q-ts4900 |
| 123 | 127 | - technologic,imx6q-ts7970 |
| 124 | 128 | - toradex,apalis_imx6q # Apalis iMX6 Module |
| @@ -166,6 +170,10 @@ properties: · 41 unmodified lines | ||
| 166 | 170 | - emtrion,emcon-mx6-avari # emCON-MX6S or emCON-MX6DL SoM on Avari Base |
| 167 | 171 | - fsl,imx6dl-sabreauto # i.MX6 DualLite/Solo SABRE Automotive Board |
| 168 | 172 | - fsl,imx6dl-sabresd # i.MX6 DualLite SABRE Smart Device Board |
| 173 | + - technexion,imx6dl-pico-dwarf # TechNexion i.MX6DL Pico-Dwarf | |
| 174 | + - technexion,imx6dl-pico-hobbit # TechNexion i.MX6DL Pico-Hobbit | |
| 175 | + - technexion,imx6dl-pico-nymph # TechNexion i.MX6DL Pico-Nymph | |
| 176 | + - technexion,imx6dl-pico-pi # TechNexion i.MX6DL Pico-Pi | |
| 169 | 177 | - technologic,imx6dl-ts4900 |
| 170 | 178 | - technologic,imx6dl-ts7970 |
| 171 | 179 | - toradex,colibri_imx6dl # Colibri iMX6 Module |
| @@ -225,6 +233,9 @@ properties: · 53 unmodified lines | ||
| 225 | 233 | - fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board |
| 226 | 234 | - kontron,imx6ul-n6310-som # Kontron N6310 SOM |
| 227 | 235 | - kontron,imx6ul-n6311-som # Kontron N6311 SOM |
| 236 | + - technexion,imx6ul-pico-dwarf # TechNexion i.MX6UL Pico-Dwarf | |
| 237 | + - technexion,imx6ul-pico-hobbit # TechNexion i.MX6UL Pico-Hobbit | |
| 238 | + - technexion,imx6ul-pico-pi # TechNexion i.MX6UL Pico-Pi | |
| 228 | 239 | - const: fsl,imx6ul |
| 229 | 240 | |
| 230 | 241 | - description: Kontron N6310 S Board |
| @@ -274,6 +285,7 @@ properties: · 43 unmodified lines | ||
| 274 | 285 | items: |
| 275 | 286 | - enum: |
| 276 | 287 | - toradex,colibri-imx7s # Colibri iMX7 Solo Module |
| 288 | + - toradex,colibri-imx7s-aster # Colibri iMX7 Solo Module on Aster Carrier Board | |
| 277 | 289 | - toradex,colibri-imx7s-eval-v3 # Colibri iMX7 Solo Module on Colibri Evaluation Board V3 |
| 278 | 290 | - tq,imx7s-mba7 # i.MX7S TQ MBa7 with TQMa7S SoM |
| 279 | 291 | - const: fsl,imx7s |
| @@ -284,8 +296,14 @@ properties: · 4 unmodified lines | ||
| 284 | 296 | - fsl,imx7d-sdb # i.MX7 SabreSD Board |
| 285 | 297 | - fsl,imx7d-sdb-reva # i.MX7 SabreSD Rev-A Board |
| 286 | 298 | - novtech,imx7d-meerkat96 # i.MX7 Meerkat96 Board |
| 299 | + - technexion,imx7d-pico-dwarf # TechNexion i.MX7D Pico-Dwarf | |
| 300 | + - technexion,imx7d-pico-hobbit # TechNexion i.MX7D Pico-Hobbit | |
| 301 | + - technexion,imx7d-pico-nymph # TechNexion i.MX7D Pico-Nymph | |
| 302 | + - technexion,imx7d-pico-pi # TechNexion i.MX7D Pico-Pi | |
| 287 | 303 | - toradex,colibri-imx7d # Colibri iMX7 Dual Module |
| 304 | + - toradex,colibri-imx7d-aster # Colibri iMX7 Dual Module on Aster Carrier Board | |
| 288 | 305 | - toradex,colibri-imx7d-emmc # Colibri iMX7 Dual 1GB (eMMC) Module |
| 306 | + - toradex,colibri-imx7d-emmc-aster # Colibri iMX7 Dual 1GB (eMMC) Module on Aster Carrier Board | |
| 289 | 307 | - toradex,colibri-imx7d-emmc-eval-v3 # Colibri iMX7 Dual 1GB (eMMC) Module on Colibri Evaluation Board V3 |
| 290 | 308 | - toradex,colibri-imx7d-eval-v3 # Colibri iMX7 Dual Module on Colibri Evaluation Board V3 |
| 291 | 309 | - tq,imx7d-mba7 # i.MX7D TQ MBa7 with TQMa7D SoM |
| @@ -324,6 +342,12 @@ properties: · 32 unmodified lines | ||
| 324 | 342 | - fsl,imx8mn-evk # i.MX8MN LPDDR4 EVK Board |
| 325 | 343 | - const: fsl,imx8mn |
| 326 | 344 | |
| 345 | + - description: i.MX8MP based Boards | |
| 346 | + items: | |
| 347 | + - enum: | |
| 348 | + - fsl,imx8mp-evk # i.MX8MP EVK Board | |
| 349 | + - const: fsl,imx8mp | |
| 350 | + | |
| 327 | 351 | - description: i.MX8MQ based Boards |
| 328 | 352 | items: |
| 329 | 353 | - enum: |
| @@ -395,6 +419,51 @@ properties: · 65 unmodified lines | ||
| 395 | 419 | - fsl,ls1021a-twr |
| 396 | 420 | - const: fsl,ls1021a |
| 397 | 421 | |
| 422 | + - description: LS1028A based Boards | |
| 423 | + items: | |
| 424 | + - enum: | |
| 425 | + - fsl,ls1028a-qds | |
| 426 | + - fsl,ls1028a-rdb | |
| 427 | + - const: fsl,ls1028a | |
| 428 | + | |
| 429 | + - description: Kontron KBox A-230-LS | |
| 430 | + items: | |
| 431 | + - const: kontron,kbox-a-230-ls | |
| 432 | + - const: kontron,sl28-var4 | |
| 433 | + - const: kontron,sl28 | |
| 434 | + - const: fsl,ls1028a | |
| 435 | + - description: | |
| 436 | + Kontron SMARC-sAL28 board on the SMARC Eval Carrier 2.0 | |
| 437 | + items: | |
| 438 | + - enum: | |
| 439 | + - kontron,sl28-var2-ads2 | |
| 440 | + - kontron,sl28-var3-ads2 | |
| 441 | + - kontron,sl28-var4-ads2 | |
| 442 | + - enum: | |
| 443 | + - kontron,sl28-var2 | |
| 444 | + - kontron,sl28-var3 | |
| 445 | + - kontron,sl28-var4 | |
| 446 | + - const: kontron,sl28 | |
| 447 | + - const: fsl,ls1028a | |
| 448 | + | |
| 449 | + - description: | |
| 450 | + Kontron SMARC-sAL28 board (on a generic/undefined carrier) | |
| 451 | + items: | |
| 452 | + - enum: | |
| 453 | + - kontron,sl28-var2 | |
| 454 | + - kontron,sl28-var3 | |
| 455 | + - kontron,sl28-var4 | |
| 456 | + - const: kontron,sl28 | |
| 457 | + - const: fsl,ls1028a | |
| 458 | + | |
| 459 | + - description: | |
| 460 | + Kontron SMARC-sAL28 board (base). This is used in the base device | |
| 461 | + tree which is compatible with the overlays provided by the | |
| 462 | + vendor. | |
| 463 | + items: | |
| 464 | + - const: kontron,sl28 | |
| 465 | + - const: fsl,ls1028a | |
| 466 | + | |
| 398 | 467 | - description: LS1043A based Boards |
| 399 | 468 | items: |
| 400 | 469 | - enum: |
| @@ -29,27 +29,30 @@ allOf: · 28 unmodified lines | ||
| 29 | 29 | |
| 30 | 30 | properties: |
| 31 | 31 | compatible: |
| 32 | − enum: | |
| 33 | − - arm,pl310-cache | |
| 34 | − - arm,l220-cache | |
| 35 | − - arm,l210-cache | |
| 36 | − # DEPRECATED by "brcm,bcm11351-a2-pl310-cache" | |
| 37 | − - bcm,bcm11351-a2-pl310-cache | |
| 38 | − # For Broadcom bcm11351 chipset where an | |
| 39 | − # offset needs to be added to the address before passing down to the L2 | |
| 40 | − # cache controller | |
| 41 | − - brcm,bcm11351-a2-pl310-cache | |
| 42 | − # Marvell Controller designed to be | |
| 43 | − # compatible with the ARM one, with system cache mode (meaning | |
| 44 | − # maintenance operations on L1 are broadcasted to the L2 and L2 | |
| 45 | − # performs the same operation). | |
| 46 | − - marvell,aurora-system-cache | |
| 47 | − # Marvell Controller designed to be | |
| 48 | − # compatible with the ARM one with outer cache mode. | |
| 49 | − - marvell,aurora-outer-cache | |
| 50 | − # Marvell Tauros3 cache controller, compatible | |
| 51 | − # with arm,pl310-cache controller. | |
| 52 | − - marvell,tauros3-cache | |
| 32 | + oneOf: | |
| 33 | + - enum: | |
| 34 | + - arm,pl310-cache | |
| 35 | + - arm,l220-cache | |
| 36 | + - arm,l210-cache | |
| 37 | + # DEPRECATED by "brcm,bcm11351-a2-pl310-cache" | |
| 38 | + - bcm,bcm11351-a2-pl310-cache | |
| 39 | + # For Broadcom bcm11351 chipset where an | |
| 40 | + # offset needs to be added to the address before passing down to the L2 | |
| 41 | + # cache controller | |
| 42 | + - brcm,bcm11351-a2-pl310-cache | |
| 43 | + # Marvell Controller designed to be | |
| 44 | + # compatible with the ARM one, with system cache mode (meaning | |
| 45 | + # maintenance operations on L1 are broadcasted to the L2 and L2 | |
| 46 | + # performs the same operation). | |
| 47 | + - marvell,aurora-system-cache | |
| 48 | + # Marvell Controller designed to be | |
| 49 | + # compatible with the ARM one with outer cache mode. | |
| 50 | + - marvell,aurora-outer-cache | |
| 51 | + - items: | |
| 52 | + # Marvell Tauros3 cache controller, compatible | |
| 53 | + # with arm,pl310-cache controller. | |
| 54 | + - const: marvell,tauros3-cache | |
| 55 | + - const: arm,pl310-cache | |
| 53 | 56 | |
| 54 | 57 | cache-level: |
| 55 | 58 | const: 2 |
| @@ -28,8 +28,11 @@ properties: · 27 unmodified lines | ||
| 28 | 28 | items: |
| 29 | 29 | - enum: |
| 30 | 30 | - mrvl,mmp2-brownstone |
| 31 | + - olpc,xo-1.75 | |
| 31 | 32 | - const: mrvl,mmp2 |
| 32 | 33 | - description: MMP3 based boards |
| 33 | 34 | items: |
| 34 | − - const: mrvl,mmp3 | |
| 35 | + - enum: | |
| 36 | + - dell,wyse-ariel | |
| 37 | + - const: marvell,mmp3 | |
| 35 | 38 | ... |
| @@ -43,6 +43,8 @@ required: · 42 unmodified lines | ||
| 43 | 43 | - reg-names |
| 44 | 44 | - interrupts |
| 45 | 45 | |
| 46 | +additionalProperties: false | |
| 47 | + | |
| 46 | 48 | examples: |
| 47 | 49 | - | |
| 48 | 50 | #include <dt-bindings/interrupt-controller/arm-gic.h> |
| @@ -20,27 +20,36 @@ properties: · 19 unmodified lines | ||
| 20 | 20 | items: |
| 21 | 21 | - enum: |
| 22 | 22 | - apm,potenza-pmu |
| 23 | − - arm,armv8-pmuv3 | |
| 24 | − - arm,cortex-a73-pmu | |
| 25 | − - arm,cortex-a72-pmu | |
| 26 | − - arm,cortex-a57-pmu | |
| 27 | − - arm,cortex-a53-pmu | |
| 28 | − - arm,cortex-a35-pmu | |
| 29 | − - arm,cortex-a17-pmu | |
| 30 | − - arm,cortex-a15-pmu | |
| 31 | − - arm,cortex-a12-pmu | |
| 32 | − - arm,cortex-a9-pmu | |
| 33 | − - arm,cortex-a8-pmu | |
| 34 | − - arm,cortex-a7-pmu | |
| 35 | − - arm,cortex-a5-pmu | |
| 36 | − - arm,arm11mpcore-pmu | |
| 37 | − - arm,arm1176-pmu | |
| 23 | + - arm,armv8-pmuv3 # Only for s/w models | |
| 38 | 24 | - arm,arm1136-pmu |
| 25 | + - arm,arm1176-pmu | |
| 26 | + - arm,arm11mpcore-pmu | |
| 27 | + - arm,cortex-a5-pmu | |
| 28 | + - arm,cortex-a7-pmu | |
| 29 | + - arm,cortex-a8-pmu | |
| 30 | + - arm,cortex-a9-pmu | |
| 31 | + - arm,cortex-a12-pmu | |
| 32 | + - arm,cortex-a15-pmu | |
| 33 | + - arm,cortex-a17-pmu | |
| 34 | + - arm,cortex-a32-pmu | |
| 35 | + - arm,cortex-a34-pmu | |
| 36 | + - arm,cortex-a35-pmu | |
| 37 | + - arm,cortex-a53-pmu | |
| 38 | + - arm,cortex-a55-pmu | |
| 39 | + - arm,cortex-a57-pmu | |
| 40 | + - arm,cortex-a65-pmu | |
| 41 | + - arm,cortex-a72-pmu | |
| 42 | + - arm,cortex-a73-pmu | |
| 43 | + - arm,cortex-a75-pmu | |
| 44 | + - arm,cortex-a76-pmu | |
| 45 | + - arm,cortex-a77-pmu | |
| 46 | + - arm,neoverse-e1-pmu | |
| 47 | + - arm,neoverse-n1-pmu | |
| 39 | 48 | - brcm,vulcan-pmu |
| 40 | 49 | - cavium,thunder-pmu |
| 50 | + - qcom,krait-pmu | |
| 41 | 51 | - qcom,scorpion-pmu |
| 42 | 52 | - qcom,scorpion-mp-pmu |
| 43 | − - qcom,krait-pmu | |
| 44 | 53 | |
| 45 | 54 | interrupts: |
| 46 | 55 | # Don't know how many CPUs, so no constraints to specify |
| @@ -32,6 +32,9 @@ description: |+ · 31 unmodified lines | ||
| 32 | 32 | http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf |
| 33 | 33 | |
| 34 | 34 | properties: |
| 35 | + $nodename: | |
| 36 | + const: psci | |
| 37 | + | |
| 35 | 38 | compatible: |
| 36 | 39 | oneOf: |
| 37 | 40 | - description: |
| @@ -141,6 +144,8 @@ allOf: · 103 unmodified lines | ||
| 141 | 144 | - cpu_off |
| 142 | 145 | - cpu_on |
| 143 | 146 | |
| 147 | +additionalProperties: false | |
| 148 | + | |
| 144 | 149 | examples: |
| 145 | 150 | - |+ |
| 146 | 151 | |
| @@ -28,6 +28,7 @@ description: | · 27 unmodified lines | ||
| 28 | 28 | apq8074 |
| 29 | 29 | apq8084 |
| 30 | 30 | apq8096 |
| 31 | + ipq6018 | |
| 31 | 32 | ipq8074 |
| 32 | 33 | mdm9615 |
| 33 | 34 | msm8916 |
| @@ -41,6 +42,7 @@ description: | · 7 unmodified lines | ||
| 41 | 42 | The 'board' element must be one of the following strings: |
| 42 | 43 | |
| 43 | 44 | cdp |
| 45 | + cp01-c1 | |
| 44 | 46 | dragonboard |
| 45 | 47 | hk01 |
| 46 | 48 | idp |
| @@ -150,4 +152,10 @@ properties: · 103 unmodified lines | ||
| 150 | 152 | - enum: |
| 151 | 153 | - qcom,sc7180-idp |
| 152 | 154 | - const: qcom,sc7180 |
| 155 | + | |
| 156 | + - items: | |
| 157 | + - enum: | |
| 158 | + - qcom,ipq6018-cp01-c1 | |
| 159 | + - const: qcom,ipq6018 | |
| 160 | + | |
| 153 | 161 | ... |
| @@ -27,6 +27,8 @@ required: · 26 unmodified lines | ||
| 27 | 27 | - compatible |
| 28 | 28 | - reg |
| 29 | 29 | |
| 30 | +additionalProperties: false | |
| 31 | + | |
| 30 | 32 | examples: |
| 31 | 33 | - | |
| 32 | 34 | prr: chipid@ff000044 { |
| @@ -208,6 +208,7 @@ properties: · 207 unmodified lines | ||
| 208 | 208 | - description: R-Car M3-W+ (R8A77961) |
| 209 | 209 | items: |
| 210 | 210 | - enum: |
| 211 | + - renesas,m3ulcb # M3ULCB (R-Car Starter Kit Pro, RTP8J77961ASKB0SK0SA05A (M3 ES3.0)) | |
| 211 | 212 | - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012SA5A) |
| 212 | 213 | - const: renesas,r8a77961 |
| 213 | 214 | |
| @@ -402,6 +402,11 @@ properties: · 401 unmodified lines | ||
| 402 | 402 | - const: phytec,rk3288-phycore-som |
| 403 | 403 | - const: rockchip,rk3288 |
| 404 | 404 | |
| 405 | + - description: Pine64 PinebookPro | |
| 406 | + items: | |
| 407 | + - const: pine64,pinebook-pro | |
| 408 | + - const: rockchip,rk3399 | |
| 409 | + | |
| 405 | 410 | - description: Pine64 Rock64 |
| 406 | 411 | items: |
| 407 | 412 | - const: pine64,rock64 |
| @@ -443,7 +448,7 @@ properties: · 35 unmodified lines | ||
| 443 | 448 | |
| 444 | 449 | - description: Rockchip Kylin |
| 445 | 450 | items: |
| 446 | − - const: rockchip,kylin-rk3036 | |
| 451 | + - const: rockchip,rk3036-kylin | |
| 447 | 452 | - const: rockchip,rk3036 |
| 448 | 453 | |
| 449 | 454 | - description: Rockchip PX3 Evaluation board |
| @@ -468,6 +473,11 @@ properties: · 18 unmodified lines | ||
| 468 | 473 | - const: rockchip,r88 |
| 469 | 474 | - const: rockchip,rk3368 |
| 470 | 475 | |
| 476 | + - description: Rockchip RK3036 Evaluation board | |
| 477 | + items: | |
| 478 | + - const: rockchip,rk3036-evb | |
| 479 | + - const: rockchip,rk3036 | |
| 480 | + | |
| 471 | 481 | - description: Rockchip RK3228 Evaluation board |
| 472 | 482 | items: |
| 473 | 483 | - const: rockchip,rk3228-evb |
| @@ -30,6 +30,8 @@ required: · 29 unmodified lines | ||
| 30 | 30 | - compatible |
| 31 | 31 | - reg |
| 32 | 32 | |
| 33 | +additionalProperties: false | |
| 34 | + | |
| 33 | 35 | examples: |
| 34 | 36 | - | |
| 35 | 37 | chipid@10000000 { |
| @@ -89,6 +89,8 @@ required: · 88 unmodified lines | ||
| 89 | 89 | - clock-names |
| 90 | 90 | - clocks |
| 91 | 91 | |
| 92 | +additionalProperties: false | |
| 93 | + | |
| 92 | 94 | examples: |
| 93 | 95 | - | |
| 94 | 96 | #include <dt-bindings/clock/exynos5250.h> |
| @@ -23,6 +23,8 @@ required: · 22 unmodified lines | ||
| 23 | 23 | - compatible |
| 24 | 24 | - reg |
| 25 | 25 | |
| 26 | +additionalProperties: false | |
| 27 | + | |
| 26 | 28 | examples: |
| 27 | 29 | - | |
| 28 | 30 | firmware@203f000 { |
| @@ -1,60 +0,0 @@ | ||
| 1 | −UniPhier outer cache controller | |
| 2 | − | |
| 3 | −UniPhier SoCs are integrated with a full-custom outer cache controller system. | |
| 4 | −All of them have a level 2 cache controller, and some have a level 3 cache | |
| 5 | −controller as well. | |
| 6 | − | |
| 7 | −Required properties: | |
| 8 | −- compatible: should be "socionext,uniphier-system-cache" | |
| 9 | −- reg: offsets and lengths of the register sets for the device. It should | |
| 10 | − contain 3 regions: control register, revision register, operation register, | |
| 11 | − in this order. | |
| 12 | −- cache-unified: specifies the cache is a unified cache. | |
| 13 | −- cache-size: specifies the size in bytes of the cache | |
| 14 | −- cache-sets: specifies the number of associativity sets of the cache | |
| 15 | −- cache-line-size: specifies the line size in bytes | |
| 16 | −- cache-level: specifies the level in the cache hierarchy. The value should | |
| 17 | − be 2 for L2 cache, 3 for L3 cache, etc. | |
| 18 | − | |
| 19 | −Optional properties: | |
| 20 | −- next-level-cache: phandle to the next level cache if present. The next level | |
| 21 | − cache should be also compatible with "socionext,uniphier-system-cache". | |
| 22 | − | |
| 23 | −The L2 cache must exist to use the L3 cache; the cache hierarchy must be | |
| 24 | −indicated correctly with "next-level-cache" properties. | |
| 25 | − | |
| 26 | −Example 1 (system with L2): | |
| 27 | − l2: l2-cache@500c0000 { | |
| 28 | − compatible = "socionext,uniphier-system-cache"; | |
| 29 | − reg = <0x500c0000 0x2000>, <0x503c0100 0x4>, | |
| 30 | − <0x506c0000 0x400>; | |
| 31 | − cache-unified; | |
| 32 | − cache-size = <0x80000>; | |
| 33 | − cache-sets = <256>; | |
| 34 | − cache-line-size = <128>; | |
| 35 | − cache-level = <2>; | |
| 36 | − }; | |
| 37 | − | |
| 38 | −Example 2 (system with L2 and L3): | |
| 39 | − l2: l2-cache@500c0000 { | |
| 40 | − compatible = "socionext,uniphier-system-cache"; | |
| 41 | − reg = <0x500c0000 0x2000>, <0x503c0100 0x8>, | |
| 42 | − <0x506c0000 0x400>; | |
| 43 | − cache-unified; | |
| 44 | − cache-size = <0x200000>; | |
| 45 | − cache-sets = <512>; | |
| 46 | − cache-line-size = <128>; | |
| 47 | − cache-level = <2>; | |
| 48 | − next-level-cache = <&l3>; | |
| 49 | − }; | |
| 50 | − | |
| 51 | − l3: l3-cache@500c8000 { | |
| 52 | − compatible = "socionext,uniphier-system-cache"; | |
| 53 | − reg = <0x500c8000 0x2000>, <0x503c8100 0x8>, | |
| 54 | − <0x506c8000 0x400>; | |
| 55 | − cache-unified; | |
| 56 | − cache-size = <0x400000>; | |
| 57 | − cache-sets = <512>; | |
| 58 | − cache-line-size = <256>; | |
| 59 | − cache-level = <3>; | |
| 60 | − }; | |
| @@ -0,0 +1,102 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/arm/socionext/socionext,uniphier-system-cache.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: UniPhier outer cache controller | |
| 8 | + | |
| 9 | +description: | | |
| 10 | + UniPhier ARM 32-bit SoCs are integrated with a full-custom outer cache | |
| 11 | + controller system. All of them have a level 2 cache controller, and some | |
| 12 | + have a level 3 cache controller as well. | |
| 13 | + | |
| 14 | +maintainers: | |
| 15 | + - Masahiro Yamada <yamada.masahiro@socionext.com> | |
| 16 | + | |
| 17 | +properties: | |
| 18 | + compatible: | |
| 19 | + const: socionext,uniphier-system-cache | |
| 20 | + | |
| 21 | + reg: | |
| 22 | + description: | | |
| 23 | + should contain 3 regions: control register, revision register, | |
| 24 | + operation register, in this order. | |
| 25 | + minItems: 3 | |
| 26 | + maxItems: 3 | |
| 27 | + | |
| 28 | + interrupts: | |
| 29 | + description: | | |
| 30 | + Interrupts can be used to notify the completion of cache operations. | |
| 31 | + The number of interrupts should match to the number of CPU cores. | |
| 32 | + The specified interrupts correspond to CPU0, CPU1, ... in this order. | |
| 33 | + minItems: 1 | |
| 34 | + maxItems: 4 | |
| 35 | + | |
| 36 | + cache-unified: true | |
| 37 | + | |
| 38 | + cache-size: true | |
| 39 | + | |
| 40 | + cache-sets: true | |
| 41 | + | |
| 42 | + cache-line-size: true | |
| 43 | + | |
| 44 | + cache-level: | |
| 45 | + minimum: 2 | |
| 46 | + maximum: 3 | |
| 47 | + | |
| 48 | + next-level-cache: true | |
| 49 | + | |
| 50 | +allOf: | |
| 51 | + - $ref: /schemas/cache-controller.yaml# | |
| 52 | + | |
| 53 | +additionalProperties: false | |
| 54 | + | |
| 55 | +required: | |
| 56 | + - compatible | |
| 57 | + - reg | |
| 58 | + - interrupts | |
| 59 | + - cache-unified | |
| 60 | + - cache-size | |
| 61 | + - cache-sets | |
| 62 | + - cache-line-size | |
| 63 | + - cache-level | |
| 64 | + | |
| 65 | +examples: | |
| 66 | + - | | |
| 67 | + // System with L2. | |
| 68 | + cache-controller@500c0000 { | |
| 69 | + compatible = "socionext,uniphier-system-cache"; | |
| 70 | + reg = <0x500c0000 0x2000>, <0x503c0100 0x4>, <0x506c0000 0x400>; | |
| 71 | + interrupts = <0 174 4>, <0 175 4>, <0 190 4>, <0 191 4>; | |
| 72 | + cache-unified; | |
| 73 | + cache-size = <0x140000>; | |
| 74 | + cache-sets = <512>; | |
| 75 | + cache-line-size = <128>; | |
| 76 | + cache-level = <2>; | |
| 77 | + }; | |
| 78 | + - | | |
| 79 | + // System with L2 and L3. | |
| 80 | + // L2 should specify the next level cache by 'next-level-cache'. | |
| 81 | + l2: cache-controller@500c0000 { | |
| 82 | + compatible = "socionext,uniphier-system-cache"; | |
| 83 | + reg = <0x500c0000 0x2000>, <0x503c0100 0x8>, <0x506c0000 0x400>; | |
| 84 | + interrupts = <0 190 4>, <0 191 4>; | |
| 85 | + cache-unified; | |
| 86 | + cache-size = <0x200000>; | |
| 87 | + cache-sets = <512>; | |
| 88 | + cache-line-size = <128>; | |
| 89 | + cache-level = <2>; | |
| 90 | + next-level-cache = <&l3>; | |
| 91 | + }; | |
| 92 | + | |
| 93 | + l3: cache-controller@500c8000 { | |
| 94 | + compatible = "socionext,uniphier-system-cache"; | |
| 95 | + reg = <0x500c8000 0x2000>, <0x503c8100 0x8>, <0x506c8000 0x400>; | |
| 96 | + interrupts = <0 174 4>, <0 175 4>; | |
| 97 | + cache-unified; | |
| 98 | + cache-size = <0x200000>; | |
| 99 | + cache-sets = <512>; | |
| 100 | + cache-line-size = <256>; | |
| 101 | + cache-level = <3>; | |
| 102 | + }; | |
| @@ -1,47 +0,0 @@ | ||
| 1 | −Socionext UniPhier SoC family | |
| 2 | −----------------------------- | |
| 3 | − | |
| 4 | −Required properties in the root node: | |
| 5 | − - compatible: should contain board and SoC compatible strings | |
| 6 | − | |
| 7 | −SoC and board compatible strings: | |
| 8 | − (sorted chronologically) | |
| 9 | − | |
| 10 | − - LD4 SoC: "socionext,uniphier-ld4" | |
| 11 | − - Reference Board: "socionext,uniphier-ld4-ref" | |
| 12 | − | |
| 13 | − - Pro4 SoC: "socionext,uniphier-pro4" | |
| 14 | − - Reference Board: "socionext,uniphier-pro4-ref" | |
| 15 | − - Ace Board: "socionext,uniphier-pro4-ace" | |
| 16 | − - Sanji Board: "socionext,uniphier-pro4-sanji" | |
| 17 | − | |
| 18 | − - sLD8 SoC: "socionext,uniphier-sld8" | |
| 19 | − - Reference Board: "socionext,uniphier-sld8-ref" | |
| 20 | − | |
| 21 | − - PXs2 SoC: "socionext,uniphier-pxs2" | |
| 22 | − - Gentil Board: "socionext,uniphier-pxs2-gentil" | |
| 23 | − - Vodka Board: "socionext,uniphier-pxs2-vodka" | |
| 24 | − | |
| 25 | − - LD6b SoC: "socionext,uniphier-ld6b" | |
| 26 | − - Reference Board: "socionext,uniphier-ld6b-ref" | |
| 27 | − | |
| 28 | − - LD11 SoC: "socionext,uniphier-ld11" | |
| 29 | − - Reference Board: "socionext,uniphier-ld11-ref" | |
| 30 | − - Global Board: "socionext,uniphier-ld11-global" | |
| 31 | − | |
| 32 | − - LD20 SoC: "socionext,uniphier-ld20" | |
| 33 | − - Reference Board: "socionext,uniphier-ld20-ref" | |
| 34 | − - Global Board: "socionext,uniphier-ld20-global" | |
| 35 | − | |
| 36 | − - PXs3 SoC: "socionext,uniphier-pxs3" | |
| 37 | − - Reference Board: "socionext,uniphier-pxs3-ref" | |
| 38 | − | |
| 39 | −Example: | |
| 40 | − | |
| 41 | −/dts-v1/; | |
| 42 | − | |
| 43 | −/ { | |
| 44 | − compatible = "socionext,uniphier-ld20-ref", "socionext,uniphier-ld20"; | |
| 45 | − | |
| 46 | − ... | |
| 47 | −}; | |
| @@ -0,0 +1,61 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/arm/socionext/uniphier.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Socionext UniPhier platform device tree bindings | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Masahiro Yamada <yamada.masahiro@socionext.com> | |
| 11 | + | |
| 12 | +properties: | |
| 13 | + $nodename: | |
| 14 | + const: / | |
| 15 | + compatible: | |
| 16 | + oneOf: | |
| 17 | + - description: LD4 SoC boards | |
| 18 | + items: | |
| 19 | + - enum: | |
| 20 | + - socionext,uniphier-ld4-ref | |
| 21 | + - const: socionext,uniphier-ld4 | |
| 22 | + - description: Pro4 SoC boards | |
| 23 | + items: | |
| 24 | + - enum: | |
| 25 | + - socionext,uniphier-pro4-ace | |
| 26 | + - socionext,uniphier-pro4-ref | |
| 27 | + - socionext,uniphier-pro4-sanji | |
| 28 | + - const: socionext,uniphier-pro4 | |
| 29 | + - description: sLD8 SoC boards | |
| 30 | + items: | |
| 31 | + - enum: | |
| 32 | + - socionext,uniphier-sld8-ref | |
| 33 | + - const: socionext,uniphier-sld8 | |
| 34 | + - description: PXs2 SoC boards | |
| 35 | + items: | |
| 36 | + - enum: | |
| 37 | + - socionext,uniphier-pxs2-gentil | |
| 38 | + - socionext,uniphier-pxs2-vodka | |
| 39 | + - const: socionext,uniphier-pxs2 | |
| 40 | + - description: LD6b SoC boards | |
| 41 | + items: | |
| 42 | + - enum: | |
| 43 | + - socionext,uniphier-ld6b-ref | |
| 44 | + - const: socionext,uniphier-ld6b | |
| 45 | + - description: LD11 SoC boards | |
| 46 | + items: | |
| 47 | + - enum: | |
| 48 | + - socionext,uniphier-ld11-global | |
| 49 | + - socionext,uniphier-ld11-ref | |
| 50 | + - const: socionext,uniphier-ld11 | |
| 51 | + - description: LD20 SoC boards | |
| 52 | + items: | |
| 53 | + - enum: | |
| 54 | + - socionext,uniphier-ld20-global | |
| 55 | + - socionext,uniphier-ld20-ref | |
| 56 | + - const: socionext,uniphier-ld20 | |
| 57 | + - description: PXs3 SoC boards | |
| 58 | + items: | |
| 59 | + - enum: | |
| 60 | + - socionext,uniphier-pxs3-ref | |
| 61 | + - const: socionext,uniphier-pxs3 | |
| @@ -29,6 +29,8 @@ required: · 28 unmodified lines | ||
| 29 | 29 | - reg |
| 30 | 30 | - clocks |
| 31 | 31 | |
| 32 | +additionalProperties: false | |
| 33 | + | |
| 32 | 34 | examples: |
| 33 | 35 | - | |
| 34 | 36 | #include <dt-bindings/clock/stm32mp1-clks.h> |
| @@ -394,6 +394,12 @@ properties: · 393 unmodified lines | ||
| 394 | 394 | - const: linksprite,pcduino3-nano |
| 395 | 395 | - const: allwinner,sun7i-a20 |
| 396 | 396 | |
| 397 | + - description: Linutronix Testbox v2 | |
| 398 | + items: | |
| 399 | + - const: linutronix,testbox-v2 | |
| 400 | + - const: lamobo,lamobo-r1 | |
| 401 | + - const: allwinner,sun7i-a20 | |
| 402 | + | |
| 397 | 403 | - description: HAOYU Electronics Marsboard A10 |
| 398 | 404 | items: |
| 399 | 405 | - const: haoyu,a10-marsboard |
| @@ -636,6 +642,21 @@ properties: · 236 unmodified lines | ||
| 636 | 642 | - const: pine64,pinebook |
| 637 | 643 | - const: allwinner,sun50i-a64 |
| 638 | 644 | |
| 645 | + - description: Pine64 PinePhone Developer Batch (1.0) | |
| 646 | + items: | |
| 647 | + - const: pine64,pinephone-1.0 | |
| 648 | + - const: allwinner,sun50i-a64 | |
| 649 | + | |
| 650 | + - description: Pine64 PinePhone Braveheart (1.1) | |
| 651 | + items: | |
| 652 | + - const: pine64,pinephone-1.1 | |
| 653 | + - const: allwinner,sun50i-a64 | |
| 654 | + | |
| 655 | + - description: Pine64 PineTab | |
| 656 | + items: | |
| 657 | + - const: pine64,pinetab | |
| 658 | + - const: allwinner,sun50i-a64 | |
| 659 | + | |
| 639 | 660 | - description: Pine64 SoPine Baseboard |
| 640 | 661 | items: |
| 641 | 662 | - const: pine64,sopine-baseboard |
| @@ -647,6 +668,11 @@ properties: · 5 unmodified lines | ||
| 647 | 668 | - const: pineriver,mini-xplus |
| 648 | 669 | - const: allwinner,sun4i-a10 |
| 649 | 670 | |
| 671 | + - description: PocketBook Touch Lux 3 | |
| 672 | + items: | |
| 673 | + - const: pocketbook,touch-lux-3 | |
| 674 | + - const: allwinner,sun5i-a13 | |
| 675 | + | |
| 650 | 676 | - description: Point of View Protab2-IPS9 |
| 651 | 677 | items: |
| 652 | 678 | - const: pov,protab2-ips9 |
| @@ -30,6 +30,7 @@ properties: · 29 unmodified lines | ||
| 30 | 30 | enum: |
| 31 | 31 | - allwinner,sun5i-a13-mbus |
| 32 | 32 | - allwinner,sun8i-h3-mbus |
| 33 | + - allwinner,sun50i-a64-mbus | |
| 33 | 34 | |
| 34 | 35 | reg: |
| 35 | 36 | maxItems: 1 |
| @@ -1,300 +0,0 @@ | ||
| 1 | −NVIDIA Tegra Power Management Controller (PMC) | |
| 2 | − | |
| 3 | −== Power Management Controller Node == | |
| 4 | − | |
| 5 | −The PMC block interacts with an external Power Management Unit. The PMC | |
| 6 | −mostly controls the entry and exit of the system from different sleep | |
| 7 | −modes. It provides power-gating controllers for SoC and CPU power-islands. | |
| 8 | − | |
| 9 | −Required properties: | |
| 10 | −- name : Should be pmc | |
| 11 | −- compatible : Should contain one of the following: | |
| 12 | − For Tegra20 must contain "nvidia,tegra20-pmc". | |
| 13 | − For Tegra30 must contain "nvidia,tegra30-pmc". | |
| 14 | − For Tegra114 must contain "nvidia,tegra114-pmc" | |
| 15 | − For Tegra124 must contain "nvidia,tegra124-pmc" | |
| 16 | − For Tegra132 must contain "nvidia,tegra124-pmc" | |
| 17 | − For Tegra210 must contain "nvidia,tegra210-pmc" | |
| 18 | −- reg : Offset and length of the register set for the device | |
| 19 | −- clocks : Must contain an entry for each entry in clock-names. | |
| 20 | − See ../clocks/clock-bindings.txt for details. | |
| 21 | −- clock-names : Must include the following entries: | |
| 22 | − "pclk" (The Tegra clock of that name), | |
| 23 | − "clk32k_in" (The 32KHz clock input to Tegra). | |
| 24 | − | |
| 25 | −Optional properties: | |
| 26 | −- nvidia,invert-interrupt : If present, inverts the PMU interrupt signal. | |
| 27 | − The PMU is an external Power Management Unit, whose interrupt output | |
| 28 | − signal is fed into the PMC. This signal is optionally inverted, and then | |
| 29 | − fed into the ARM GIC. The PMC is not involved in the detection or | |
| 30 | − handling of this interrupt signal, merely its inversion. | |
| 31 | −- nvidia,suspend-mode : The suspend mode that the platform should use. | |
| 32 | − Valid values are 0, 1 and 2: | |
| 33 | − 0 (LP0): CPU + Core voltage off and DRAM in self-refresh | |
| 34 | − 1 (LP1): CPU voltage off and DRAM in self-refresh | |
| 35 | − 2 (LP2): CPU voltage off | |
| 36 | −- nvidia,core-power-req-active-high : Boolean, core power request active-high | |
| 37 | −- nvidia,sys-clock-req-active-high : Boolean, system clock request active-high | |
| 38 | −- nvidia,combined-power-req : Boolean, combined power request for CPU & Core | |
| 39 | −- nvidia,cpu-pwr-good-en : Boolean, CPU power good signal (from PMIC to PMC) | |
| 40 | − is enabled. | |
| 41 | − | |
| 42 | −Required properties when nvidia,suspend-mode is specified: | |
| 43 | −- nvidia,cpu-pwr-good-time : CPU power good time in uS. | |
| 44 | −- nvidia,cpu-pwr-off-time : CPU power off time in uS. | |
| 45 | −- nvidia,core-pwr-good-time : <Oscillator-stable-time Power-stable-time> | |
| 46 | − Core power good time in uS. | |
| 47 | −- nvidia,core-pwr-off-time : Core power off time in uS. | |
| 48 | − | |
| 49 | −Required properties when nvidia,suspend-mode=<0>: | |
| 50 | −- nvidia,lp0-vec : <start length> Starting address and length of LP0 vector | |
| 51 | − The LP0 vector contains the warm boot code that is executed by AVP when | |
| 52 | − resuming from the LP0 state. The AVP (Audio-Video Processor) is an ARM7 | |
| 53 | − processor and always being the first boot processor when chip is power on | |
| 54 | − or resume from deep sleep mode. When the system is resumed from the deep | |
| 55 | − sleep mode, the warm boot code will restore some PLLs, clocks and then | |
| 56 | − bring up CPU0 for resuming the system. | |
| 57 | − | |
| 58 | −Hardware-triggered thermal reset: | |
| 59 | −On Tegra30, Tegra114 and Tegra124, if the 'i2c-thermtrip' subnode exists, | |
| 60 | −hardware-triggered thermal reset will be enabled. | |
| 61 | − | |
| 62 | −Required properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'): | |
| 63 | −- nvidia,i2c-controller-id : ID of I2C controller to send poweroff command to. Valid values are | |
| 64 | − described in section 9.2.148 "APBDEV_PMC_SCRATCH53_0" of the | |
| 65 | − Tegra K1 Technical Reference Manual. | |
| 66 | −- nvidia,bus-addr : Bus address of the PMU on the I2C bus | |
| 67 | −- nvidia,reg-addr : I2C register address to write poweroff command to | |
| 68 | −- nvidia,reg-data : Poweroff command to write to PMU | |
| 69 | − | |
| 70 | −Optional properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'): | |
| 71 | −- nvidia,pinmux-id : Pinmux used by the hardware when issuing poweroff command. | |
| 72 | − Defaults to 0. Valid values are described in section 12.5.2 | |
| 73 | − "Pinmux Support" of the Tegra4 Technical Reference Manual. | |
| 74 | − | |
| 75 | −Optional nodes: | |
| 76 | −- powergates : This node contains a hierarchy of power domain nodes, which | |
| 77 | − should match the powergates on the Tegra SoC. See "Powergate | |
| 78 | − Nodes" below. | |
| 79 | − | |
| 80 | −Example: | |
| 81 | − | |
| 82 | −/ SoC dts including file | |
| 83 | −pmc@7000f400 { | |
| 84 | − compatible = "nvidia,tegra20-pmc"; | |
| 85 | − reg = <0x7000e400 0x400>; | |
| 86 | − clocks = <&tegra_car 110>, <&clk32k_in>; | |
| 87 | − clock-names = "pclk", "clk32k_in"; | |
| 88 | − nvidia,invert-interrupt; | |
| 89 | − nvidia,suspend-mode = <1>; | |
| 90 | − nvidia,cpu-pwr-good-time = <2000>; | |
| 91 | − nvidia,cpu-pwr-off-time = <100>; | |
| 92 | − nvidia,core-pwr-good-time = <3845 3845>; | |
| 93 | − nvidia,core-pwr-off-time = <458>; | |
| 94 | − nvidia,core-power-req-active-high; | |
| 95 | − nvidia,sys-clock-req-active-high; | |
| 96 | − nvidia,lp0-vec = <0xbdffd000 0x2000>; | |
| 97 | −}; | |
| 98 | − | |
| 99 | −/ Tegra board dts file | |
| 100 | −{ | |
| 101 | − ... | |
| 102 | − pmc@7000f400 { | |
| 103 | − i2c-thermtrip { | |
| 104 | − nvidia,i2c-controller-id = <4>; | |
| 105 | − nvidia,bus-addr = <0x40>; | |
| 106 | − nvidia,reg-addr = <0x36>; | |
| 107 | − nvidia,reg-data = <0x2>; | |
| 108 | − }; | |
| 109 | − }; | |
| 110 | − ... | |
| 111 | − clocks { | |
| 112 | − compatible = "simple-bus"; | |
| 113 | − #address-cells = <1>; | |
| 114 | − #size-cells = <0>; | |
| 115 | − | |
| 116 | − clk32k_in: clock { | |
| 117 | − compatible = "fixed-clock"; | |
| 118 | − reg=<0>; | |
| 119 | − #clock-cells = <0>; | |
| 120 | − clock-frequency = <32768>; | |
| 121 | − }; | |
| 122 | − }; | |
| 123 | − ... | |
| 124 | −}; | |
| 125 | − | |
| 126 | − | |
| 127 | −== Powergate Nodes == | |
| 128 | − | |
| 129 | −Each of the powergate nodes represents a power-domain on the Tegra SoC | |
| 130 | −that can be power-gated by the Tegra PMC. The name of the powergate node | |
| 131 | −should be one of the below. Note that not every powergate is applicable | |
| 132 | −to all Tegra devices and the following list shows which powergates are | |
| 133 | −applicable to which devices. Please refer to the Tegra TRM for more | |
| 134 | −details on the various powergates. | |
| 135 | − | |
| 136 | − Name Description Devices Applicable | |
| 137 | − 3d 3D Graphics Tegra20/114/124/210 | |
| 138 | − 3d0 3D Graphics 0 Tegra30 | |
| 139 | − 3d1 3D Graphics 1 Tegra30 | |
| 140 | − aud Audio Tegra210 | |
| 141 | − dfd Debug Tegra210 | |
| 142 | − dis Display A Tegra114/124/210 | |
| 143 | − disb Display B Tegra114/124/210 | |
| 144 | − heg 2D Graphics Tegra30/114/124/210 | |
| 145 | − iram Internal RAM Tegra124/210 | |
| 146 | − mpe MPEG Encode All | |
| 147 | − nvdec NVIDIA Video Decode Engine Tegra210 | |
| 148 | − nvjpg NVIDIA JPEG Engine Tegra210 | |
| 149 | − pcie PCIE Tegra20/30/124/210 | |
| 150 | − sata SATA Tegra30/124/210 | |
| 151 | − sor Display interfaces Tegra124/210 | |
| 152 | − ve2 Video Encode Engine 2 Tegra210 | |
| 153 | − venc Video Encode Engine All | |
| 154 | − vdec Video Decode Engine Tegra20/30/114/124 | |
| 155 | − vic Video Imaging Compositor Tegra124/210 | |
| 156 | − xusba USB Partition A Tegra114/124/210 | |
| 157 | − xusbb USB Partition B Tegra114/124/210 | |
| 158 | − xusbc USB Partition C Tegra114/124/210 | |
| 159 | − | |
| 160 | −Required properties: | |
| 161 | − - clocks: Must contain an entry for each clock required by the PMC for | |
| 162 | − controlling a power-gate. See ../clocks/clock-bindings.txt for details. | |
| 163 | − - resets: Must contain an entry for each reset required by the PMC for | |
| 164 | − controlling a power-gate. See ../reset/reset.txt for details. | |
| 165 | − - #power-domain-cells: Must be 0. | |
| 166 | − | |
| 167 | −Example: | |
| 168 | − | |
| 169 | − pmc: pmc@7000e400 { | |
| 170 | − compatible = "nvidia,tegra210-pmc"; | |
| 171 | − reg = <0x0 0x7000e400 0x0 0x400>; | |
| 172 | − clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>; | |
| 173 | − clock-names = "pclk", "clk32k_in"; | |
| 174 | − | |
| 175 | − powergates { | |
| 176 | − pd_audio: aud { | |
| 177 | − clocks = <&tegra_car TEGRA210_CLK_APE>, | |
| 178 | − <&tegra_car TEGRA210_CLK_APB2APE>; | |
| 179 | − resets = <&tegra_car 198>; | |
| 180 | − #power-domain-cells = <0>; | |
| 181 | − }; | |
| 182 | − }; | |
| 183 | − }; | |
| 184 | − | |
| 185 | − | |
| 186 | −== Powergate Clients == | |
| 187 | − | |
| 188 | −Hardware blocks belonging to a power domain should contain a "power-domains" | |
| 189 | −property that is a phandle pointing to the corresponding powergate node. | |
| 190 | − | |
| 191 | −Example: | |
| 192 | − | |
| 193 | − adma: adma@702e2000 { | |
| 194 | − ... | |
| 195 | − power-domains = <&pd_audio>; | |
| 196 | − ... | |
| 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 | − }; | |
| @@ -0,0 +1,354 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra20-pmc.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Tegra Power Management Controller (PMC) | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Thierry Reding <thierry.reding@gmail.com> | |
| 11 | + - Jonathan Hunter <jonathanh@nvidia.com> | |
| 12 | + | |
| 13 | +properties: | |
| 14 | + compatible: | |
| 15 | + enum: | |
| 16 | + - nvidia,tegra20-pmc | |
| 17 | + - nvidia,tegra20-pmc | |
| 18 | + - nvidia,tegra30-pmc | |
| 19 | + - nvidia,tegra114-pmc | |
| 20 | + - nvidia,tegra124-pmc | |
| 21 | + - nvidia,tegra210-pmc | |
| 22 | + | |
| 23 | + reg: | |
| 24 | + maxItems: 1 | |
| 25 | + description: | |
| 26 | + Offset and length of the register set for the device. | |
| 27 | + | |
| 28 | + clock-names: | |
| 29 | + items: | |
| 30 | + - const: pclk | |
| 31 | + - const: clk32k_in | |
| 32 | + description: | |
| 33 | + Must includes entries pclk and clk32k_in. | |
| 34 | + pclk is the Tegra clock of that name and clk32k_in is 32KHz clock | |
| 35 | + input to Tegra. | |
| 36 | + | |
| 37 | + clocks: | |
| 38 | + maxItems: 2 | |
| 39 | + description: | |
| 40 | + Must contain an entry for each entry in clock-names. | |
| 41 | + See ../clocks/clocks-bindings.txt for details. | |
| 42 | + | |
| 43 | + '#clock-cells': | |
| 44 | + const: 1 | |
| 45 | + description: | |
| 46 | + Tegra PMC has clk_out_1, clk_out_2, and clk_out_3. | |
| 47 | + PMC also has blink control which allows 32Khz clock output to | |
| 48 | + Tegra blink pad. | |
| 49 | + Consumer of PMC clock should specify the desired clock by having | |
| 50 | + the clock ID in its "clocks" phandle cell with pmc clock provider. | |
| 51 | + See include/dt-bindings/soc/tegra-pmc.h for the list of Tegra PMC | |
| 52 | + clock IDs. | |
| 53 | + | |
| 54 | + '#interrupt-cells': | |
| 55 | + const: 2 | |
| 56 | + description: | |
| 57 | + Specifies number of cells needed to encode an interrupt source. | |
| 58 | + The value must be 2. | |
| 59 | + | |
| 60 | + interrupt-controller: true | |
| 61 | + | |
| 62 | + nvidia,invert-interrupt: | |
| 63 | + $ref: /schemas/types.yaml#/definitions/flag | |
| 64 | + description: Inverts the PMU interrupt signal. | |
| 65 | + The PMU is an external Power Management Unit, whose interrupt output | |
| 66 | + signal is fed into the PMC. This signal is optionally inverted, and | |
| 67 | + then fed into the ARM GIC. The PMC is not involved in the detection | |
| 68 | + or handling of this interrupt signal, merely its inversion. | |
| 69 | + | |
| 70 | + nvidia,core-power-req-active-high: | |
| 71 | + $ref: /schemas/types.yaml#/definitions/flag | |
| 72 | + description: Core power request active-high. | |
| 73 | + | |
| 74 | + nvidia,sys-clock-req-active-high: | |
| 75 | + $ref: /schemas/types.yaml#/definitions/flag | |
| 76 | + description: System clock request active-high. | |
| 77 | + | |
| 78 | + nvidia,combined-power-req: | |
| 79 | + $ref: /schemas/types.yaml#/definitions/flag | |
| 80 | + description: combined power request for CPU and Core. | |
| 81 | + | |
| 82 | + nvidia,cpu-pwr-good-en: | |
| 83 | + $ref: /schemas/types.yaml#/definitions/flag | |
| 84 | + description: | |
| 85 | + CPU power good signal from external PMIC to PMC is enabled. | |
| 86 | + | |
| 87 | + nvidia,suspend-mode: | |
| 88 | + allOf: | |
| 89 | + - $ref: /schemas/types.yaml#/definitions/uint32 | |
| 90 | + - enum: [0, 1, 2] | |
| 91 | + description: | |
| 92 | + The suspend mode that the platform should use. | |
| 93 | + Mode 0 is for LP0, CPU + Core voltage off and DRAM in self-refresh | |
| 94 | + Mode 1 is for LP1, CPU voltage off and DRAM in self-refresh | |
| 95 | + Mode 2 is for LP2, CPU voltage off | |
| 96 | + | |
| 97 | + nvidia,cpu-pwr-good-time: | |
| 98 | + $ref: /schemas/types.yaml#/definitions/uint32 | |
| 99 | + description: CPU power good time in uSec. | |
| 100 | + | |
| 101 | + nvidia,cpu-pwr-off-time: | |
| 102 | + $ref: /schemas/types.yaml#/definitions/uint32 | |
| 103 | + description: CPU power off time in uSec. | |
| 104 | + | |
| 105 | + nvidia,core-pwr-good-time: | |
| 106 | + $ref: /schemas/types.yaml#/definitions/uint32-array | |
| 107 | + description: | |
| 108 | + <Oscillator-stable-time Power-stable-time> | |
| 109 | + Core power good time in uSec. | |
| 110 | + | |
| 111 | + nvidia,core-pwr-off-time: | |
| 112 | + $ref: /schemas/types.yaml#/definitions/uint32 | |
| 113 | + description: Core power off time in uSec. | |
| 114 | + | |
| 115 | + nvidia,lp0-vec: | |
| 116 | + $ref: /schemas/types.yaml#/definitions/uint32-array | |
| 117 | + description: | |
| 118 | + <start length> Starting address and length of LP0 vector. | |
| 119 | + The LP0 vector contains the warm boot code that is executed | |
| 120 | + by AVP when resuming from the LP0 state. | |
| 121 | + The AVP (Audio-Video Processor) is an ARM7 processor and | |
| 122 | + always being the first boot processor when chip is power on | |
| 123 | + or resume from deep sleep mode. When the system is resumed | |
| 124 | + from the deep sleep mode, the warm boot code will restore | |
| 125 | + some PLLs, clocks and then brings up CPU0 for resuming the | |
| 126 | + system. | |
| 127 | + | |
| 128 | + i2c-thermtrip: | |
| 129 | + type: object | |
| 130 | + description: | |
| 131 | + On Tegra30, Tegra114 and Tegra124 if i2c-thermtrip subnode exists, | |
| 132 | + hardware-triggered thermal reset will be enabled. | |
| 133 | + | |
| 134 | + properties: | |
| 135 | + nvidia,i2c-controller-id: | |
| 136 | + $ref: /schemas/types.yaml#/definitions/uint32 | |
| 137 | + description: | |
| 138 | + ID of I2C controller to send poweroff command to PMU. | |
| 139 | + Valid values are described in section 9.2.148 | |
| 140 | + "APBDEV_PMC_SCRATCH53_0" of the Tegra K1 Technical Reference | |
| 141 | + Manual. | |
| 142 | + | |
| 143 | + nvidia,bus-addr: | |
| 144 | + $ref: /schemas/types.yaml#/definitions/uint32 | |
| 145 | + description: Bus address of the PMU on the I2C bus. | |
| 146 | + | |
| 147 | + nvidia,reg-addr: | |
| 148 | + $ref: /schemas/types.yaml#/definitions/uint32 | |
| 149 | + description: PMU I2C register address to issue poweroff command. | |
| 150 | + | |
| 151 | + nvidia,reg-data: | |
| 152 | + $ref: /schemas/types.yaml#/definitions/uint32 | |
| 153 | + description: Poweroff command to write to PMU. | |
| 154 | + | |
| 155 | + nvidia,pinmux-id: | |
| 156 | + $ref: /schemas/types.yaml#/definitions/uint32 | |
| 157 | + description: | |
| 158 | + Pinmux used by the hardware when issuing Poweroff command. | |
| 159 | + Defaults to 0. Valid values are described in section 12.5.2 | |
| 160 | + "Pinmux Support" of the Tegra4 Technical Reference Manual. | |
| 161 | + | |
| 162 | + required: | |
| 163 | + - nvidia,i2c-controller-id | |
| 164 | + - nvidia,bus-addr | |
| 165 | + - nvidia,reg-addr | |
| 166 | + - nvidia,reg-data | |
| 167 | + | |
| 168 | + additionalProperties: false | |
| 169 | + | |
| 170 | + powergates: | |
| 171 | + type: object | |
| 172 | + description: | | |
| 173 | + This node contains a hierarchy of power domain nodes, which should | |
| 174 | + match the powergates on the Tegra SoC. Each powergate node | |
| 175 | + represents a power-domain on the Tegra SoC that can be power-gated | |
| 176 | + by the Tegra PMC. | |
| 177 | + Hardware blocks belonging to a power domain should contain | |
| 178 | + "power-domains" property that is a phandle pointing to corresponding | |
| 179 | + powergate node. | |
| 180 | + The name of the powergate node should be one of the below. Note that | |
| 181 | + not every powergate is applicable to all Tegra devices and the following | |
| 182 | + list shows which powergates are applicable to which devices. | |
| 183 | + Please refer to Tegra TRM for mode details on the powergate nodes to | |
| 184 | + use for each power-gate block inside Tegra. | |
| 185 | + Name Description Devices Applicable | |
| 186 | + 3d 3D Graphics Tegra20/114/124/210 | |
| 187 | + 3d0 3D Graphics 0 Tegra30 | |
| 188 | + 3d1 3D Graphics 1 Tegra30 | |
| 189 | + aud Audio Tegra210 | |
| 190 | + dfd Debug Tegra210 | |
| 191 | + dis Display A Tegra114/124/210 | |
| 192 | + disb Display B Tegra114/124/210 | |
| 193 | + heg 2D Graphics Tegra30/114/124/210 | |
| 194 | + iram Internal RAM Tegra124/210 | |
| 195 | + mpe MPEG Encode All | |
| 196 | + nvdec NVIDIA Video Decode Engine Tegra210 | |
| 197 | + nvjpg NVIDIA JPEG Engine Tegra210 | |
| 198 | + pcie PCIE Tegra20/30/124/210 | |
| 199 | + sata SATA Tegra30/124/210 | |
| 200 | + sor Display interfaces Tegra124/210 | |
| 201 | + ve2 Video Encode Engine 2 Tegra210 | |
| 202 | + venc Video Encode Engine All | |
| 203 | + vdec Video Decode Engine Tegra20/30/114/124 | |
| 204 | + vic Video Imaging Compositor Tegra124/210 | |
| 205 | + xusba USB Partition A Tegra114/124/210 | |
| 206 | + xusbb USB Partition B Tegra114/124/210 | |
| 207 | + xusbc USB Partition C Tegra114/124/210 | |
| 208 | + | |
| 209 | + patternProperties: | |
| 210 | + "^[a-z0-9]+$": | |
| 211 | + type: object | |
| 212 | + | |
| 213 | + patternProperties: | |
| 214 | + clocks: | |
| 215 | + minItems: 1 | |
| 216 | + maxItems: 8 | |
| 217 | + description: | |
| 218 | + Must contain an entry for each clock required by the PMC | |
| 219 | + for controlling a power-gate. | |
| 220 | + See ../clocks/clock-bindings.txt document for more details. | |
| 221 | + | |
| 222 | + resets: | |
| 223 | + minItems: 1 | |
| 224 | + maxItems: 8 | |
| 225 | + description: | |
| 226 | + Must contain an entry for each reset required by the PMC | |
| 227 | + for controlling a power-gate. | |
| 228 | + See ../reset/reset.txt for more details. | |
| 229 | + | |
| 230 | + '#power-domain-cells': | |
| 231 | + const: 0 | |
| 232 | + description: Must be 0. | |
| 233 | + | |
| 234 | + required: | |
| 235 | + - clocks | |
| 236 | + - resets | |
| 237 | + - '#power-domain-cells' | |
| 238 | + | |
| 239 | + additionalProperties: false | |
| 240 | + | |
| 241 | +patternProperties: | |
| 242 | + "^[a-f0-9]+-[a-f0-9]+$": | |
| 243 | + type: object | |
| 244 | + description: | |
| 245 | + This is a Pad configuration node. On Tegra SOCs a pad is a set of | |
| 246 | + pins which are configured as a group. The pin grouping is a fixed | |
| 247 | + attribute of the hardware. The PMC can be used to set pad power state | |
| 248 | + and signaling voltage. A pad can be either in active or power down mode. | |
| 249 | + The support for power state and signaling voltage configuration varies | |
| 250 | + depending on the pad in question. 3.3V and 1.8V signaling voltages | |
| 251 | + are supported on pins where software controllable signaling voltage | |
| 252 | + switching is available. | |
| 253 | + | |
| 254 | + The pad configuration state nodes are placed under the pmc node and they | |
| 255 | + are referred to by the pinctrl client properties. For more information | |
| 256 | + see Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt. | |
| 257 | + The pad name should be used as the value of the pins property in pin | |
| 258 | + configuration nodes. | |
| 259 | + | |
| 260 | + The following pads are present on Tegra124 and Tegra132 | |
| 261 | + audio, bb, cam, comp, csia, csb, cse, dsi, dsib, dsic, dsid, hdmi, hsic, | |
| 262 | + hv, lvds, mipi-bias, nand, pex-bias, pex-clk1, pex-clk2, pex-cntrl, | |
| 263 | + sdmmc1, sdmmc3, sdmmc4, sys_ddc, uart, usb0, usb1, usb2, usb_bias. | |
| 264 | + | |
| 265 | + The following pads are present on Tegra210 | |
| 266 | + audio, audio-hv, cam, csia, csib, csic, csid, csie, csif, dbg, | |
| 267 | + debug-nonao, dmic, dp, dsi, dsib, dsic, dsid, emmc, emmc2, gpio, hdmi, | |
| 268 | + hsic, lvds, mipi-bias, pex-bias, pex-clk1, pex-clk2, pex-cntrl, sdmmc1, | |
| 269 | + sdmmc3, spi, spi-hv, uart, usb0, usb1, usb2, usb3, usb-bias. | |
| 270 | + | |
| 271 | + properties: | |
| 272 | + pins: | |
| 273 | + $ref: /schemas/types.yaml#/definitions/string | |
| 274 | + description: Must contain name of the pad(s) to be configured. | |
| 275 | + | |
| 276 | + low-power-enable: | |
| 277 | + $ref: /schemas/types.yaml#/definitions/flag | |
| 278 | + description: Configure the pad into power down mode. | |
| 279 | + | |
| 280 | + low-power-disable: | |
| 281 | + $ref: /schemas/types.yaml#/definitions/flag | |
| 282 | + description: Configure the pad into active mode. | |
| 283 | + | |
| 284 | + power-source: | |
| 285 | + $ref: /schemas/types.yaml#/definitions/uint32 | |
| 286 | + description: | |
| 287 | + Must contain either TEGRA_IO_PAD_VOLTAGE_1V8 or | |
| 288 | + TEGRA_IO_PAD_VOLTAGE_3V3 to select between signaling voltages. | |
| 289 | + The values are defined in | |
| 290 | + include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h. | |
| 291 | + Power state can be configured on all Tegra124 and Tegra132 | |
| 292 | + pads. None of the Tegra124 or Tegra132 pads support signaling | |
| 293 | + voltage switching. | |
| 294 | + All of the listed Tegra210 pads except pex-cntrl support power | |
| 295 | + state configuration. Signaling voltage switching is supported | |
| 296 | + on below Tegra210 pads. | |
| 297 | + audio, audio-hv, cam, dbg, dmic, gpio, pex-cntrl, sdmmc1, | |
| 298 | + sdmmc3, spi, spi-hv, and uart. | |
| 299 | + | |
| 300 | + required: | |
| 301 | + - pins | |
| 302 | + | |
| 303 | + additionalProperties: false | |
| 304 | + | |
| 305 | +required: | |
| 306 | + - compatible | |
| 307 | + - reg | |
| 308 | + - clock-names | |
| 309 | + - clocks | |
| 310 | + - '#clock-cells' | |
| 311 | + | |
| 312 | +dependencies: | |
| 313 | + "nvidia,suspend-mode": ["nvidia,core-pwr-off-time", "nvidia,cpu-pwr-off-time"] | |
| 314 | + "nvidia,core-pwr-off-time": ["nvidia,core-pwr-good-time"] | |
| 315 | + "nvidia,cpu-pwr-off-time": ["nvidia,cpu-pwr-good-time"] | |
| 316 | + | |
| 317 | +examples: | |
| 318 | + - | | |
| 319 | + | |
| 320 | + #include <dt-bindings/clock/tegra210-car.h> | |
| 321 | + #include <dt-bindings/pinctrl/pinctrl-tegra-io-pad.h> | |
| 322 | + #include <dt-bindings/soc/tegra-pmc.h> | |
| 323 | + | |
| 324 | + tegra_pmc: pmc@7000e400 { | |
| 325 | + compatible = "nvidia,tegra210-pmc"; | |
| 326 | + reg = <0x0 0x7000e400 0x0 0x400>; | |
| 327 | + clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>; | |
| 328 | + clock-names = "pclk", "clk32k_in"; | |
| 329 | + #clock-cells = <1>; | |
| 330 | + | |
| 331 | + nvidia,invert-interrupt; | |
| 332 | + nvidia,suspend-mode = <0>; | |
| 333 | + nvidia,cpu-pwr-good-time = <0>; | |
| 334 | + nvidia,cpu-pwr-off-time = <0>; | |
| 335 | + nvidia,core-pwr-good-time = <4587 3876>; | |
| 336 | + nvidia,core-pwr-off-time = <39065>; | |
| 337 | + nvidia,core-power-req-active-high; | |
| 338 | + nvidia,sys-clock-req-active-high; | |
| 339 | + | |
| 340 | + powergates { | |
| 341 | + pd_audio: aud { | |
| 342 | + clocks = <&tegra_car TEGRA210_CLK_APE>, | |
| 343 | + <&tegra_car TEGRA210_CLK_APB2APE>; | |
| 344 | + resets = <&tegra_car 198>; | |
| 345 | + #power-domain-cells = <0>; | |
| 346 | + }; | |
| 347 | + | |
| 348 | + pd_xusbss: xusba { | |
| 349 | + clocks = <&tegra_car TEGRA210_CLK_XUSB_SS>; | |
| 350 | + resets = <&tegra_car TEGRA210_CLK_XUSB_SS>; | |
| 351 | + #power-domain-cells = <0>; | |
| 352 | + }; | |
| 353 | + }; | |
| 354 | + }; | |
| @@ -1,229 +0,0 @@ | ||
| 1 | −ARM Versatile Express boards family | |
| 2 | −----------------------------------- | |
| 3 | − | |
| 4 | −ARM's Versatile Express platform consists of a motherboard and one | |
| 5 | −or more daughterboards (tiles). The motherboard provides a set of | |
| 6 | −peripherals. Processor and RAM "live" on the tiles. | |
| 7 | − | |
| 8 | −The motherboard and each core tile should be described by a separate | |
| 9 | −Device Tree source file, with the tile's description including | |
| 10 | −the motherboard file using a /include/ directive. As the motherboard | |
| 11 | −can be initialized in one of two different configurations ("memory | |
| 12 | −maps"), care must be taken to include the correct one. | |
| 13 | − | |
| 14 | − | |
| 15 | −Root node | |
| 16 | −--------- | |
| 17 | − | |
| 18 | −Required properties in the root node: | |
| 19 | −- compatible value: | |
| 20 | − compatible = "arm,vexpress,<model>", "arm,vexpress"; | |
| 21 | − where <model> is the full tile model name (as used in the tile's | |
| 22 | − Technical Reference Manual), eg.: | |
| 23 | − - for Coretile Express A5x2 (V2P-CA5s): | |
| 24 | − compatible = "arm,vexpress,v2p-ca5s", "arm,vexpress"; | |
| 25 | − - for Coretile Express A9x4 (V2P-CA9): | |
| 26 | − compatible = "arm,vexpress,v2p-ca9", "arm,vexpress"; | |
| 27 | − If a tile comes in several variants or can be used in more then one | |
| 28 | − configuration, the compatible value should be: | |
| 29 | − compatible = "arm,vexpress,<model>,<variant>", \ | |
| 30 | − "arm,vexpress,<model>", "arm,vexpress"; | |
| 31 | − eg: | |
| 32 | − - Coretile Express A15x2 (V2P-CA15) with Tech Chip 1: | |
| 33 | − compatible = "arm,vexpress,v2p-ca15,tc1", \ | |
| 34 | − "arm,vexpress,v2p-ca15", "arm,vexpress"; | |
| 35 | − - LogicTile Express 13MG (V2F-2XV6) running Cortex-A7 (3 cores) SMM: | |
| 36 | − compatible = "arm,vexpress,v2f-2xv6,ca7x3", \ | |
| 37 | − "arm,vexpress,v2f-2xv6", "arm,vexpress"; | |
| 38 | − | |
| 39 | −Optional properties in the root node: | |
| 40 | −- tile model name (use name from the tile's Technical Reference | |
| 41 | − Manual, eg. "V2P-CA5s") | |
| 42 | − model = "<model>"; | |
| 43 | −- tile's HBI number (unique ARM's board model ID, visible on the | |
| 44 | − PCB's silkscreen) in hexadecimal transcription: | |
| 45 | − arm,hbi = <0xhbi> | |
| 46 | − eg: | |
| 47 | − - for Coretile Express A5x2 (V2P-CA5s) HBI-0191: | |
| 48 | − arm,hbi = <0x191>; | |
| 49 | − - Coretile Express A9x4 (V2P-CA9) HBI-0225: | |
| 50 | − arm,hbi = <0x225>; | |
| 51 | − | |
| 52 | − | |
| 53 | −CPU nodes | |
| 54 | −--------- | |
| 55 | − | |
| 56 | −Top-level standard "cpus" node is required. It must contain a node | |
| 57 | −with device_type = "cpu" property for every available core, eg.: | |
| 58 | − | |
| 59 | − cpus { | |
| 60 | − #address-cells = <1>; | |
| 61 | − #size-cells = <0>; | |
| 62 | − | |
| 63 | − cpu@0 { | |
| 64 | − device_type = "cpu"; | |
| 65 | − compatible = "arm,cortex-a5"; | |
| 66 | − reg = <0>; | |
| 67 | − }; | |
| 68 | − }; | |
| 69 | − | |
| 70 | − | |
| 71 | −Configuration infrastructure | |
| 72 | −---------------------------- | |
| 73 | − | |
| 74 | −The platform has an elaborated configuration system, consisting of | |
| 75 | −microcontrollers residing on the mother- and daughterboards known | |
| 76 | −as Motherboard/Daughterboard Configuration Controller (MCC and DCC). | |
| 77 | −The controllers are responsible for the platform initialization | |
| 78 | −(reset generation, flash programming, FPGA bitfiles loading etc.) | |
| 79 | −but also control clock generators, voltage regulators, gather | |
| 80 | −environmental data like temperature, power consumption etc. Even | |
| 81 | −the video output switch (FPGA) is controlled that way. | |
| 82 | − | |
| 83 | −The controllers are not mapped into normal memory address space | |
| 84 | −and must be accessed through bridges - other devices capable | |
| 85 | −of generating transactions on the configuration bus. | |
| 86 | − | |
| 87 | −The nodes describing configuration controllers must define | |
| 88 | −the following properties: | |
| 89 | −- compatible value: | |
| 90 | − compatible = "arm,vexpress,config-bus"; | |
| 91 | −- bridge phandle: | |
| 92 | − arm,vexpress,config-bridge = <phandle>; | |
| 93 | −and children describing available functions. | |
| 94 | − | |
| 95 | − | |
| 96 | −Platform topology | |
| 97 | −----------------- | |
| 98 | − | |
| 99 | −As Versatile Express can be configured in number of physically | |
| 100 | −different setups, the device tree should describe platform topology. | |
| 101 | −Root node and main motherboard node must define the following | |
| 102 | −property, describing physical location of the children nodes: | |
| 103 | −- site number: | |
| 104 | − arm,vexpress,site = <number>; | |
| 105 | − where 0 means motherboard, 1 or 2 are daugtherboard sites, | |
| 106 | − 0xf means "master" site (site containing main CPU tile) | |
| 107 | −- when daughterboards are stacked on one site, their position | |
| 108 | − in the stack be be described with: | |
| 109 | − arm,vexpress,position = <number>; | |
| 110 | −- when describing tiles consisting more than one DCC, its number | |
| 111 | − can be described with: | |
| 112 | − arm,vexpress,dcc = <number>; | |
| 113 | − | |
| 114 | −Any of the numbers above defaults to zero if not defined in | |
| 115 | −the node or any of its parent. | |
| 116 | − | |
| 117 | − | |
| 118 | −Motherboard | |
| 119 | −----------- | |
| 120 | − | |
| 121 | −The motherboard description file provides a single "motherboard" node | |
| 122 | −using 2 address cells corresponding to the Static Memory Bus used | |
| 123 | −between the motherboard and the tile. The first cell defines the Chip | |
| 124 | −Select (CS) line number, the second cell address offset within the CS. | |
| 125 | −All interrupt lines between the motherboard and the tile are active | |
| 126 | −high and are described using single cell. | |
| 127 | − | |
| 128 | −Optional properties of the "motherboard" node: | |
| 129 | −- motherboard's memory map variant: | |
| 130 | − arm,v2m-memory-map = "<name>"; | |
| 131 | − where name is one of: | |
| 132 | − - "rs1" - for RS1 map (i.a. peripherals on CS3); this map is also | |
| 133 | − referred to as "ARM Cortex-A Series memory map": | |
| 134 | − arm,v2m-memory-map = "rs1"; | |
| 135 | − When this property is missing, the motherboard is using the original | |
| 136 | − memory map (also known as the "Legacy memory map", primarily used | |
| 137 | − with the original CoreTile Express A9x4) with peripherals on CS7. | |
| 138 | − | |
| 139 | −Motherboard .dtsi files provide a set of labelled peripherals that | |
| 140 | −can be used to obtain required phandle in the tile's "aliases" node: | |
| 141 | −- UARTs, note that the numbers correspond to the physical connectors | |
| 142 | − on the motherboard's back panel: | |
| 143 | − v2m_serial0, v2m_serial1, v2m_serial2 and v2m_serial3 | |
| 144 | −- I2C controllers: | |
| 145 | − v2m_i2c_dvi and v2m_i2c_pcie | |
| 146 | −- SP804 timers: | |
| 147 | − v2m_timer01 and v2m_timer23 | |
| 148 | − | |
| 149 | −The tile description should define a "smb" node, describing the | |
| 150 | −Static Memory Bus between the tile and motherboard. It must define | |
| 151 | −the following properties: | |
| 152 | −- "simple-bus" compatible value (to ensure creation of the children) | |
| 153 | − compatible = "simple-bus"; | |
| 154 | −- mapping of the SMB CS/offset addresses into main address space: | |
| 155 | − #address-cells = <2>; | |
| 156 | − #size-cells = <1>; | |
| 157 | − ranges = <...>; | |
| 158 | −- interrupts mapping: | |
| 159 | − #interrupt-cells = <1>; | |
| 160 | − interrupt-map-mask = <0 0 63>; | |
| 161 | − interrupt-map = <...>; | |
| 162 | − | |
| 163 | − | |
| 164 | −Example of a VE tile description (simplified) | |
| 165 | −--------------------------------------------- | |
| 166 | − | |
| 167 | −/dts-v1/; | |
| 168 | − | |
| 169 | −/ { | |
| 170 | − model = "V2P-CA5s"; | |
| 171 | − arm,hbi = <0x225>; | |
| 172 | − arm,vexpress,site = <0xf>; | |
| 173 | − compatible = "arm,vexpress-v2p-ca5s", "arm,vexpress"; | |
| 174 | − interrupt-parent = <&gic>; | |
| 175 | − #address-cells = <1>; | |
| 176 | − #size-cells = <1>; | |
| 177 | − | |
| 178 | − chosen { }; | |
| 179 | − | |
| 180 | − aliases { | |
| 181 | − serial0 = &v2m_serial0; | |
| 182 | − }; | |
| 183 | − | |
| 184 | − cpus { | |
| 185 | − #address-cells = <1>; | |
| 186 | − #size-cells = <0>; | |
| 187 | − | |
| 188 | − cpu@0 { | |
| 189 | − device_type = "cpu"; | |
| 190 | − compatible = "arm,cortex-a5"; | |
| 191 | − reg = <0>; | |
| 192 | − }; | |
| 193 | − }; | |
| 194 | − | |
| 195 | − gic: interrupt-controller@2c001000 { | |
| 196 | − compatible = "arm,cortex-a9-gic"; | |
| 197 | − #interrupt-cells = <3>; | |
| 198 | − #address-cells = <0>; | |
| 199 | − interrupt-controller; | |
| 200 | − reg = <0x2c001000 0x1000>, | |
| 201 | − <0x2c000100 0x100>; | |
| 202 | − }; | |
| 203 | − | |
| 204 | − dcc { | |
| 205 | − compatible = "arm,vexpress,config-bus"; | |
| 206 | − arm,vexpress,config-bridge = <&v2m_sysreg>; | |
| 207 | − | |
| 208 | − osc@0 { | |
| 209 | − compatible = "arm,vexpress-osc"; | |
| 210 | − }; | |
| 211 | − }; | |
| 212 | − | |
| 213 | − smb { | |
| 214 | − compatible = "simple-bus"; | |
| 215 | − | |
| 216 | − #address-cells = <2>; | |
| 217 | − #size-cells = <1>; | |
| 218 | − /* CS0 is visible at 0x08000000 */ | |
| 219 | − ranges = <0 0 0x08000000 0x04000000>; | |
| 220 | − | |
| 221 | − #interrupt-cells = <1>; | |
| 222 | − interrupt-map-mask = <0 0 63>; | |
| 223 | − /* Active high IRQ 0 is connected to GIC's SPI0 */ | |
| 224 | − interrupt-map = <0 0 0 &gic 0 0 4>; | |
| 225 | − | |
| 226 | − /include/ "vexpress-v2m-rs1.dtsi" | |
| 227 | − }; | |
| 228 | −}; | |
| 229 | − | |
| @@ -0,0 +1,71 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: "http://devicetree.org/schemas/ata/renesas,rcar-sata.yaml#" | |
| 5 | +$schema: "http://devicetree.org/meta-schemas/core.yaml#" | |
| 6 | + | |
| 7 | +title: Renesas R-Car Serial-ATA Interface | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Geert Uytterhoeven <geert+renesas@glider.be> | |
| 11 | + | |
| 12 | +properties: | |
| 13 | + compatible: | |
| 14 | + oneOf: | |
| 15 | + - items: | |
| 16 | + - enum: | |
| 17 | + - renesas,sata-r8a7779 # R-Car H1 | |
| 18 | + - items: | |
| 19 | + - enum: | |
| 20 | + - renesas,sata-r8a7790-es1 # R-Car H2 ES1 | |
| 21 | + - renesas,sata-r8a7790 # R-Car H2 other than ES1 | |
| 22 | + - renesas,sata-r8a7791 # R-Car M2-W | |
| 23 | + - renesas,sata-r8a7793 # R-Car M2-N | |
| 24 | + - const: renesas,rcar-gen2-sata # generic R-Car Gen2 | |
| 25 | + - items: | |
| 26 | + - enum: | |
| 27 | + - renesas,sata-r8a774b1 # RZ/G2N | |
| 28 | + - renesas,sata-r8a7795 # R-Car H3 | |
| 29 | + - renesas,sata-r8a77965 # R-Car M3-N | |
| 30 | + - const: renesas,rcar-gen3-sata # generic R-Car Gen3 or RZ/G2 | |
| 31 | + | |
| 32 | + reg: | |
| 33 | + maxItems: 1 | |
| 34 | + | |
| 35 | + interrupts: | |
| 36 | + maxItems: 1 | |
| 37 | + | |
| 38 | + clocks: | |
| 39 | + maxItems: 1 | |
| 40 | + | |
| 41 | + iommus: | |
| 42 | + maxItems: 1 | |
| 43 | + | |
| 44 | + power-domains: | |
| 45 | + maxItems: 1 | |
| 46 | + | |
| 47 | + resets: | |
| 48 | + maxItems: 1 | |
| 49 | + | |
| 50 | +required: | |
| 51 | + - compatible | |
| 52 | + - reg | |
| 53 | + - interrupts | |
| 54 | + - clocks | |
| 55 | + | |
| 56 | +additionalProperties: false | |
| 57 | + | |
| 58 | +examples: | |
| 59 | + - | | |
| 60 | + #include <dt-bindings/clock/r8a7791-cpg-mssr.h> | |
| 61 | + #include <dt-bindings/interrupt-controller/arm-gic.h> | |
| 62 | + #include <dt-bindings/power/r8a7791-sysc.h> | |
| 63 | + | |
| 64 | + sata@ee300000 { | |
| 65 | + compatible = "renesas,sata-r8a7791", "renesas,rcar-gen2-sata"; | |
| 66 | + reg = <0xee300000 0x200000>; | |
| 67 | + interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>; | |
| 68 | + clocks = <&cpg CPG_MOD 815>; | |
| 69 | + power-domains = <&sysc R8A7791_PD_ALWAYS_ON>; | |
| 70 | + resets = <&cpg 815>; | |
| 71 | + }; | |
| @@ -1,36 +0,0 @@ | ||
| 1 | −* Renesas R-Car SATA | |
| 2 | − | |
| 3 | −Required properties: | |
| 4 | −- compatible : should contain one or more of the following: | |
| 5 | − - "renesas,sata-r8a774b1" for RZ/G2N | |
| 6 | − - "renesas,sata-r8a7779" for R-Car H1 | |
| 7 | − - "renesas,sata-r8a7790-es1" for R-Car H2 ES1 | |
| 8 | − - "renesas,sata-r8a7790" for R-Car H2 other than ES1 | |
| 9 | − - "renesas,sata-r8a7791" for R-Car M2-W | |
| 10 | − - "renesas,sata-r8a7793" for R-Car M2-N | |
| 11 | − - "renesas,sata-r8a7795" for R-Car H3 | |
| 12 | − - "renesas,sata-r8a77965" for R-Car M3-N | |
| 13 | − - "renesas,rcar-gen2-sata" for a generic R-Car Gen2 | |
| 14 | − compatible device | |
| 15 | − - "renesas,rcar-gen3-sata" for a generic R-Car Gen3 or | |
| 16 | − RZ/G2 compatible device | |
| 17 | − - "renesas,rcar-sata" is deprecated | |
| 18 | − | |
| 19 | − When compatible with the generic version nodes | |
| 20 | − must list the SoC-specific version corresponding | |
| 21 | − to the platform first followed by the generic | |
| 22 | − version. | |
| 23 | − | |
| 24 | −- reg : address and length of the SATA registers; | |
| 25 | −- interrupts : must consist of one interrupt specifier. | |
| 26 | −- clocks : must contain a reference to the functional clock. | |
| 27 | − | |
| 28 | −Example: | |
| 29 | − | |
| 30 | −sata0: sata@ee300000 { | |
| 31 | − compatible = "renesas,sata-r8a7791", "renesas,rcar-gen2-sata"; | |
| 32 | − reg = <0 0xee300000 0 0x2000>; | |
| 33 | − interrupt-parent = <&gic>; | |
| 34 | − interrupts = <0 105 IRQ_TYPE_LEVEL_HIGH>; | |
| 35 | − clocks = <&mstp8_clks R8A7791_CLK_SATA0>; | |
| 36 | −}; | |
| @@ -0,0 +1,96 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/bus/socionext,uniphier-system-bus.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: UniPhier System Bus | |
| 8 | + | |
| 9 | +description: | | |
| 10 | + The UniPhier System Bus is an external bus that connects on-board devices to | |
| 11 | + the UniPhier SoC. It is a simple (semi-)parallel bus with address, data, and | |
| 12 | + some control signals. It supports up to 8 banks (chip selects). | |
| 13 | + | |
| 14 | + Before any access to the bus, the bus controller must be configured; the bus | |
| 15 | + controller registers provide the control for the translation from the offset | |
| 16 | + within each bank to the CPU-viewed address. The needed setup includes the | |
| 17 | + base address, the size of each bank. Optionally, some timing parameters can | |
| 18 | + be optimized for faster bus access. | |
| 19 | + | |
| 20 | +maintainers: | |
| 21 | + - Masahiro Yamada <yamada.masahiro@socionext.com> | |
| 22 | + | |
| 23 | +properties: | |
| 24 | + compatible: | |
| 25 | + const: socionext,uniphier-system-bus | |
| 26 | + | |
| 27 | + reg: | |
| 28 | + maxItems: 1 | |
| 29 | + | |
| 30 | + "#address-cells": | |
| 31 | + description: | | |
| 32 | + The first cell is the bank number (chip select). | |
| 33 | + The second cell is the address offset within the bank. | |
| 34 | + const: 2 | |
| 35 | + | |
| 36 | + "#size-cells": | |
| 37 | + const: 1 | |
| 38 | + | |
| 39 | + ranges: | |
| 40 | + description: | | |
| 41 | + Provide address translation from the System Bus to the parent bus. | |
| 42 | + | |
| 43 | + Note: | |
| 44 | + The address region(s) that can be assigned for the System Bus is | |
| 45 | + implementation defined. Some SoCs can use 0x00000000-0x0fffffff and | |
| 46 | + 0x40000000-0x4fffffff, while other SoCs only 0x40000000-0x4fffffff. | |
| 47 | + There might be additional limitations depending on SoCs and the boot mode. | |
| 48 | + The address translation is arbitrary as long as the banks are assigned in | |
| 49 | + the supported address space with the required alignment and they do not | |
| 50 | + overlap one another. | |
| 51 | + | |
| 52 | + For example, it is possible to map: | |
| 53 | + bank 0 to 0x42000000-0x43ffffff, bank 5 to 0x46000000-0x46ffffff | |
| 54 | + It is also possible to map: | |
| 55 | + bank 0 to 0x48000000-0x49ffffff, bank 5 to 0x44000000-0x44ffffff | |
| 56 | + There is no reason to stick to a particular translation mapping, but the | |
| 57 | + "ranges" property should provide a "reasonable" default that is known to | |
| 58 | + work. The software should initialize the bus controller according to it. | |
| 59 | + | |
| 60 | +required: | |
| 61 | + - compatible | |
| 62 | + - reg | |
| 63 | + - "#address-cells" | |
| 64 | + - "#size-cells" | |
| 65 | + - ranges | |
| 66 | + | |
| 67 | +examples: | |
| 68 | + - | | |
| 69 | + // In this example, | |
| 70 | + // - the Ethernet device is connected at the offset 0x01f00000 of CS1 and | |
| 71 | + // mapped to 0x43f00000 of the parent bus. | |
| 72 | + // - the UART device is connected at the offset 0x00200000 of CS5 and | |
| 73 | + // mapped to 0x46200000 of the parent bus. | |
| 74 | + | |
| 75 | + system-bus@58c00000 { | |
| 76 | + compatible = "socionext,uniphier-system-bus"; | |
| 77 | + reg = <0x58c00000 0x400>; | |
| 78 | + #address-cells = <2>; | |
| 79 | + #size-cells = <1>; | |
| 80 | + ranges = <1 0x00000000 0x42000000 0x02000000>, | |
| 81 | + <5 0x00000000 0x46000000 0x01000000>; | |
| 82 | + | |
| 83 | + ethernet@1,01f00000 { | |
| 84 | + compatible = "smsc,lan9115"; | |
| 85 | + reg = <1 0x01f00000 0x1000>; | |
| 86 | + interrupts = <0 48 4>; | |
| 87 | + phy-mode = "mii"; | |
| 88 | + }; | |
| 89 | + | |
| 90 | + uart@5,00200000 { | |
| 91 | + compatible = "ns16550a"; | |
| 92 | + reg = <5 0x00200000 0x20>; | |
| 93 | + interrupts = <0 49 4>; | |
| 94 | + clock-frequency = <12288000>; | |
| 95 | + }; | |
| 96 | + }; | |
| @@ -38,6 +38,7 @@ Required standard properties: · 37 unmodified lines | ||
| 38 | 38 | "ti,sysc-dra7-mcasp" |
| 39 | 39 | "ti,sysc-usb-host-fs" |
| 40 | 40 | "ti,sysc-dra7-mcan" |
| 41 | + "ti,sysc-pruss" | |
| 41 | 42 | |
| 42 | 43 | - reg shall have register areas implemented for the interconnect |
| 43 | 44 | target module in question such as revision, sysc and syss |
| @@ -1,66 +0,0 @@ | ||
| 1 | −UniPhier System Bus | |
| 2 | − | |
| 3 | −The UniPhier System Bus is an external bus that connects on-board devices to | |
| 4 | −the UniPhier SoC. It is a simple (semi-)parallel bus with address, data, and | |
| 5 | −some control signals. It supports up to 8 banks (chip selects). | |
| 6 | − | |
| 7 | −Before any access to the bus, the bus controller must be configured; the bus | |
| 8 | −controller registers provide the control for the translation from the offset | |
| 9 | −within each bank to the CPU-viewed address. The needed setup includes the base | |
| 10 | −address, the size of each bank. Optionally, some timing parameters can be | |
| 11 | −optimized for faster bus access. | |
| 12 | − | |
| 13 | −Required properties: | |
| 14 | −- compatible: should be "socionext,uniphier-system-bus". | |
| 15 | −- reg: offset and length of the register set for the bus controller device. | |
| 16 | −- #address-cells: should be 2. The first cell is the bank number (chip select). | |
| 17 | − The second cell is the address offset within the bank. | |
| 18 | −- #size-cells: should be 1. | |
| 19 | −- ranges: should provide a proper address translation from the System Bus to | |
| 20 | − the parent bus. | |
| 21 | − | |
| 22 | −Note: | |
| 23 | −The address region(s) that can be assigned for the System Bus is implementation | |
| 24 | −defined. Some SoCs can use 0x00000000-0x0fffffff and 0x40000000-0x4fffffff, | |
| 25 | −while other SoCs can only use 0x40000000-0x4fffffff. There might be additional | |
| 26 | −limitations depending on SoCs and the boot mode. The address translation is | |
| 27 | −arbitrary as long as the banks are assigned in the supported address space with | |
| 28 | −the required alignment and they do not overlap one another. | |
| 29 | −For example, it is possible to map: | |
| 30 | − bank 0 to 0x42000000-0x43ffffff, bank 5 to 0x46000000-0x46ffffff | |
| 31 | −It is also possible to map: | |
| 32 | − bank 0 to 0x48000000-0x49ffffff, bank 5 to 0x44000000-0x44ffffff | |
| 33 | −There is no reason to stick to a particular translation mapping, but the | |
| 34 | −"ranges" property should provide a "reasonable" default that is known to work. | |
| 35 | −The software should initialize the bus controller according to it. | |
| 36 | − | |
| 37 | −Example: | |
| 38 | − | |
| 39 | − system-bus { | |
| 40 | − compatible = "socionext,uniphier-system-bus"; | |
| 41 | − reg = <0x58c00000 0x400>; | |
| 42 | − #address-cells = <2>; | |
| 43 | − #size-cells = <1>; | |
| 44 | − ranges = <1 0x00000000 0x42000000 0x02000000 | |
| 45 | − 5 0x00000000 0x46000000 0x01000000>; | |
| 46 | − | |
| 47 | − ethernet@1,01f00000 { | |
| 48 | − compatible = "smsc,lan9115"; | |
| 49 | − reg = <1 0x01f00000 0x1000>; | |
| 50 | − interrupts = <0 48 4> | |
| 51 | − phy-mode = "mii"; | |
| 52 | − }; | |
| 53 | − | |
| 54 | − uart@5,00200000 { | |
| 55 | − compatible = "ns16550a"; | |
| 56 | − reg = <5 0x00200000 0x20>; | |
| 57 | − interrupts = <0 49 4> | |
| 58 | − clock-frequency = <12288000>; | |
| 59 | − }; | |
| 60 | − }; | |
| 61 | − | |
| 62 | −In this example, | |
| 63 | − - the Ethernet device is connected at the offset 0x01f00000 of CS1 and | |
| 64 | − mapped to 0x43f00000 of the parent bus. | |
| 65 | − - the UART device is connected at the offset 0x00200000 of CS5 and | |
| 66 | − mapped to 0x46200000 of the parent bus. | |
| @@ -0,0 +1,54 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/chrome/google,cros-ec-typec.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Google Chrome OS EC(Embedded Controller) Type C port driver. | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Benson Leung <bleung@chromium.org> | |
| 11 | + - Prashant Malani <pmalani@chromium.org> | |
| 12 | + | |
| 13 | +description: | |
| 14 | + Chrome OS devices have an Embedded Controller(EC) which has access to | |
| 15 | + Type C port state. This node is intended to allow the host to read and | |
| 16 | + control the Type C ports. The node for this device should be under a | |
| 17 | + cros-ec node like google,cros-ec-spi. | |
| 18 | + | |
| 19 | +properties: | |
| 20 | + compatible: | |
| 21 | + const: google,cros-ec-typec | |
| 22 | + | |
| 23 | + connector: | |
| 24 | + $ref: /schemas/connector/usb-connector.yaml# | |
| 25 | + | |
| 26 | +required: | |
| 27 | + - compatible | |
| 28 | + | |
| 29 | +examples: | |
| 30 | + - |+ | |
| 31 | + spi0 { | |
| 32 | + #address-cells = <1>; | |
| 33 | + #size-cells = <0>; | |
| 34 | + | |
| 35 | + cros_ec: ec@0 { | |
| 36 | + compatible = "google,cros-ec-spi"; | |
| 37 | + reg = <0>; | |
| 38 | + | |
| 39 | + typec { | |
| 40 | + compatible = "google,cros-ec-typec"; | |
| 41 | + | |
| 42 | + #address-cells = <1>; | |
| 43 | + #size-cells = <0>; | |
| 44 | + | |
| 45 | + connector@0 { | |
| 46 | + compatible = "usb-c-connector"; | |
| 47 | + reg = <0>; | |
| 48 | + power-role = "dual"; | |
| 49 | + data-role = "dual"; | |
| 50 | + try-power-role = "source"; | |
| 51 | + }; | |
| 52 | + }; | |
| 53 | + }; | |
| 54 | + }; | |
| @@ -0,0 +1,103 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/clock/arm,syscon-icst.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: ARM System Controller ICST Clocks | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Linus Walleij <linusw@kernel.org> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + The ICS525 and ICS307 oscillators are produced by Integrated | |
| 14 | + Devices Technology (IDT). ARM integrated these oscillators deeply into their | |
| 15 | + reference designs by adding special control registers that manage such | |
| 16 | + oscillators to their system controllers. | |
| 17 | + | |
| 18 | + The various ARM system controllers contain logic to serialize and initialize | |
| 19 | + an ICST clock request after a write to the 32 bit register at an offset | |
| 20 | + into the system controller. Furthermore, to even be able to alter one of | |
| 21 | + these frequencies, the system controller must first be unlocked by | |
| 22 | + writing a special token to another offset in the system controller. | |
| 23 | + | |
| 24 | + Some ARM hardware contain special versions of the serial interface that only | |
| 25 | + connects the low 8 bits of the VDW (missing one bit), hard-wires RDW to | |
| 26 | + different values and sometimes also hard-wires the output divider. They | |
| 27 | + therefore have special compatible strings as per this table (the OD value is | |
| 28 | + the value on the pins, not the resulting output divider). | |
| 29 | + | |
| 30 | + In the core modules and logic tiles, the ICST is a configurable clock fed | |
| 31 | + from a 24 MHz clock on the motherboard (usually the main crystal) used for | |
| 32 | + generating e.g. video clocks. It is located on the core module and there is | |
| 33 | + only one of these. This clock node must be a subnode of the core module. | |
| 34 | + | |
| 35 | + Hardware variant RDW OD VDW | |
| 36 | + | |
| 37 | + Integrator/AP 22 1 Bit 8 0, rest variable | |
| 38 | + integratorap-cm | |
| 39 | + | |
| 40 | + Integrator/AP 46 3 Bit 8 0, rest variable | |
| 41 | + integratorap-sys | |
| 42 | + | |
| 43 | + Integrator/AP 22 or 1 17 or (33 or 25 MHz) | |
| 44 | + integratorap-pci 14 1 14 | |
| 45 | + | |
| 46 | + Integrator/CP 22 variable Bit 8 0, rest variable | |
| 47 | + integratorcp-cm-core | |
| 48 | + | |
| 49 | + Integrator/CP 22 variable Bit 8 0, rest variable | |
| 50 | + integratorcp-cm-mem | |
| 51 | + | |
| 52 | + The ICST oscillator must be provided inside a system controller node. | |
| 53 | + | |
| 54 | +properties: | |
| 55 | + "#clock-cells": | |
| 56 | + const: 0 | |
| 57 | + | |
| 58 | + compatible: | |
| 59 | + enum: | |
| 60 | + - arm,syscon-icst525 | |
| 61 | + - arm,syscon-icst307 | |
| 62 | + - arm,syscon-icst525-integratorap-cm | |
| 63 | + - arm,syscon-icst525-integratorap-sys | |
| 64 | + - arm,syscon-icst525-integratorap-pci | |
| 65 | + - arm,syscon-icst525-integratorcp-cm-core | |
| 66 | + - arm,syscon-icst525-integratorcp-cm-mem | |
| 67 | + - arm,integrator-cm-auxosc | |
| 68 | + - arm,versatile-cm-auxosc | |
| 69 | + - arm,impd-vco1 | |
| 70 | + - arm,impd-vco2 | |
| 71 | + | |
| 72 | + clocks: | |
| 73 | + description: Parent clock for the ICST VCO | |
| 74 | + maxItems: 1 | |
| 75 | + | |
| 76 | + clock-output-names: | |
| 77 | + maxItems: 1 | |
| 78 | + | |
| 79 | + lock-offset: | |
| 80 | + $ref: '/schemas/types.yaml#/definitions/uint32' | |
| 81 | + description: Offset to the unlocking register for the oscillator | |
| 82 | + | |
| 83 | + vco-offset: | |
| 84 | + $ref: '/schemas/types.yaml#/definitions/uint32' | |
| 85 | + description: Offset to the VCO register for the oscillator | |
| 86 | + | |
| 87 | +required: | |
| 88 | + - "#clock-cells" | |
| 89 | + - compatible | |
| 90 | + - clocks | |
| 91 | + | |
| 92 | +examples: | |
| 93 | + - | | |
| 94 | + vco1: clock@00 { | |
| 95 | + compatible = "arm,impd1-vco1"; | |
| 96 | + #clock-cells = <0>; | |
| 97 | + lock-offset = <0x08>; | |
| 98 | + vco-offset = <0x00>; | |
| 99 | + clocks = <&sysclk>; | |
| 100 | + clock-output-names = "IM-PD1-VCO1"; | |
| 101 | + }; | |
| 102 | + | |
| 103 | +... | |
| @@ -1,34 +0,0 @@ | ||
| 1 | −Clock bindings for ARM Integrator and Versatile Core Module clocks | |
| 2 | − | |
| 3 | −Auxiliary Oscillator Clock | |
| 4 | − | |
| 5 | −This is a configurable clock fed from a 24 MHz chrystal, | |
| 6 | −used for generating e.g. video clocks. It is located on the | |
| 7 | −core module and there is only one of these. | |
| 8 | − | |
| 9 | −This clock node *must* be a subnode of the core module, since | |
| 10 | −it obtains the base address for it's address range from its | |
| 11 | −parent node. | |
| 12 | − | |
| 13 | − | |
| 14 | −Required properties: | |
| 15 | −- compatible: must be "arm,integrator-cm-auxosc" or "arm,versatile-cm-auxosc" | |
| 16 | −- #clock-cells: must be <0> | |
| 17 | − | |
| 18 | −Optional properties: | |
| 19 | −- clocks: parent clock(s) | |
| 20 | − | |
| 21 | −Example: | |
| 22 | − | |
| 23 | −core-module@10000000 { | |
| 24 | − xtal24mhz: xtal24mhz@24M { | |
| 25 | − #clock-cells = <0>; | |
| 26 | − compatible = "fixed-clock"; | |
| 27 | − clock-frequency = <24000000>; | |
| 28 | − }; | |
| 29 | − auxosc: cm_aux_osc@25M { | |
| 30 | − #clock-cells = <0>; | |
| 31 | − compatible = "arm,integrator-cm-auxosc"; | |
| 32 | − clocks = <&xtal24mhz>; | |
| 33 | − }; | |
| 34 | −}; | |
| @@ -1,70 +0,0 @@ | ||
| 1 | −ARM System Controller ICST clocks | |
| 2 | − | |
| 3 | −The ICS525 and ICS307 oscillators are produced by Integrated Devices | |
| 4 | −Technology (IDT). ARM integrated these oscillators deeply into their | |
| 5 | −reference designs by adding special control registers that manage such | |
| 6 | −oscillators to their system controllers. | |
| 7 | − | |
| 8 | −The various ARM system controllers contain logic to serialize and initialize | |
| 9 | −an ICST clock request after a write to the 32 bit register at an offset | |
| 10 | −into the system controller. Furthermore, to even be able to alter one of | |
| 11 | −these frequencies, the system controller must first be unlocked by | |
| 12 | −writing a special token to another offset in the system controller. | |
| 13 | − | |
| 14 | −Some ARM hardware contain special versions of the serial interface that only | |
| 15 | −connects the low 8 bits of the VDW (missing one bit), hardwires RDW to | |
| 16 | −different values and sometimes also hardwire the output divider. They | |
| 17 | −therefore have special compatible strings as per this table (the OD value is | |
| 18 | −the value on the pins, not the resulting output divider): | |
| 19 | − | |
| 20 | −Hardware variant: RDW OD VDW | |
| 21 | − | |
| 22 | −Integrator/AP 22 1 Bit 8 0, rest variable | |
| 23 | −integratorap-cm | |
| 24 | − | |
| 25 | −Integrator/AP 46 3 Bit 8 0, rest variable | |
| 26 | −integratorap-sys | |
| 27 | − | |
| 28 | −Integrator/AP 22 or 1 17 or (33 or 25 MHz) | |
| 29 | −integratorap-pci 14 1 14 | |
| 30 | − | |
| 31 | −Integrator/CP 22 variable Bit 8 0, rest variable | |
| 32 | −integratorcp-cm-core | |
| 33 | − | |
| 34 | −Integrator/CP 22 variable Bit 8 0, rest variable | |
| 35 | −integratorcp-cm-mem | |
| 36 | − | |
| 37 | −The ICST oscillator must be provided inside a system controller node. | |
| 38 | − | |
| 39 | −Required properties: | |
| 40 | −- compatible: must be one of | |
| 41 | − "arm,syscon-icst525" | |
| 42 | − "arm,syscon-icst307" | |
| 43 | − "arm,syscon-icst525-integratorap-cm" | |
| 44 | − "arm,syscon-icst525-integratorap-sys" | |
| 45 | − "arm,syscon-icst525-integratorap-pci" | |
| 46 | − "arm,syscon-icst525-integratorcp-cm-core" | |
| 47 | − "arm,syscon-icst525-integratorcp-cm-mem" | |
| 48 | −- lock-offset: the offset address into the system controller where the | |
| 49 | − unlocking register is located | |
| 50 | −- vco-offset: the offset address into the system controller where the | |
| 51 | − ICST control register is located (even 32 bit address) | |
| 52 | −- #clock-cells: must be <0> | |
| 53 | −- clocks: parent clock, since the ICST needs a parent clock to derive its | |
| 54 | − frequency from, this attribute is compulsory. | |
| 55 | − | |
| 56 | −Example: | |
| 57 | − | |
| 58 | −syscon: syscon@10000000 { | |
| 59 | − compatible = "syscon"; | |
| 60 | − reg = <0x10000000 0x1000>; | |
| 61 | − | |
| 62 | − oscclk0: osc0@c { | |
| 63 | − compatible = "arm,syscon-icst307"; | |
| 64 | − #clock-cells = <0>; | |
| 65 | − lock-offset = <0x20>; | |
| 66 | − vco-offset = <0x0c>; | |
| 67 | − clocks = <&xtal24mhz>; | |
| 68 | − }; | |
| 69 | − (...) | |
| 70 | −}; | |
| @@ -94,7 +94,7 @@ clock is connected to output 0 of the &ref. · 93 unmodified lines | ||
| 94 | 94 | /* external oscillator */ |
| 95 | 95 | osc: oscillator { |
| 96 | 96 | compatible = "fixed-clock"; |
| 97 | − #clock-cells = <1>; | |
| 97 | + #clock-cells = <0>; | |
| 98 | 98 | clock-frequency = <32678>; |
| 99 | 99 | clock-output-names = "osc"; |
| 100 | 100 | }; |
| @@ -21,6 +21,9 @@ properties: · 20 unmodified lines | ||
| 21 | 21 | reg: |
| 22 | 22 | maxItems: 1 |
| 23 | 23 | |
| 24 | + clocks: | |
| 25 | + maxItems: 1 | |
| 26 | + | |
| 24 | 27 | '#clock-cells': |
| 25 | 28 | const: 0 |
| 26 | 29 | |
| @@ -41,6 +44,8 @@ required: · 14 unmodified lines | ||
| 41 | 44 | - clocks |
| 42 | 45 | - '#clock-cells' |
| 43 | 46 | |
| 47 | +additionalProperties: false | |
| 48 | + | |
| 44 | 49 | examples: |
| 45 | 50 | # Display PIXEL Clock node: |
| 46 | 51 | - | |
| @@ -1,29 +0,0 @@ | ||
| 1 | −* Clock bindings for NXP i.MX8M Mini | |
| 2 | − | |
| 3 | −Required properties: | |
| 4 | −- compatible: Should be "fsl,imx8mm-ccm" | |
| 5 | −- reg: Address and length of the register set | |
| 6 | −- #clock-cells: Should be <1> | |
| 7 | −- clocks: list of clock specifiers, must contain an entry for each required | |
| 8 | − entry in clock-names | |
| 9 | −- clock-names: should include the following entries: | |
| 10 | − - "osc_32k" | |
| 11 | − - "osc_24m" | |
| 12 | − - "clk_ext1" | |
| 13 | − - "clk_ext2" | |
| 14 | − - "clk_ext3" | |
| 15 | − - "clk_ext4" | |
| 16 | − | |
| 17 | −clk: clock-controller@30380000 { | |
| 18 | − compatible = "fsl,imx8mm-ccm"; | |
| 19 | − reg = <0x0 0x30380000 0x0 0x10000>; | |
| 20 | − #clock-cells = <1>; | |
| 21 | − clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>, | |
| 22 | − <&clk_ext3>, <&clk_ext4>; | |
| 23 | − clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2", | |
| 24 | − "clk_ext3", "clk_ext4"; | |
| 25 | −}; | |
| 26 | − | |
| 27 | −The clock consumer should specify the desired clock by having the clock | |
| 28 | −ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mm-clock.h | |
| 29 | −for the full list of i.MX8M Mini clock IDs. | |
| @@ -0,0 +1,68 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/clock/imx8mm-clock.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: NXP i.MX8M Mini Clock Control Module Binding | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Anson Huang <Anson.Huang@nxp.com> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + NXP i.MX8M Mini clock control module is an integrated clock controller, which | |
| 14 | + generates and supplies to all modules. | |
| 15 | + | |
| 16 | +properties: | |
| 17 | + compatible: | |
| 18 | + const: fsl,imx8mm-ccm | |
| 19 | + | |
| 20 | + reg: | |
| 21 | + maxItems: 1 | |
| 22 | + | |
| 23 | + clocks: | |
| 24 | + items: | |
| 25 | + - description: 32k osc | |
| 26 | + - description: 24m osc | |
| 27 | + - description: ext1 clock input | |
| 28 | + - description: ext2 clock input | |
| 29 | + - description: ext3 clock input | |
| 30 | + - description: ext4 clock input | |
| 31 | + | |
| 32 | + clock-names: | |
| 33 | + items: | |
| 34 | + - const: osc_32k | |
| 35 | + - const: osc_24m | |
| 36 | + - const: clk_ext1 | |
| 37 | + - const: clk_ext2 | |
| 38 | + - const: clk_ext3 | |
| 39 | + - const: clk_ext4 | |
| 40 | + | |
| 41 | + '#clock-cells': | |
| 42 | + const: 1 | |
| 43 | + description: | |
| 44 | + The clock consumer should specify the desired clock by having the clock | |
| 45 | + ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mm-clock.h | |
| 46 | + for the full list of i.MX8M Mini clock IDs. | |
| 47 | + | |
| 48 | +required: | |
| 49 | + - compatible | |
| 50 | + - reg | |
| 51 | + - clocks | |
| 52 | + - clock-names | |
| 53 | + - '#clock-cells' | |
| 54 | + | |
| 55 | +examples: | |
| 56 | + # Clock Control Module node: | |
| 57 | + - | | |
| 58 | + clk: clock-controller@30380000 { | |
| 59 | + compatible = "fsl,imx8mm-ccm"; | |
| 60 | + reg = <0x30380000 0x10000>; | |
| 61 | + #clock-cells = <1>; | |
| 62 | + clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>, | |
| 63 | + <&clk_ext3>, <&clk_ext4>; | |
| 64 | + clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2", | |
| 65 | + "clk_ext3", "clk_ext4"; | |
| 66 | + }; | |
| 67 | + | |
| 68 | +... | |
| @@ -40,7 +40,7 @@ properties: · 39 unmodified lines | ||
| 40 | 40 | |
| 41 | 41 | '#clock-cells': |
| 42 | 42 | const: 1 |
| 43 | − description: | | |
| 43 | + description: | |
| 44 | 44 | The clock consumer should specify the desired clock by having the clock |
| 45 | 45 | ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mn-clock.h |
| 46 | 46 | for the full list of i.MX8M Nano clock IDs. |
| @@ -52,12 +52,14 @@ required: · 5 unmodified lines | ||
| 52 | 52 | - clock-names |
| 53 | 53 | - '#clock-cells' |
| 54 | 54 | |
| 55 | +additionalProperties: false | |
| 56 | + | |
| 55 | 57 | examples: |
| 56 | 58 | # Clock Control Module node: |
| 57 | 59 | - | |
| 58 | 60 | clk: clock-controller@30380000 { |
| 59 | 61 | compatible = "fsl,imx8mn-ccm"; |
| 60 | − reg = <0x0 0x30380000 0x0 0x10000>; | |
| 62 | + reg = <0x30380000 0x10000>; | |
| 61 | 63 | #clock-cells = <1>; |
| 62 | 64 | clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, |
| 63 | 65 | <&clk_ext2>, <&clk_ext3>, <&clk_ext4>; |
| @@ -65,48 +67,4 @@ examples: · 1 unmodified line | ||
| 65 | 67 | "clk_ext2", "clk_ext3", "clk_ext4"; |
| 66 | 68 | }; |
| 67 | 69 | |
| 68 | − # Required external clocks for Clock Control Module node: | |
| 69 | − - | | |
| 70 | − osc_32k: clock-osc-32k { | |
| 71 | − compatible = "fixed-clock"; | |
| 72 | − #clock-cells = <0>; | |
| 73 | − clock-frequency = <32768>; | |
| 74 | − clock-output-names = "osc_32k"; | |
| 75 | − }; | |
| 76 | − | |
| 77 | − osc_24m: clock-osc-24m { | |
| 78 | − compatible = "fixed-clock"; | |
| 79 | − #clock-cells = <0>; | |
| 80 | − clock-frequency = <24000000>; | |
| 81 | − clock-output-names = "osc_24m"; | |
| 82 | − }; | |
| 83 | − | |
| 84 | − clk_ext1: clock-ext1 { | |
| 85 | − compatible = "fixed-clock"; | |
| 86 | − #clock-cells = <0>; | |
| 87 | − clock-frequency = <133000000>; | |
| 88 | − clock-output-names = "clk_ext1"; | |
| 89 | − }; | |
| 90 | − | |
| 91 | − clk_ext2: clock-ext2 { | |
| 92 | − compatible = "fixed-clock"; | |
| 93 | − #clock-cells = <0>; | |
| 94 | − clock-frequency = <133000000>; | |
| 95 | − clock-output-names = "clk_ext2"; | |
| 96 | − }; | |
| 97 | − | |
| 98 | − clk_ext3: clock-ext3 { | |
| 99 | − compatible = "fixed-clock"; | |
| 100 | − #clock-cells = <0>; | |
| 101 | − clock-frequency = <133000000>; | |
| 102 | − clock-output-names = "clk_ext3"; | |
| 103 | − }; | |
| 104 | − | |
| 105 | − clk_ext4: clock-ext4 { | |
| 106 | − compatible = "fixed-clock"; | |
| 107 | − #clock-cells = <0>; | |
| 108 | − clock-frequency= <133000000>; | |
| 109 | − clock-output-names = "clk_ext4"; | |
| 110 | − }; | |
| 111 | − | |
| 112 | 70 | ... |
| @@ -52,6 +52,8 @@ required: · 51 unmodified lines | ||
| 52 | 52 | - clock-names |
| 53 | 53 | - '#clock-cells' |
| 54 | 54 | |
| 55 | +additionalProperties: false | |
| 56 | + | |
| 55 | 57 | examples: |
| 56 | 58 | # Clock Control Module node: |
| 57 | 59 | - | |
| @@ -1,20 +0,0 @@ | ||
| 1 | −* Clock bindings for NXP i.MX8M Quad | |
| 2 | − | |
| 3 | −Required properties: | |
| 4 | −- compatible: Should be "fsl,imx8mq-ccm" | |
| 5 | −- reg: Address and length of the register set | |
| 6 | −- #clock-cells: Should be <1> | |
| 7 | −- clocks: list of clock specifiers, must contain an entry for each required | |
| 8 | − entry in clock-names | |
| 9 | −- clock-names: should include the following entries: | |
| 10 | − - "ckil" | |
| 11 | − - "osc_25m" | |
| 12 | − - "osc_27m" | |
| 13 | − - "clk_ext1" | |
| 14 | − - "clk_ext2" | |
| 15 | − - "clk_ext3" | |
| 16 | − - "clk_ext4" | |
| 17 | − | |
| 18 | −The clock consumer should specify the desired clock by having the clock | |
| 19 | −ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mq-clock.h | |
| 20 | −for the full list of i.MX8M Quad clock IDs. | |
| @@ -0,0 +1,72 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/clock/imx8mq-clock.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: NXP i.MX8M Quad Clock Control Module Binding | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Anson Huang <Anson.Huang@nxp.com> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + NXP i.MX8M Quad clock control module is an integrated clock controller, which | |
| 14 | + generates and supplies to all modules. | |
| 15 | + | |
| 16 | +properties: | |
| 17 | + compatible: | |
| 18 | + const: fsl,imx8mq-ccm | |
| 19 | + | |
| 20 | + reg: | |
| 21 | + maxItems: 1 | |
| 22 | + | |
| 23 | + clocks: | |
| 24 | + items: | |
| 25 | + - description: 32k osc | |
| 26 | + - description: 25m osc | |
| 27 | + - description: 27m osc | |
| 28 | + - description: ext1 clock input | |
| 29 | + - description: ext2 clock input | |
| 30 | + - description: ext3 clock input | |
| 31 | + - description: ext4 clock input | |
| 32 | + | |
| 33 | + clock-names: | |
| 34 | + items: | |
| 35 | + - const: ckil | |
| 36 | + - const: osc_25m | |
| 37 | + - const: osc_27m | |
| 38 | + - const: clk_ext1 | |
| 39 | + - const: clk_ext2 | |
| 40 | + - const: clk_ext3 | |
| 41 | + - const: clk_ext4 | |
| 42 | + | |
| 43 | + '#clock-cells': | |
| 44 | + const: 1 | |
| 45 | + description: | |
| 46 | + The clock consumer should specify the desired clock by having the clock | |
| 47 | + ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mq-clock.h | |
| 48 | + for the full list of i.MX8M Quad clock IDs. | |
| 49 | + | |
| 50 | +required: | |
| 51 | + - compatible | |
| 52 | + - reg | |
| 53 | + - clocks | |
| 54 | + - clock-names | |
| 55 | + - '#clock-cells' | |
| 56 | + | |
| 57 | +examples: | |
| 58 | + # Clock Control Module node: | |
| 59 | + - | | |
| 60 | + clk: clock-controller@30380000 { | |
| 61 | + compatible = "fsl,imx8mq-ccm"; | |
| 62 | + reg = <0x30380000 0x10000>; | |
| 63 | + #clock-cells = <1>; | |
| 64 | + clocks = <&ckil>, <&osc_25m>, <&osc_27m>, | |
| 65 | + <&clk_ext1>, <&clk_ext2>, | |
| 66 | + <&clk_ext3>, <&clk_ext4>; | |
| 67 | + clock-names = "ckil", "osc_25m", "osc_27m", | |
| 68 | + "clk_ext1", "clk_ext2", | |
| 69 | + "clk_ext3", "clk_ext4"; | |
| 70 | + }; | |
| 71 | + | |
| 72 | +... | |
| @@ -0,0 +1,64 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/clock/marvell,mmp2-clock.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Marvell MMP2 and MMP3 Clock Controller | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Lubomir Rintel <lkundrak@v3.sk> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + The clock subsystem on MMP2 or MMP3 generates and supplies clock to various | |
| 14 | + controllers within the SoC. | |
| 15 | + | |
| 16 | + Each clock is assigned an identifier and client nodes use this identifier | |
| 17 | + to specify the clock which they consume. | |
| 18 | + | |
| 19 | + All these identifiers could be found in <dt-bindings/clock/marvell,mmp2.h>. | |
| 20 | + | |
| 21 | +properties: | |
| 22 | + compatible: | |
| 23 | + enum: | |
| 24 | + - marvell,mmp2-clock # controller compatible with MMP2 SoC | |
| 25 | + - marvell,mmp3-clock # controller compatible with MMP3 SoC | |
| 26 | + | |
| 27 | + reg: | |
| 28 | + items: | |
| 29 | + - description: MPMU register region | |
| 30 | + - description: APMU register region | |
| 31 | + - description: APBC register region | |
| 32 | + | |
| 33 | + reg-names: | |
| 34 | + items: | |
| 35 | + - const: mpmu | |
| 36 | + - const: apmu | |
| 37 | + - const: apbc | |
| 38 | + | |
| 39 | + '#clock-cells': | |
| 40 | + const: 1 | |
| 41 | + | |
| 42 | + '#reset-cells': | |
| 43 | + const: 1 | |
| 44 | + | |
| 45 | +required: | |
| 46 | + - compatible | |
| 47 | + - reg | |
| 48 | + - reg-names | |
| 49 | + - '#clock-cells' | |
| 50 | + - '#reset-cells' | |
| 51 | + | |
| 52 | +additionalProperties: false | |
| 53 | + | |
| 54 | +examples: | |
| 55 | + - | | |
| 56 | + clock-controller@d4050000 { | |
| 57 | + compatible = "marvell,mmp2-clock"; | |
| 58 | + reg = <0xd4050000 0x1000>, | |
| 59 | + <0xd4282800 0x400>, | |
| 60 | + <0xd4015000 0x1000>; | |
| 61 | + reg-names = "mpmu", "apmu", "apbc"; | |
| 62 | + #clock-cells = <1>; | |
| 63 | + #reset-cells = <1>; | |
| 64 | + }; | |
| @@ -1,21 +0,0 @@ | ||
| 1 | −* Marvell MMP2 Clock Controller | |
| 2 | − | |
| 3 | −The MMP2 clock subsystem generates and supplies clock to various | |
| 4 | −controllers within the MMP2 SoC. | |
| 5 | − | |
| 6 | −Required Properties: | |
| 7 | − | |
| 8 | −- compatible: should be one of the following. | |
| 9 | − - "marvell,mmp2-clock" - controller compatible with MMP2 SoC. | |
| 10 | − | |
| 11 | −- reg: physical base address of the clock subsystem and length of memory mapped | |
| 12 | − region. There are 3 places in SOC has clock control logic: | |
| 13 | − "mpmu", "apmu", "apbc". So three reg spaces need to be defined. | |
| 14 | − | |
| 15 | −- #clock-cells: should be 1. | |
| 16 | −- #reset-cells: should be 1. | |
| 17 | − | |
| 18 | −Each clock is assigned an identifier and client nodes use this identifier | |
| 19 | −to specify the clock which they consume. | |
| 20 | − | |
| 21 | −All these identifiers could be found in <dt-bindings/clock/marvell,mmp2.h>. | |
| @@ -35,6 +35,8 @@ required: · 34 unmodified lines | ||
| 35 | 35 | - clocks |
| 36 | 36 | - '#clock-cells' |
| 37 | 37 | |
| 38 | +additionalProperties: false | |
| 39 | + | |
| 38 | 40 | examples: |
| 39 | 41 | # Clock controller node: |
| 40 | 42 | - | |
| @@ -68,6 +68,8 @@ required: · 67 unmodified lines | ||
| 68 | 68 | - nvmem-cell-names |
| 69 | 69 | - '#thermal-sensor-cells' |
| 70 | 70 | |
| 71 | +additionalProperties: false | |
| 72 | + | |
| 71 | 73 | examples: |
| 72 | 74 | - | |
| 73 | 75 | clock-controller@900000 { |
| @@ -40,6 +40,8 @@ required: · 39 unmodified lines | ||
| 40 | 40 | - '#clock-cells' |
| 41 | 41 | - '#reset-cells' |
| 42 | 42 | |
| 43 | +additionalProperties: false | |
| 44 | + | |
| 43 | 45 | examples: |
| 44 | 46 | - | |
| 45 | 47 | clock-controller@1800000 { |
| @@ -56,6 +56,8 @@ required: · 55 unmodified lines | ||
| 56 | 56 | - '#reset-cells' |
| 57 | 57 | - '#power-domain-cells' |
| 58 | 58 | |
| 59 | +additionalProperties: false | |
| 60 | + | |
| 59 | 61 | examples: |
| 60 | 62 | - | |
| 61 | 63 | clock-controller@300000 { |
| @@ -66,6 +66,8 @@ required: · 65 unmodified lines | ||
| 66 | 66 | - '#reset-cells' |
| 67 | 67 | - '#power-domain-cells' |
| 68 | 68 | |
| 69 | +additionalProperties: false | |
| 70 | + | |
| 69 | 71 | examples: |
| 70 | 72 | - | |
| 71 | 73 | #include <dt-bindings/clock/qcom,rpmcc.h> |
| @@ -40,6 +40,8 @@ required: · 39 unmodified lines | ||
| 40 | 40 | - '#clock-cells' |
| 41 | 41 | - '#reset-cells' |
| 42 | 42 | |
| 43 | +additionalProperties: false | |
| 44 | + | |
| 43 | 45 | examples: |
| 44 | 46 | - | |
| 45 | 47 | clock-controller@1800000 { |
| @@ -58,6 +58,8 @@ required: · 57 unmodified lines | ||
| 58 | 58 | - '#reset-cells' |
| 59 | 59 | - '#power-domain-cells' |
| 60 | 60 | |
| 61 | +additionalProperties: false | |
| 62 | + | |
| 61 | 63 | examples: |
| 62 | 64 | - | |
| 63 | 65 | #include <dt-bindings/clock/qcom,rpmh.h> |
| @@ -56,6 +56,8 @@ required: · 55 unmodified lines | ||
| 56 | 56 | - '#reset-cells' |
| 57 | 57 | - '#power-domain-cells' |
| 58 | 58 | |
| 59 | +additionalProperties: false | |
| 60 | + | |
| 59 | 61 | examples: |
| 60 | 62 | - | |
| 61 | 63 | #include <dt-bindings/clock/qcom,rpmh.h> |
| @@ -0,0 +1,72 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/clock/qcom,gcc-sm8250.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Qualcomm Global Clock & Reset Controller Binding for SM8250 | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Stephen Boyd <sboyd@kernel.org> | |
| 11 | + - Taniya Das <tdas@codeaurora.org> | |
| 12 | + | |
| 13 | +description: | | |
| 14 | + Qualcomm global clock control module which supports the clocks, resets and | |
| 15 | + power domains on SM8250. | |
| 16 | + | |
| 17 | + See also: | |
| 18 | + - dt-bindings/clock/qcom,gcc-sm8250.h | |
| 19 | + | |
| 20 | +properties: | |
| 21 | + compatible: | |
| 22 | + const: qcom,gcc-sm8250 | |
| 23 | + | |
| 24 | + clocks: | |
| 25 | + items: | |
| 26 | + - description: Board XO source | |
| 27 | + - description: Sleep clock source | |
| 28 | + | |
| 29 | + clock-names: | |
| 30 | + items: | |
| 31 | + - const: bi_tcxo | |
| 32 | + - const: sleep_clk | |
| 33 | + | |
| 34 | + '#clock-cells': | |
| 35 | + const: 1 | |
| 36 | + | |
| 37 | + '#reset-cells': | |
| 38 | + const: 1 | |
| 39 | + | |
| 40 | + '#power-domain-cells': | |
| 41 | + const: 1 | |
| 42 | + | |
| 43 | + reg: | |
| 44 | + maxItems: 1 | |
| 45 | + | |
| 46 | + protected-clocks: | |
| 47 | + description: | |
| 48 | + Protected clock specifier list as per common clock binding. | |
| 49 | + | |
| 50 | +required: | |
| 51 | + - compatible | |
| 52 | + - clocks | |
| 53 | + - clock-names | |
| 54 | + - reg | |
| 55 | + - '#clock-cells' | |
| 56 | + - '#reset-cells' | |
| 57 | + - '#power-domain-cells' | |
| 58 | + | |
| 59 | +examples: | |
| 60 | + - | | |
| 61 | + #include <dt-bindings/clock/qcom,rpmh.h> | |
| 62 | + clock-controller@100000 { | |
| 63 | + compatible = "qcom,gcc-sm8250"; | |
| 64 | + reg = <0 0x00100000 0 0x1f0000>; | |
| 65 | + clocks = <&rpmhcc RPMH_CXO_CLK>, | |
| 66 | + <&sleep_clk>; | |
| 67 | + clock-names = "bi_tcxo", "sleep_clk"; | |
| 68 | + #clock-cells = <1>; | |
| 69 | + #reset-cells = <1>; | |
| 70 | + #power-domain-cells = <1>; | |
| 71 | + }; | |
| 72 | +... | |
| @@ -74,6 +74,8 @@ required: · 73 unmodified lines | ||
| 74 | 74 | - '#reset-cells' |
| 75 | 75 | - '#power-domain-cells' |
| 76 | 76 | |
| 77 | +additionalProperties: false | |
| 78 | + | |
| 77 | 79 | examples: |
| 78 | 80 | # Example for GCC for MSM8960: |
| 79 | 81 | - | |
| @@ -74,6 +74,8 @@ required: · 73 unmodified lines | ||
| 74 | 74 | - '#reset-cells' |
| 75 | 75 | - '#power-domain-cells' |
| 76 | 76 | |
| 77 | +additionalProperties: false | |
| 78 | + | |
| 77 | 79 | if: |
| 78 | 80 | properties: |
| 79 | 81 | compatible: |
| @@ -50,6 +50,8 @@ required: · 49 unmodified lines | ||
| 50 | 50 | - '#reset-cells' |
| 51 | 51 | - '#power-domain-cells' |
| 52 | 52 | |
| 53 | +additionalProperties: false | |
| 54 | + | |
| 53 | 55 | examples: |
| 54 | 56 | - | |
| 55 | 57 | #include <dt-bindings/clock/qcom,gcc-msm8998.h> |
| @@ -14,7 +14,9 @@ Required properties : · 13 unmodified lines | ||
| 14 | 14 | "qcom,rpmcc-apq8060", "qcom,rpmcc" |
| 15 | 15 | "qcom,rpmcc-msm8916", "qcom,rpmcc" |
| 16 | 16 | "qcom,rpmcc-msm8974", "qcom,rpmcc" |
| 17 | + "qcom,rpmcc-msm8976", "qcom,rpmcc" | |
| 17 | 18 | "qcom,rpmcc-apq8064", "qcom,rpmcc" |
| 19 | + "qcom,rpmcc-ipq806x", "qcom,rpmcc" | |
| 18 | 20 | "qcom,rpmcc-msm8996", "qcom,rpmcc" |
| 19 | 21 | "qcom,rpmcc-msm8998", "qcom,rpmcc" |
| 20 | 22 | "qcom,rpmcc-qcs404", "qcom,rpmcc" |
| @@ -20,6 +20,7 @@ properties: · 19 unmodified lines | ||
| 20 | 20 | - qcom,sc7180-rpmh-clk |
| 21 | 21 | - qcom,sdm845-rpmh-clk |
| 22 | 22 | - qcom,sm8150-rpmh-clk |
| 23 | + - qcom,sm8250-rpmh-clk | |
| 23 | 24 | |
| 24 | 25 | clocks: |
| 25 | 26 | maxItems: 1 |
| @@ -35,6 +36,8 @@ required: · 9 unmodified lines | ||
| 35 | 36 | - compatible |
| 36 | 37 | - '#clock-cells' |
| 37 | 38 | |
| 39 | +additionalProperties: false | |
| 40 | + | |
| 38 | 41 | examples: |
| 39 | 42 | # Example for GCC for SDM845: The below node should be defined inside |
| 40 | 43 | # &apps_rsc node. |
| @@ -58,6 +58,8 @@ required: · 57 unmodified lines | ||
| 58 | 58 | - '#reset-cells' |
| 59 | 59 | - '#power-domain-cells' |
| 60 | 60 | |
| 61 | +additionalProperties: false | |
| 62 | + | |
| 61 | 63 | examples: |
| 62 | 64 | - | |
| 63 | 65 | #include <dt-bindings/clock/qcom,gcc-sc7180.h> |
| @@ -52,6 +52,8 @@ required: · 51 unmodified lines | ||
| 52 | 52 | - '#reset-cells' |
| 53 | 53 | - '#power-domain-cells' |
| 54 | 54 | |
| 55 | +additionalProperties: false | |
| 56 | + | |
| 55 | 57 | examples: |
| 56 | 58 | - | |
| 57 | 59 | #include <dt-bindings/clock/qcom,gcc-sc7180.h> |
| @@ -0,0 +1,62 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/clock/qcom,sc7180-mss.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Qualcomm Modem Clock Controller Binding for SC7180 | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Taniya Das <tdas@codeaurora.org> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + Qualcomm modem clock control module which supports the clocks on SC7180. | |
| 14 | + | |
| 15 | + See also: | |
| 16 | + - dt-bindings/clock/qcom,mss-sc7180.h | |
| 17 | + | |
| 18 | +properties: | |
| 19 | + compatible: | |
| 20 | + const: qcom,sc7180-mss | |
| 21 | + | |
| 22 | + clocks: | |
| 23 | + items: | |
| 24 | + - description: gcc_mss_mfab_axi clock from GCC | |
| 25 | + - description: gcc_mss_nav_axi clock from GCC | |
| 26 | + - description: gcc_mss_cfg_ahb clock from GCC | |
| 27 | + | |
| 28 | + clock-names: | |
| 29 | + items: | |
| 30 | + - const: gcc_mss_mfab_axis | |
| 31 | + - const: gcc_mss_nav_axi | |
| 32 | + - const: cfg_ahb | |
| 33 | + | |
| 34 | + '#clock-cells': | |
| 35 | + const: 1 | |
| 36 | + | |
| 37 | + reg: | |
| 38 | + maxItems: 1 | |
| 39 | + | |
| 40 | +required: | |
| 41 | + - compatible | |
| 42 | + - reg | |
| 43 | + - clocks | |
| 44 | + - '#clock-cells' | |
| 45 | + | |
| 46 | +additionalProperties: false | |
| 47 | + | |
| 48 | +examples: | |
| 49 | + - | | |
| 50 | + #include <dt-bindings/clock/qcom,gcc-sc7180.h> | |
| 51 | + clock-controller@41a8000 { | |
| 52 | + compatible = "qcom,sc7180-mss"; | |
| 53 | + reg = <0 0x041a8000 0 0x8000>; | |
| 54 | + clocks = <&gcc GCC_MSS_MFAB_AXIS_CLK>, | |
| 55 | + <&gcc GCC_MSS_NAV_AXI_CLK>, | |
| 56 | + <&gcc GCC_MSS_CFG_AHB_CLK>; | |
| 57 | + clock-names = "gcc_mss_mfab_axis", | |
| 58 | + "gcc_mss_nav_axi", | |
| 59 | + "cfg_ahb"; | |
| 60 | + #clock-cells = <1>; | |
| 61 | + }; | |
| 62 | +... | |
| @@ -48,6 +48,8 @@ required: · 47 unmodified lines | ||
| 48 | 48 | - '#reset-cells' |
| 49 | 49 | - '#power-domain-cells' |
| 50 | 50 | |
| 51 | +additionalProperties: false | |
| 52 | + | |
| 51 | 53 | examples: |
| 52 | 54 | - | |
| 53 | 55 | #include <dt-bindings/clock/qcom,rpmh.h> |
| @@ -67,6 +67,8 @@ required: · 66 unmodified lines | ||
| 67 | 67 | - '#reset-cells' |
| 68 | 68 | - '#power-domain-cells' |
| 69 | 69 | |
| 70 | +additionalProperties: false | |
| 71 | + | |
| 70 | 72 | examples: |
| 71 | 73 | - | |
| 72 | 74 | #include <dt-bindings/clock/qcom,gcc-sdm845.h> |
| @@ -52,6 +52,8 @@ required: · 51 unmodified lines | ||
| 52 | 52 | - '#reset-cells' |
| 53 | 53 | - '#power-domain-cells' |
| 54 | 54 | |
| 55 | +additionalProperties: false | |
| 56 | + | |
| 55 | 57 | examples: |
| 56 | 58 | - | |
| 57 | 59 | #include <dt-bindings/clock/qcom,gcc-sdm845.h> |
| @@ -48,6 +48,8 @@ required: · 47 unmodified lines | ||
| 48 | 48 | - '#reset-cells' |
| 49 | 49 | - '#power-domain-cells' |
| 50 | 50 | |
| 51 | +additionalProperties: false | |
| 52 | + | |
| 51 | 53 | examples: |
| 52 | 54 | - | |
| 53 | 55 | #include <dt-bindings/clock/qcom,rpmh.h> |
| @@ -1,100 +0,0 @@ | ||
| 1 | −* Renesas Clock Pulse Generator / Module Standby and Software Reset | |
| 2 | − | |
| 3 | −On Renesas ARM SoCs (SH/R-Mobile, R-Car, RZ), the CPG (Clock Pulse Generator) | |
| 4 | −and MSSR (Module Standby and Software Reset) blocks are intimately connected, | |
| 5 | −and share the same register block. | |
| 6 | − | |
| 7 | −They provide the following functionalities: | |
| 8 | − - The CPG block generates various core clocks, | |
| 9 | − - The MSSR block provides two functions: | |
| 10 | − 1. Module Standby, providing a Clock Domain to control the clock supply | |
| 11 | − to individual SoC devices, | |
| 12 | − 2. Reset Control, to perform a software reset of individual SoC devices. | |
| 13 | − | |
| 14 | −Required Properties: | |
| 15 | − - compatible: Must be one of: | |
| 16 | − - "renesas,r7s9210-cpg-mssr" for the r7s9210 SoC (RZ/A2) | |
| 17 | − - "renesas,r8a7743-cpg-mssr" for the r8a7743 SoC (RZ/G1M) | |
| 18 | − - "renesas,r8a7744-cpg-mssr" for the r8a7744 SoC (RZ/G1N) | |
| 19 | − - "renesas,r8a7745-cpg-mssr" for the r8a7745 SoC (RZ/G1E) | |
| 20 | − - "renesas,r8a77470-cpg-mssr" for the r8a77470 SoC (RZ/G1C) | |
| 21 | − - "renesas,r8a774a1-cpg-mssr" for the r8a774a1 SoC (RZ/G2M) | |
| 22 | − - "renesas,r8a774b1-cpg-mssr" for the r8a774b1 SoC (RZ/G2N) | |
| 23 | − - "renesas,r8a774c0-cpg-mssr" for the r8a774c0 SoC (RZ/G2E) | |
| 24 | − - "renesas,r8a7790-cpg-mssr" for the r8a7790 SoC (R-Car H2) | |
| 25 | − - "renesas,r8a7791-cpg-mssr" for the r8a7791 SoC (R-Car M2-W) | |
| 26 | − - "renesas,r8a7792-cpg-mssr" for the r8a7792 SoC (R-Car V2H) | |
| 27 | − - "renesas,r8a7793-cpg-mssr" for the r8a7793 SoC (R-Car M2-N) | |
| 28 | − - "renesas,r8a7794-cpg-mssr" for the r8a7794 SoC (R-Car E2) | |
| 29 | − - "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC (R-Car H3) | |
| 30 | − - "renesas,r8a7796-cpg-mssr" for the r8a77960 SoC (R-Car M3-W) | |
| 31 | − - "renesas,r8a77961-cpg-mssr" for the r8a77961 SoC (R-Car M3-W+) | |
| 32 | − - "renesas,r8a77965-cpg-mssr" for the r8a77965 SoC (R-Car M3-N) | |
| 33 | − - "renesas,r8a77970-cpg-mssr" for the r8a77970 SoC (R-Car V3M) | |
| 34 | − - "renesas,r8a77980-cpg-mssr" for the r8a77980 SoC (R-Car V3H) | |
| 35 | − - "renesas,r8a77990-cpg-mssr" for the r8a77990 SoC (R-Car E3) | |
| 36 | − - "renesas,r8a77995-cpg-mssr" for the r8a77995 SoC (R-Car D3) | |
| 37 | − | |
| 38 | − - reg: Base address and length of the memory resource used by the CPG/MSSR | |
| 39 | − block | |
| 40 | − | |
| 41 | − - clocks: References to external parent clocks, one entry for each entry in | |
| 42 | − clock-names | |
| 43 | − - clock-names: List of external parent clock names. Valid names are: | |
| 44 | − - "extal" (r7s9210, r8a7743, r8a7744, r8a7745, r8a77470, r8a774a1, | |
| 45 | − r8a774b1, r8a774c0, r8a7790, r8a7791, r8a7792, r8a7793, | |
| 46 | − r8a7794, r8a7795, r8a77960, r8a77961, r8a77965, r8a77970, | |
| 47 | − r8a77980, r8a77990, r8a77995) | |
| 48 | − - "extalr" (r8a774a1, r8a774b1, r8a7795, r8a77960, r8a77961, r8a77965, | |
| 49 | − r8a77970, r8a77980) | |
| 50 | − - "usb_extal" (r8a7743, r8a7744, r8a7745, r8a77470, r8a7790, r8a7791, | |
| 51 | − r8a7793, r8a7794) | |
| 52 | − | |
| 53 | − - #clock-cells: Must be 2 | |
| 54 | − - For CPG core clocks, the two clock specifier cells must be "CPG_CORE" | |
| 55 | − and a core clock reference, as defined in | |
| 56 | − <dt-bindings/clock/*-cpg-mssr.h>. | |
| 57 | − - For module clocks, the two clock specifier cells must be "CPG_MOD" and | |
| 58 | − a module number, as defined in the datasheet. | |
| 59 | − | |
| 60 | − - #power-domain-cells: Must be 0 | |
| 61 | − - SoC devices that are part of the CPG/MSSR Clock Domain and can be | |
| 62 | − power-managed through Module Standby should refer to the CPG device | |
| 63 | − node in their "power-domains" property, as documented by the generic PM | |
| 64 | − Domain bindings in | |
| 65 | − Documentation/devicetree/bindings/power/power-domain.yaml. | |
| 66 | − | |
| 67 | − - #reset-cells: Must be 1 | |
| 68 | − - The single reset specifier cell must be the module number, as defined | |
| 69 | − in the datasheet. | |
| 70 | − | |
| 71 | − | |
| 72 | −Examples | |
| 73 | −-------- | |
| 74 | − | |
| 75 | − - CPG device node: | |
| 76 | − | |
| 77 | − cpg: clock-controller@e6150000 { | |
| 78 | − compatible = "renesas,r8a7795-cpg-mssr"; | |
| 79 | − reg = <0 0xe6150000 0 0x1000>; | |
| 80 | − clocks = <&extal_clk>, <&extalr_clk>; | |
| 81 | − clock-names = "extal", "extalr"; | |
| 82 | − #clock-cells = <2>; | |
| 83 | − #power-domain-cells = <0>; | |
| 84 | − #reset-cells = <1>; | |
| 85 | − }; | |
| 86 | − | |
| 87 | − | |
| 88 | − - CPG/MSSR Clock Domain member device node: | |
| 89 | − | |
| 90 | − scif2: serial@e6e88000 { | |
| 91 | − compatible = "renesas,scif-r8a7795", "renesas,scif"; | |
| 92 | − reg = <0 0xe6e88000 0 64>; | |
| 93 | − interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>; | |
| 94 | − clocks = <&cpg CPG_MOD 310>; | |
| 95 | − clock-names = "fck"; | |
| 96 | − dmas = <&dmac1 0x13>, <&dmac1 0x12>; | |
| 97 | − dma-names = "tx", "rx"; | |
| 98 | − power-domains = <&cpg>; | |
| 99 | − resets = <&cpg 310>; | |
| 100 | − }; | |
| @@ -0,0 +1,119 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: "http://devicetree.org/schemas/clock/renesas,cpg-mssr.yaml#" | |
| 5 | +$schema: "http://devicetree.org/meta-schemas/core.yaml#" | |
| 6 | + | |
| 7 | +title: Renesas Clock Pulse Generator / Module Standby and Software Reset | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Geert Uytterhoeven <geert+renesas@glider.be> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + On Renesas ARM SoCs (SH/R-Mobile, R-Car, RZ), the CPG (Clock Pulse Generator) | |
| 14 | + and MSSR (Module Standby and Software Reset) blocks are intimately connected, | |
| 15 | + and share the same register block. | |
| 16 | + | |
| 17 | + They provide the following functionalities: | |
| 18 | + - The CPG block generates various core clocks, | |
| 19 | + - The MSSR block provides two functions: | |
| 20 | + 1. Module Standby, providing a Clock Domain to control the clock supply | |
| 21 | + to individual SoC devices, | |
| 22 | + 2. Reset Control, to perform a software reset of individual SoC devices. | |
| 23 | + | |
| 24 | +properties: | |
| 25 | + compatible: | |
| 26 | + enum: | |
| 27 | + - renesas,r7s9210-cpg-mssr # RZ/A2 | |
| 28 | + - renesas,r8a7743-cpg-mssr # RZ/G1M | |
| 29 | + - renesas,r8a7744-cpg-mssr # RZ/G1N | |
| 30 | + - renesas,r8a7745-cpg-mssr # RZ/G1E | |
| 31 | + - renesas,r8a77470-cpg-mssr # RZ/G1C | |
| 32 | + - renesas,r8a774a1-cpg-mssr # RZ/G2M | |
| 33 | + - renesas,r8a774b1-cpg-mssr # RZ/G2N | |
| 34 | + - renesas,r8a774c0-cpg-mssr # RZ/G2E | |
| 35 | + - renesas,r8a7790-cpg-mssr # R-Car H2 | |
| 36 | + - renesas,r8a7791-cpg-mssr # R-Car M2-W | |
| 37 | + - renesas,r8a7792-cpg-mssr # R-Car V2H | |
| 38 | + - renesas,r8a7793-cpg-mssr # R-Car M2-N | |
| 39 | + - renesas,r8a7794-cpg-mssr # R-Car E2 | |
| 40 | + - renesas,r8a7795-cpg-mssr # R-Car H3 | |
| 41 | + - renesas,r8a7796-cpg-mssr # R-Car M3-W | |
| 42 | + - renesas,r8a77961-cpg-mssr # R-Car M3-W+ | |
| 43 | + - renesas,r8a77965-cpg-mssr # R-Car M3-N | |
| 44 | + - renesas,r8a77970-cpg-mssr # R-Car V3M | |
| 45 | + - renesas,r8a77980-cpg-mssr # R-Car V3H | |
| 46 | + - renesas,r8a77990-cpg-mssr # R-Car E3 | |
| 47 | + - renesas,r8a77995-cpg-mssr # R-Car D3 | |
| 48 | + | |
| 49 | + reg: | |
| 50 | + maxItems: 1 | |
| 51 | + | |
| 52 | + clocks: | |
| 53 | + minItems: 1 | |
| 54 | + maxItems: 2 | |
| 55 | + | |
| 56 | + clock-names: | |
| 57 | + minItems: 1 | |
| 58 | + maxItems: 2 | |
| 59 | + items: | |
| 60 | + enum: | |
| 61 | + - extal # All | |
| 62 | + - extalr # Most R-Car Gen3 and RZ/G2 | |
| 63 | + - usb_extal # Most R-Car Gen2 and RZ/G1 | |
| 64 | + | |
| 65 | + '#clock-cells': | |
| 66 | + description: | | |
| 67 | + - For CPG core clocks, the two clock specifier cells must be "CPG_CORE" | |
| 68 | + and a core clock reference, as defined in | |
| 69 | + <dt-bindings/clock/*-cpg-mssr.h> | |
| 70 | + - For module clocks, the two clock specifier cells must be "CPG_MOD" and | |
| 71 | + a module number, as defined in the datasheet. | |
| 72 | + const: 2 | |
| 73 | + | |
| 74 | + '#power-domain-cells': | |
| 75 | + description: | |
| 76 | + SoC devices that are part of the CPG/MSSR Clock Domain and can be | |
| 77 | + power-managed through Module Standby should refer to the CPG device node | |
| 78 | + in their "power-domains" property, as documented by the generic PM Domain | |
| 79 | + bindings in Documentation/devicetree/bindings/power/power-domain.yaml. | |
| 80 | + const: 0 | |
| 81 | + | |
| 82 | + '#reset-cells': | |
| 83 | + description: | |
| 84 | + The single reset specifier cell must be the module number, as defined in | |
| 85 | + the datasheet. | |
| 86 | + const: 1 | |
| 87 | + | |
| 88 | +if: | |
| 89 | + not: | |
| 90 | + properties: | |
| 91 | + compatible: | |
| 92 | + items: | |
| 93 | + enum: | |
| 94 | + - renesas,r7s9210-cpg-mssr | |
| 95 | +then: | |
| 96 | + required: | |
| 97 | + - '#reset-cells' | |
| 98 | + | |
| 99 | +required: | |
| 100 | + - compatible | |
| 101 | + - reg | |
| 102 | + - clocks | |
| 103 | + - clock-names | |
| 104 | + - '#clock-cells' | |
| 105 | + - '#power-domain-cells' | |
| 106 | + | |
| 107 | +additionalProperties: false | |
| 108 | + | |
| 109 | +examples: | |
| 110 | + - | | |
| 111 | + cpg: clock-controller@e6150000 { | |
| 112 | + compatible = "renesas,r8a7795-cpg-mssr"; | |
| 113 | + reg = <0xe6150000 0x1000>; | |
| 114 | + clocks = <&extal_clk>, <&extalr_clk>; | |
| 115 | + clock-names = "extal", "extalr"; | |
| 116 | + #clock-cells = <2>; | |
| 117 | + #power-domain-cells = <0>; | |
| 118 | + #reset-cells = <1>; | |
| 119 | + }; | |
| @@ -38,10 +38,17 @@ Required properties: · 37 unmodified lines | ||
| 38 | 38 | - reg: offset and length of the USB 2.0 clock selector register block. |
| 39 | 39 | - clocks: A list of phandles and specifier pairs. |
| 40 | 40 | - clock-names: Name of the clocks. |
| 41 | − - The functional clock must be "ehci_ohci" | |
| 41 | + - The functional clock of USB 2.0 host side must be "ehci_ohci" | |
| 42 | + - The functional clock of HS-USB side must be "hs-usb-if" | |
| 42 | 43 | - The USB_EXTAL clock pin must be "usb_extal" |
| 43 | 44 | - The USB_XTAL clock pin must be "usb_xtal" |
| 44 | 45 | - #clock-cells: Must be 0 |
| 46 | +- power-domains: A phandle and symbolic PM domain specifier. | |
| 47 | + See power/renesas,rcar-sysc.yaml. | |
| 48 | +- resets: A list of phandles and specifier pairs. | |
| 49 | +- reset-names: Name of the resets. | |
| 50 | + - The reset of USB 2.0 host side must be "ehci_ohci" | |
| 51 | + - The reset of HS-USB side must be "hs-usb-if" | |
| 45 | 52 | |
| 46 | 53 | Example (R-Car H3): |
| 47 | 54 | |
| @@ -49,7 +56,11 @@ Example (R-Car H3): · 1 unmodified line | ||
| 49 | 56 | compatible = "renesas,r8a7795-rcar-usb2-clock-sel", |
| 50 | 57 | "renesas,rcar-gen3-usb2-clock-sel"; |
| 51 | 58 | reg = <0 0xe6590630 0 0x02>; |
| 52 | − clocks = <&cpg CPG_MOD 703>, <&usb_extal>, <&usb_xtal>; | |
| 53 | − clock-names = "ehci_ohci", "usb_extal", "usb_xtal"; | |
| 59 | + clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, | |
| 60 | + <&usb_extal>, <&usb_xtal>; | |
| 61 | + clock-names = "ehci_ohci", "hs-usb-if", "usb_extal", "usb_xtal"; | |
| 54 | 62 | #clock-cells = <0>; |
| 63 | + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; | |
| 64 | + resets = <&cpg 703>, <&cpg 704>; | |
| 65 | + reset-names = "ehci_ohci", "hs-usb-if"; | |
| 55 | 66 | }; |
| @@ -0,0 +1,94 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/clock/socionext,uniphier-clock.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: UniPhier clock controller | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Masahiro Yamada <yamada.masahiro@socionext.com> | |
| 11 | + | |
| 12 | +properties: | |
| 13 | + compatible: | |
| 14 | + oneOf: | |
| 15 | + - description: System clock | |
| 16 | + enum: | |
| 17 | + - socionext,uniphier-ld4-clock | |
| 18 | + - socionext,uniphier-pro4-clock | |
| 19 | + - socionext,uniphier-sld8-clock | |
| 20 | + - socionext,uniphier-pro5-clock | |
| 21 | + - socionext,uniphier-pxs2-clock | |
| 22 | + - socionext,uniphier-ld6b-clock | |
| 23 | + - socionext,uniphier-ld11-clock | |
| 24 | + - socionext,uniphier-ld20-clock | |
| 25 | + - socionext,uniphier-pxs3-clock | |
| 26 | + - description: Media I/O (MIO) clock, SD clock | |
| 27 | + enum: | |
| 28 | + - socionext,uniphier-ld4-mio-clock | |
| 29 | + - socionext,uniphier-pro4-mio-clock | |
| 30 | + - socionext,uniphier-sld8-mio-clock | |
| 31 | + - socionext,uniphier-pro5-sd-clock | |
| 32 | + - socionext,uniphier-pxs2-sd-clock | |
| 33 | + - socionext,uniphier-ld11-mio-clock | |
| 34 | + - socionext,uniphier-ld20-sd-clock | |
| 35 | + - socionext,uniphier-pxs3-sd-clock | |
| 36 | + - description: Peripheral clock | |
| 37 | + enum: | |
| 38 | + - socionext,uniphier-ld4-peri-clock | |
| 39 | + - socionext,uniphier-pro4-peri-clock | |
| 40 | + - socionext,uniphier-sld8-peri-clock | |
| 41 | + - socionext,uniphier-pro5-peri-clock | |
| 42 | + - socionext,uniphier-pxs2-peri-clock | |
| 43 | + - socionext,uniphier-ld11-peri-clock | |
| 44 | + - socionext,uniphier-ld20-peri-clock | |
| 45 | + - socionext,uniphier-pxs3-peri-clock | |
| 46 | + | |
| 47 | + "#clock-cells": | |
| 48 | + const: 1 | |
| 49 | + | |
| 50 | +additionalProperties: false | |
| 51 | + | |
| 52 | +required: | |
| 53 | + - compatible | |
| 54 | + - "#clock-cells" | |
| 55 | + | |
| 56 | +examples: | |
| 57 | + - | | |
| 58 | + sysctrl@61840000 { | |
| 59 | + compatible = "socionext,uniphier-sysctrl", "simple-mfd", "syscon"; | |
| 60 | + reg = <0x61840000 0x4000>; | |
| 61 | + | |
| 62 | + clock { | |
| 63 | + compatible = "socionext,uniphier-ld11-clock"; | |
| 64 | + #clock-cells = <1>; | |
| 65 | + }; | |
| 66 | + | |
| 67 | + // other nodes ... | |
| 68 | + }; | |
| 69 | + | |
| 70 | + - | | |
| 71 | + mioctrl@59810000 { | |
| 72 | + compatible = "socionext,uniphier-mioctrl", "simple-mfd", "syscon"; | |
| 73 | + reg = <0x59810000 0x800>; | |
| 74 | + | |
| 75 | + clock { | |
| 76 | + compatible = "socionext,uniphier-ld11-mio-clock"; | |
| 77 | + #clock-cells = <1>; | |
| 78 | + }; | |
| 79 | + | |
| 80 | + // other nodes ... | |
| 81 | + }; | |
| 82 | + | |
| 83 | + - | | |
| 84 | + perictrl@59820000 { | |
| 85 | + compatible = "socionext,uniphier-perictrl", "simple-mfd", "syscon"; | |
| 86 | + reg = <0x59820000 0x200>; | |
| 87 | + | |
| 88 | + clock { | |
| 89 | + compatible = "socionext,uniphier-ld11-peri-clock"; | |
| 90 | + #clock-cells = <1>; | |
| 91 | + }; | |
| 92 | + | |
| 93 | + // other nodes ... | |
| 94 | + }; | |
| @@ -1,4 +1,4 @@ | ||
| 1 | −Spreadtrum Clock Binding | |
| 1 | +Spreadtrum SC9860 Clock Binding | |
| 2 | 2 | ------------------------ |
| 3 | 3 | |
| 4 | 4 | Required properties: |
| @@ -0,0 +1,105 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +# Copyright 2019 Unisoc Inc. | |
| 3 | +%YAML 1.2 | |
| 4 | +--- | |
| 5 | +$id: "http://devicetree.org/schemas/clock/sprd,sc9863a-clk.yaml#" | |
| 6 | +$schema: "http://devicetree.org/meta-schemas/core.yaml#" | |
| 7 | + | |
| 8 | +title: SC9863A Clock Control Unit Device Tree Bindings | |
| 9 | + | |
| 10 | +maintainers: | |
| 11 | + - Orson Zhai <orsonzhai@gmail.com> | |
| 12 | + - Baolin Wang <baolin.wang7@gmail.com> | |
| 13 | + - Chunyan Zhang <zhang.lyra@gmail.com> | |
| 14 | + | |
| 15 | +properties: | |
| 16 | + "#clock-cells": | |
| 17 | + const: 1 | |
| 18 | + | |
| 19 | + compatible : | |
| 20 | + enum: | |
| 21 | + - sprd,sc9863a-ap-clk | |
| 22 | + - sprd,sc9863a-aon-clk | |
| 23 | + - sprd,sc9863a-apahb-gate | |
| 24 | + - sprd,sc9863a-pmu-gate | |
| 25 | + - sprd,sc9863a-aonapb-gate | |
| 26 | + - sprd,sc9863a-pll | |
| 27 | + - sprd,sc9863a-mpll | |
| 28 | + - sprd,sc9863a-rpll | |
| 29 | + - sprd,sc9863a-dpll | |
| 30 | + - sprd,sc9863a-mm-gate | |
| 31 | + - sprd,sc9863a-apapb-gate | |
| 32 | + | |
| 33 | + clocks: | |
| 34 | + minItems: 1 | |
| 35 | + maxItems: 4 | |
| 36 | + description: | | |
| 37 | + The input parent clock(s) phandle for this clock, only list fixed | |
| 38 | + clocks which are declared in devicetree. | |
| 39 | + | |
| 40 | + clock-names: | |
| 41 | + minItems: 1 | |
| 42 | + maxItems: 4 | |
| 43 | + items: | |
| 44 | + - const: ext-26m | |
| 45 | + - const: ext-32k | |
| 46 | + - const: ext-4m | |
| 47 | + - const: rco-100m | |
| 48 | + | |
| 49 | + reg: | |
| 50 | + maxItems: 1 | |
| 51 | + | |
| 52 | +required: | |
| 53 | + - compatible | |
| 54 | + - '#clock-cells' | |
| 55 | + | |
| 56 | +if: | |
| 57 | + properties: | |
| 58 | + compatible: | |
| 59 | + enum: | |
| 60 | + - sprd,sc9863a-ap-clk | |
| 61 | + - sprd,sc9863a-aon-clk | |
| 62 | +then: | |
| 63 | + required: | |
| 64 | + - reg | |
| 65 | + | |
| 66 | +else: | |
| 67 | + description: | | |
| 68 | + Other SC9863a clock nodes should be the child of a syscon node in | |
| 69 | + which compatible string shoule be: | |
| 70 | + "sprd,sc9863a-glbregs", "syscon", "simple-mfd" | |
| 71 | + | |
| 72 | + The 'reg' property for the clock node is also required if there is a sub | |
| 73 | + range of registers for the clocks. | |
| 74 | + | |
| 75 | +examples: | |
| 76 | + - | | |
| 77 | + ap_clk: clock-controller@21500000 { | |
| 78 | + compatible = "sprd,sc9863a-ap-clk"; | |
| 79 | + reg = <0 0x21500000 0 0x1000>; | |
| 80 | + clocks = <&ext_26m>, <&ext_32k>; | |
| 81 | + clock-names = "ext-26m", "ext-32k"; | |
| 82 | + #clock-cells = <1>; | |
| 83 | + }; | |
| 84 | + | |
| 85 | + - | | |
| 86 | + soc { | |
| 87 | + #address-cells = <2>; | |
| 88 | + #size-cells = <2>; | |
| 89 | + | |
| 90 | + ap_ahb_regs: syscon@20e00000 { | |
| 91 | + compatible = "sprd,sc9863a-glbregs", "syscon", "simple-mfd"; | |
| 92 | + reg = <0 0x20e00000 0 0x4000>; | |
| 93 | + #address-cells = <1>; | |
| 94 | + #size-cells = <1>; | |
| 95 | + ranges = <0 0 0x20e00000 0x4000>; | |
| 96 | + | |
| 97 | + apahb_gate: apahb-gate@0 { | |
| 98 | + compatible = "sprd,sc9863a-apahb-gate"; | |
| 99 | + reg = <0x0 0x1020>; | |
| 100 | + #clock-cells = <1>; | |
| 101 | + }; | |
| 102 | + }; | |
| 103 | + }; | |
| 104 | + | |
| 105 | +... | |
| @@ -0,0 +1,35 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/clock/ti,am654-ehrpwm-tbclk.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: TI EHRPWM Time Base Clock | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Vignesh Raghavendra <vigneshr@ti.com> | |
| 11 | + | |
| 12 | +properties: | |
| 13 | + compatible: | |
| 14 | + items: | |
| 15 | + - const: ti,am654-ehrpwm-tbclk | |
| 16 | + - const: syscon | |
| 17 | + | |
| 18 | + "#clock-cells": | |
| 19 | + const: 1 | |
| 20 | + | |
| 21 | + reg: | |
| 22 | + maxItems: 1 | |
| 23 | + | |
| 24 | +required: | |
| 25 | + - compatible | |
| 26 | + - "#clock-cells" | |
| 27 | + - reg | |
| 28 | + | |
| 29 | +examples: | |
| 30 | + - | | |
| 31 | + ehrpwm_tbclk: syscon@4140 { | |
| 32 | + compatible = "ti,am654-ehrpwm-tbclk", "syscon"; | |
| 33 | + reg = <0x4140 0x18>; | |
| 34 | + #clock-cells = <1>; | |
| 35 | + }; | |
| @@ -1,132 +0,0 @@ | ||
| 1 | −UniPhier clock controller | |
| 2 | − | |
| 3 | − | |
| 4 | −System clock | |
| 5 | −------------ | |
| 6 | − | |
| 7 | −Required properties: | |
| 8 | −- compatible: should be one of the following: | |
| 9 | − "socionext,uniphier-ld4-clock" - for LD4 SoC. | |
| 10 | − "socionext,uniphier-pro4-clock" - for Pro4 SoC. | |
| 11 | − "socionext,uniphier-sld8-clock" - for sLD8 SoC. | |
| 12 | − "socionext,uniphier-pro5-clock" - for Pro5 SoC. | |
| 13 | − "socionext,uniphier-pxs2-clock" - for PXs2/LD6b SoC. | |
| 14 | − "socionext,uniphier-ld11-clock" - for LD11 SoC. | |
| 15 | − "socionext,uniphier-ld20-clock" - for LD20 SoC. | |
| 16 | − "socionext,uniphier-pxs3-clock" - for PXs3 SoC | |
| 17 | −- #clock-cells: should be 1. | |
| 18 | − | |
| 19 | −Example: | |
| 20 | − | |
| 21 | − sysctrl@61840000 { | |
| 22 | − compatible = "socionext,uniphier-sysctrl", | |
| 23 | − "simple-mfd", "syscon"; | |
| 24 | − reg = <0x61840000 0x4000>; | |
| 25 | − | |
| 26 | − clock { | |
| 27 | − compatible = "socionext,uniphier-ld11-clock"; | |
| 28 | − #clock-cells = <1>; | |
| 29 | − }; | |
| 30 | − | |
| 31 | − other nodes ... | |
| 32 | − }; | |
| 33 | − | |
| 34 | −Provided clocks: | |
| 35 | − | |
| 36 | − 8: ST DMAC | |
| 37 | −12: GIO (Giga bit stream I/O) | |
| 38 | −14: USB3 ch0 host | |
| 39 | −15: USB3 ch1 host | |
| 40 | −16: USB3 ch0 PHY0 | |
| 41 | −17: USB3 ch0 PHY1 | |
| 42 | −20: USB3 ch1 PHY0 | |
| 43 | −21: USB3 ch1 PHY1 | |
| 44 | − | |
| 45 | − | |
| 46 | −Media I/O (MIO) clock, SD clock | |
| 47 | −------------------------------- | |
| 48 | − | |
| 49 | −Required properties: | |
| 50 | −- compatible: should be one of the following: | |
| 51 | − "socionext,uniphier-ld4-mio-clock" - for LD4 SoC. | |
| 52 | − "socionext,uniphier-pro4-mio-clock" - for Pro4 SoC. | |
| 53 | − "socionext,uniphier-sld8-mio-clock" - for sLD8 SoC. | |
| 54 | − "socionext,uniphier-pro5-sd-clock" - for Pro5 SoC. | |
| 55 | − "socionext,uniphier-pxs2-sd-clock" - for PXs2/LD6b SoC. | |
| 56 | − "socionext,uniphier-ld11-mio-clock" - for LD11 SoC. | |
| 57 | − "socionext,uniphier-ld20-sd-clock" - for LD20 SoC. | |
| 58 | − "socionext,uniphier-pxs3-sd-clock" - for PXs3 SoC | |
| 59 | −- #clock-cells: should be 1. | |
| 60 | − | |
| 61 | −Example: | |
| 62 | − | |
| 63 | − mioctrl@59810000 { | |
| 64 | − compatible = "socionext,uniphier-mioctrl", | |
| 65 | − "simple-mfd", "syscon"; | |
| 66 | − reg = <0x59810000 0x800>; | |
| 67 | − | |
| 68 | − clock { | |
| 69 | − compatible = "socionext,uniphier-ld11-mio-clock"; | |
| 70 | − #clock-cells = <1>; | |
| 71 | − }; | |
| 72 | − | |
| 73 | − other nodes ... | |
| 74 | − }; | |
| 75 | − | |
| 76 | −Provided clocks: | |
| 77 | − | |
| 78 | − 0: SD ch0 host | |
| 79 | − 1: eMMC host | |
| 80 | − 2: SD ch1 host | |
| 81 | − 7: MIO DMAC | |
| 82 | − 8: USB2 ch0 host | |
| 83 | − 9: USB2 ch1 host | |
| 84 | −10: USB2 ch2 host | |
| 85 | −12: USB2 ch0 PHY | |
| 86 | −13: USB2 ch1 PHY | |
| 87 | −14: USB2 ch2 PHY | |
| 88 | − | |
| 89 | − | |
| 90 | −Peripheral clock | |
| 91 | −---------------- | |
| 92 | − | |
| 93 | −Required properties: | |
| 94 | −- compatible: should be one of the following: | |
| 95 | − "socionext,uniphier-ld4-peri-clock" - for LD4 SoC. | |
| 96 | − "socionext,uniphier-pro4-peri-clock" - for Pro4 SoC. | |
| 97 | − "socionext,uniphier-sld8-peri-clock" - for sLD8 SoC. | |
| 98 | − "socionext,uniphier-pro5-peri-clock" - for Pro5 SoC. | |
| 99 | − "socionext,uniphier-pxs2-peri-clock" - for PXs2/LD6b SoC. | |
| 100 | − "socionext,uniphier-ld11-peri-clock" - for LD11 SoC. | |
| 101 | − "socionext,uniphier-ld20-peri-clock" - for LD20 SoC. | |
| 102 | − "socionext,uniphier-pxs3-peri-clock" - for PXs3 SoC | |
| 103 | −- #clock-cells: should be 1. | |
| 104 | − | |
| 105 | −Example: | |
| 106 | − | |
| 107 | − perictrl@59820000 { | |
| 108 | − compatible = "socionext,uniphier-perictrl", | |
| 109 | − "simple-mfd", "syscon"; | |
| 110 | − reg = <0x59820000 0x200>; | |
| 111 | − | |
| 112 | − clock { | |
| 113 | − compatible = "socionext,uniphier-ld11-peri-clock"; | |
| 114 | − #clock-cells = <1>; | |
| 115 | − }; | |
| 116 | − | |
| 117 | − other nodes ... | |
| 118 | − }; | |
| 119 | − | |
| 120 | −Provided clocks: | |
| 121 | − | |
| 122 | − 0: UART ch0 | |
| 123 | − 1: UART ch1 | |
| 124 | − 2: UART ch2 | |
| 125 | − 3: UART ch3 | |
| 126 | − 4: I2C ch0 | |
| 127 | − 5: I2C ch1 | |
| 128 | − 6: I2C ch2 | |
| 129 | − 7: I2C ch3 | |
| 130 | − 8: I2C ch4 | |
| 131 | − 9: I2C ch5 | |
| 132 | −10: I2C ch6 | |
| @@ -19,7 +19,7 @@ Required nodes: · 18 unmodified lines | ||
| 19 | 19 | 0: High Speed (HS), |
| 20 | 20 | 3: Mobile High-Definition Link (MHL), specific to 11-pin Samsung micro-USB. |
| 21 | 21 | |
| 22 | −[1]: bindings/connector/usb-connector.txt | |
| 22 | +[1]: bindings/connector/usb-connector.yaml | |
| 23 | 23 | |
| 24 | 24 | Example |
| 25 | 25 | ------- |
| @@ -1,135 +0,0 @@ | ||
| 1 | −USB Connector | |
| 2 | −============= | |
| 3 | − | |
| 4 | −A USB connector node represents a physical USB connector. It should be | |
| 5 | −a child of a USB interface controller. | |
| 6 | − | |
| 7 | −Required properties: | |
| 8 | −- compatible: describes type of the connector, must be one of: | |
| 9 | − "usb-a-connector", | |
| 10 | − "usb-b-connector", | |
| 11 | − "usb-c-connector". | |
| 12 | − | |
| 13 | −Optional properties: | |
| 14 | −- label: symbolic name for the connector, | |
| 15 | −- type: size of the connector, should be specified in case of USB-A, USB-B | |
| 16 | − non-fullsize connectors: "mini", "micro". | |
| 17 | −- self-powered: Set this property if the usb device that has its own power | |
| 18 | − source. | |
| 19 | − | |
| 20 | −Optional properties for usb-b-connector: | |
| 21 | −- id-gpios: an input gpio for USB ID pin. | |
| 22 | −- vbus-gpios: an input gpio for USB VBUS pin, used to detect presence of | |
| 23 | − VBUS 5V. | |
| 24 | − see gpio/gpio.txt. | |
| 25 | −- vbus-supply: a phandle to the regulator for USB VBUS if needed when host | |
| 26 | − mode or dual role mode is supported. | |
| 27 | − Particularly, if use an output GPIO to control a VBUS regulator, should | |
| 28 | − model it as a regulator. | |
| 29 | − see regulator/fixed-regulator.yaml | |
| 30 | −- pinctrl-names : a pinctrl state named "default" is optional | |
| 31 | −- pinctrl-0 : pin control group | |
| 32 | − see pinctrl/pinctrl-bindings.txt | |
| 33 | − | |
| 34 | −Optional properties for usb-c-connector: | |
| 35 | −- power-role: should be one of "source", "sink" or "dual"(DRP) if typec | |
| 36 | − connector has power support. | |
| 37 | −- try-power-role: preferred power role if "dual"(DRP) can support Try.SNK | |
| 38 | − or Try.SRC, should be "sink" for Try.SNK or "source" for Try.SRC. | |
| 39 | −- data-role: should be one of "host", "device", "dual"(DRD) if typec | |
| 40 | − connector supports USB data. | |
| 41 | − | |
| 42 | −Required properties for usb-c-connector with power delivery support: | |
| 43 | −- source-pdos: An array of u32 with each entry providing supported power | |
| 44 | − source data object(PDO), the detailed bit definitions of PDO can be found | |
| 45 | − in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2 | |
| 46 | − Source_Capabilities Message, the order of each entry(PDO) should follow | |
| 47 | − the PD spec chapter 6.4.1. Required for power source and power dual role. | |
| 48 | − User can specify the source PDO array via PDO_FIXED/BATT/VAR/PPS_APDO() | |
| 49 | − defined in dt-bindings/usb/pd.h. | |
| 50 | −- sink-pdos: An array of u32 with each entry providing supported power | |
| 51 | − sink data object(PDO), the detailed bit definitions of PDO can be found | |
| 52 | − in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3 | |
| 53 | − Sink Capabilities Message, the order of each entry(PDO) should follow | |
| 54 | − the PD spec chapter 6.4.1. Required for power sink and power dual role. | |
| 55 | − User can specify the sink PDO array via PDO_FIXED/BATT/VAR/PPS_APDO() defined | |
| 56 | − in dt-bindings/usb/pd.h. | |
| 57 | −- op-sink-microwatt: Sink required operating power in microwatt, if source | |
| 58 | − can't offer the power, Capability Mismatch is set. Required for power | |
| 59 | − sink and power dual role. | |
| 60 | − | |
| 61 | −Required nodes: | |
| 62 | −- any data bus to the connector should be modeled using the OF graph bindings | |
| 63 | − specified in bindings/graph.txt, unless the bus is between parent node and | |
| 64 | − the connector. Since single connector can have multiple data buses every bus | |
| 65 | − has assigned OF graph port number as follows: | |
| 66 | − 0: High Speed (HS), present in all connectors, | |
| 67 | − 1: Super Speed (SS), present in SS capable connectors, | |
| 68 | − 2: Sideband use (SBU), present in USB-C. | |
| 69 | − | |
| 70 | −Examples | |
| 71 | −-------- | |
| 72 | − | |
| 73 | −1. Micro-USB connector with HS lines routed via controller (MUIC): | |
| 74 | − | |
| 75 | −muic-max77843@66 { | |
| 76 | − ... | |
| 77 | − usb_con: connector { | |
| 78 | − compatible = "usb-b-connector"; | |
| 79 | − label = "micro-USB"; | |
| 80 | − type = "micro"; | |
| 81 | − }; | |
| 82 | −}; | |
| 83 | − | |
| 84 | −2. USB-C connector attached to CC controller (s2mm005), HS lines routed | |
| 85 | −to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort. | |
| 86 | −DisplayPort video lines are routed to the connector via SS mux in USB3 PHY. | |
| 87 | − | |
| 88 | −ccic: s2mm005@33 { | |
| 89 | − ... | |
| 90 | − usb_con: connector { | |
| 91 | − compatible = "usb-c-connector"; | |
| 92 | − label = "USB-C"; | |
| 93 | − | |
| 94 | − ports { | |
| 95 | − #address-cells = <1>; | |
| 96 | − #size-cells = <0>; | |
| 97 | − | |
| 98 | − port@0 { | |
| 99 | − reg = <0>; | |
| 100 | − usb_con_hs: endpoint { | |
| 101 | − remote-endpoint = <&max77865_usbc_hs>; | |
| 102 | − }; | |
| 103 | − }; | |
| 104 | − port@1 { | |
| 105 | − reg = <1>; | |
| 106 | − usb_con_ss: endpoint { | |
| 107 | − remote-endpoint = <&usbdrd_phy_ss>; | |
| 108 | − }; | |
| 109 | − }; | |
| 110 | − port@2 { | |
| 111 | − reg = <2>; | |
| 112 | − usb_con_sbu: endpoint { | |
| 113 | − remote-endpoint = <&dp_aux>; | |
| 114 | − }; | |
| 115 | − }; | |
| 116 | − }; | |
| 117 | − }; | |
| 118 | −}; | |
| 119 | − | |
| 120 | −3. USB-C connector attached to a typec port controller(ptn5110), which has | |
| 121 | −power delivery support and enables drp. | |
| 122 | − | |
| 123 | −typec: ptn5110@50 { | |
| 124 | − ... | |
| 125 | − usb_con: connector { | |
| 126 | − compatible = "usb-c-connector"; | |
| 127 | − label = "USB-C"; | |
| 128 | − power-role = "dual"; | |
| 129 | − try-power-role = "sink"; | |
| 130 | − source-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)>; | |
| 131 | − sink-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM) | |
| 132 | − PDO_VAR(5000, 12000, 2000)>; | |
| 133 | − op-sink-microwatt = <10000000>; | |
| 134 | − }; | |
| 135 | −}; | |
| @@ -0,0 +1,206 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0-only | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/connector/usb-connector.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: USB Connector | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Rob Herring <robh@kernel.org> | |
| 11 | + | |
| 12 | +description: | |
| 13 | + A USB connector node represents a physical USB connector. It should be a child | |
| 14 | + of a USB interface controller. | |
| 15 | + | |
| 16 | +properties: | |
| 17 | + compatible: | |
| 18 | + enum: | |
| 19 | + - usb-a-connector | |
| 20 | + - usb-b-connector | |
| 21 | + - usb-c-connector | |
| 22 | + | |
| 23 | + label: | |
| 24 | + description: Symbolic name for the connector. | |
| 25 | + | |
| 26 | + type: | |
| 27 | + description: Size of the connector, should be specified in case of | |
| 28 | + non-fullsize 'usb-a-connector' or 'usb-b-connector' compatible | |
| 29 | + connectors. | |
| 30 | + allOf: | |
| 31 | + - $ref: /schemas/types.yaml#definitions/string | |
| 32 | + enum: | |
| 33 | + - mini | |
| 34 | + - micro | |
| 35 | + | |
| 36 | + self-powered: | |
| 37 | + description: Set this property if the USB device has its own power source. | |
| 38 | + type: boolean | |
| 39 | + | |
| 40 | + # The following are optional properties for "usb-b-connector". | |
| 41 | + id-gpios: | |
| 42 | + description: An input gpio for USB ID pin. | |
| 43 | + maxItems: 1 | |
| 44 | + | |
| 45 | + vbus-gpios: | |
| 46 | + description: An input gpio for USB VBus pin, used to detect presence of | |
| 47 | + VBUS 5V. | |
| 48 | + maxItems: 1 | |
| 49 | + | |
| 50 | + vbus-supply: | |
| 51 | + description: A phandle to the regulator for USB VBUS if needed when host | |
| 52 | + mode or dual role mode is supported. | |
| 53 | + Particularly, if use an output GPIO to control a VBUS regulator, should | |
| 54 | + model it as a regulator. See bindings/regulator/fixed-regulator.yaml | |
| 55 | + | |
| 56 | + # The following are optional properties for "usb-c-connector". | |
| 57 | + power-role: | |
| 58 | + description: Determines the power role that the Type C connector will | |
| 59 | + support. "dual" refers to Dual Role Port (DRP). | |
| 60 | + allOf: | |
| 61 | + - $ref: /schemas/types.yaml#definitions/string | |
| 62 | + enum: | |
| 63 | + - source | |
| 64 | + - sink | |
| 65 | + - dual | |
| 66 | + | |
| 67 | + try-power-role: | |
| 68 | + description: Preferred power role. | |
| 69 | + allOf: | |
| 70 | + - $ref: /schemas/types.yaml#definitions/string | |
| 71 | + enum: | |
| 72 | + - source | |
| 73 | + - sink | |
| 74 | + - dual | |
| 75 | + | |
| 76 | + data-role: | |
| 77 | + description: Data role if Type C connector supports USB data. "dual" refers | |
| 78 | + Dual Role Device (DRD). | |
| 79 | + allOf: | |
| 80 | + - $ref: /schemas/types.yaml#definitions/string | |
| 81 | + enum: | |
| 82 | + - host | |
| 83 | + - device | |
| 84 | + - dual | |
| 85 | + | |
| 86 | + # The following are optional properties for "usb-c-connector" with power | |
| 87 | + # delivery support. | |
| 88 | + source-pdos: | |
| 89 | + description: An array of u32 with each entry providing supported power | |
| 90 | + source data object(PDO), the detailed bit definitions of PDO can be found | |
| 91 | + in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2 | |
| 92 | + Source_Capabilities Message, the order of each entry(PDO) should follow | |
| 93 | + the PD spec chapter 6.4.1. Required for power source and power dual role. | |
| 94 | + User can specify the source PDO array via PDO_FIXED/BATT/VAR/PPS_APDO() | |
| 95 | + defined in dt-bindings/usb/pd.h. | |
| 96 | + minItems: 1 | |
| 97 | + maxItems: 7 | |
| 98 | + allOf: | |
| 99 | + - $ref: /schemas/types.yaml#/definitions/uint32-array | |
| 100 | + | |
| 101 | + sink-pdos: | |
| 102 | + description: An array of u32 with each entry providing supported power sink | |
| 103 | + data object(PDO), the detailed bit definitions of PDO can be found in | |
| 104 | + "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3 | |
| 105 | + Sink Capabilities Message, the order of each entry(PDO) should follow the | |
| 106 | + PD spec chapter 6.4.1. Required for power sink and power dual role. User | |
| 107 | + can specify the sink PDO array via PDO_FIXED/BATT/VAR/PPS_APDO() defined | |
| 108 | + in dt-bindings/usb/pd.h. | |
| 109 | + minItems: 1 | |
| 110 | + maxItems: 7 | |
| 111 | + allOf: | |
| 112 | + - $ref: /schemas/types.yaml#/definitions/uint32-array | |
| 113 | + | |
| 114 | + op-sink-microwatt: | |
| 115 | + description: Sink required operating power in microwatt, if source can't | |
| 116 | + offer the power, Capability Mismatch is set. Required for power sink and | |
| 117 | + power dual role. | |
| 118 | + | |
| 119 | + ports: | |
| 120 | + description: OF graph bindings (specified in bindings/graph.txt) that model | |
| 121 | + any data bus to the connector unless the bus is between parent node and | |
| 122 | + the connector. Since a single connector can have multiple data buses every | |
| 123 | + bus has an assigned OF graph port number as described below. | |
| 124 | + type: object | |
| 125 | + properties: | |
| 126 | + port@0: | |
| 127 | + type: object | |
| 128 | + description: High Speed (HS), present in all connectors. | |
| 129 | + | |
| 130 | + port@1: | |
| 131 | + type: object | |
| 132 | + description: Super Speed (SS), present in SS capable connectors. | |
| 133 | + | |
| 134 | + port@2: | |
| 135 | + type: object | |
| 136 | + description: Sideband Use (SBU), present in USB-C. This describes the | |
| 137 | + alternate mode connection of which SBU is a part. | |
| 138 | + | |
| 139 | + required: | |
| 140 | + - port@0 | |
| 141 | + | |
| 142 | +required: | |
| 143 | + - compatible | |
| 144 | + | |
| 145 | +examples: | |
| 146 | + # Micro-USB connector with HS lines routed via controller (MUIC). | |
| 147 | + - |+ | |
| 148 | + muic-max77843 { | |
| 149 | + usb_con1: connector { | |
| 150 | + compatible = "usb-b-connector"; | |
| 151 | + label = "micro-USB"; | |
| 152 | + type = "micro"; | |
| 153 | + }; | |
| 154 | + }; | |
| 155 | + | |
| 156 | + # USB-C connector attached to CC controller (s2mm005), HS lines routed | |
| 157 | + # to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort. | |
| 158 | + # DisplayPort video lines are routed to the connector via SS mux in USB3 PHY. | |
| 159 | + - |+ | |
| 160 | + ccic: s2mm005 { | |
| 161 | + usb_con2: connector { | |
| 162 | + compatible = "usb-c-connector"; | |
| 163 | + label = "USB-C"; | |
| 164 | + | |
| 165 | + ports { | |
| 166 | + #address-cells = <1>; | |
| 167 | + #size-cells = <0>; | |
| 168 | + | |
| 169 | + port@0 { | |
| 170 | + reg = <0>; | |
| 171 | + usb_con_hs: endpoint { | |
| 172 | + remote-endpoint = <&max77865_usbc_hs>; | |
| 173 | + }; | |
| 174 | + }; | |
| 175 | + port@1 { | |
| 176 | + reg = <1>; | |
| 177 | + usb_con_ss: endpoint { | |
| 178 | + remote-endpoint = <&usbdrd_phy_ss>; | |
| 179 | + }; | |
| 180 | + }; | |
| 181 | + port@2 { | |
| 182 | + reg = <2>; | |
| 183 | + usb_con_sbu: endpoint { | |
| 184 | + remote-endpoint = <&dp_aux>; | |
| 185 | + }; | |
| 186 | + }; | |
| 187 | + }; | |
| 188 | + }; | |
| 189 | + }; | |
| 190 | + | |
| 191 | + # USB-C connector attached to a typec port controller(ptn5110), which has | |
| 192 | + # power delivery support and enables drp. | |
| 193 | + - |+ | |
| 194 | + #include <dt-bindings/usb/pd.h> | |
| 195 | + typec: ptn5110 { | |
| 196 | + usb_con3: connector { | |
| 197 | + compatible = "usb-c-connector"; | |
| 198 | + label = "USB-C"; | |
| 199 | + power-role = "dual"; | |
| 200 | + try-power-role = "sink"; | |
| 201 | + source-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)>; | |
| 202 | + sink-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM) | |
| 203 | + PDO_VAR(5000, 12000, 2000)>; | |
| 204 | + op-sink-microwatt = <10000000>; | |
| 205 | + }; | |
| 206 | + }; | |
| @@ -23,6 +23,8 @@ properties: · 22 unmodified lines | ||
| 23 | 23 | - items: |
| 24 | 24 | - const: allwinner,sun7i-a20-crypto |
| 25 | 25 | - const: allwinner,sun4i-a10-crypto |
| 26 | + - items: | |
| 27 | + - const: allwinner,sun8i-a33-crypto | |
| 26 | 28 | |
| 27 | 29 | reg: |
| 28 | 30 | maxItems: 1 |
| @@ -11,7 +11,7 @@ Required properties: · 10 unmodified lines | ||
| 11 | 11 | |
| 12 | 12 | Example: |
| 13 | 13 | |
| 14 | −dcp@80028000 { | |
| 14 | +dcp: crypto@80028000 { | |
| 15 | 15 | compatible = "fsl,imx28-dcp", "fsl,imx23-dcp"; |
| 16 | 16 | reg = <0x80028000 0x2000>; |
| 17 | 17 | interrupts = <52 53>; |
| @@ -8,7 +8,7 @@ Required properties: · 7 unmodified lines | ||
| 8 | 8 | |
| 9 | 9 | Example: |
| 10 | 10 | |
| 11 | −sah@10025000 { | |
| 11 | +sah: crypto@10025000 { | |
| 12 | 12 | compatible = "fsl,imx27-sahara"; |
| 13 | 13 | reg = < 0x10025000 0x800>; |
| 14 | 14 | interrupts = <75>; |
| @@ -138,7 +138,7 @@ iMX6QDL/SX requires four clocks · 137 unmodified lines | ||
| 138 | 138 | |
| 139 | 139 | iMX6UL does only require three clocks |
| 140 | 140 | |
| 141 | − crypto: caam@2140000 { | |
| 141 | + crypto: crypto@2140000 { | |
| 142 | 142 | compatible = "fsl,sec-v4.0"; |
| 143 | 143 | #address-cells = <1>; |
| 144 | 144 | #size-cells = <1>; |
| @@ -0,0 +1,37 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/crypto/xlnx,zynqmp-aes.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Xilinx ZynqMP AES-GCM Hardware Accelerator Device Tree Bindings | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Kalyani Akula <kalyani.akula@xilinx.com> | |
| 11 | + - Michal Simek <michal.simek@xilinx.com> | |
| 12 | + | |
| 13 | +description: | | |
| 14 | + The ZynqMP AES-GCM hardened cryptographic accelerator is used to | |
| 15 | + encrypt or decrypt the data with provided key and initialization vector. | |
| 16 | + | |
| 17 | +properties: | |
| 18 | + compatible: | |
| 19 | + const: xlnx,zynqmp-aes | |
| 20 | + | |
| 21 | +required: | |
| 22 | + - compatible | |
| 23 | + | |
| 24 | +additionalProperties: false | |
| 25 | + | |
| 26 | +examples: | |
| 27 | + - | | |
| 28 | + firmware { | |
| 29 | + zynqmp_firmware: zynqmp-firmware { | |
| 30 | + compatible = "xlnx,zynqmp-firmware"; | |
| 31 | + method = "smc"; | |
| 32 | + xlnx_aes: zynqmp-aes { | |
| 33 | + compatible = "xlnx,zynqmp-aes"; | |
| 34 | + }; | |
| 35 | + }; | |
| 36 | + }; | |
| 37 | +... | |
| @@ -71,9 +71,9 @@ properties: · 70 unmodified lines | ||
| 71 | 71 | maxItems: 2 |
| 72 | 72 | |
| 73 | 73 | reg-names: |
| 74 | − items: | |
| 75 | − - const: vpu | |
| 76 | − - const: hhi | |
| 74 | + items: | |
| 75 | + - const: vpu | |
| 76 | + - const: hhi | |
| 77 | 77 | |
| 78 | 78 | interrupts: |
| 79 | 79 | maxItems: 1 |
| @@ -107,6 +107,8 @@ required: · 27 unmodified lines | ||
| 107 | 107 | - "#address-cells" |
| 108 | 108 | - "#size-cells" |
| 109 | 109 | |
| 110 | +additionalProperties: false | |
| 111 | + | |
| 110 | 112 | examples: |
| 111 | 113 | - | |
| 112 | 114 | vpu: vpu@d0100000 { |
| @@ -6,16 +6,22 @@ Required properties: · 5 unmodified lines | ||
| 6 | 6 | |
| 7 | 7 | Optional properties: |
| 8 | 8 | - label: a symbolic name for the connector |
| 9 | +- sdtv-standards: limit the supported TV standards on a connector to the given | |
| 10 | + ones. If not specified all TV standards are allowed. | |
| 11 | + Possible TV standards are defined in | |
| 12 | + include/dt-bindings/display/sdtv-standards.h. | |
| 9 | 13 | |
| 10 | 14 | Required nodes: |
| 11 | 15 | - Video port for TV input |
| 12 | 16 | |
| 13 | 17 | Example |
| 14 | 18 | ------- |
| 19 | +#include <dt-bindings/display/sdtv-standards.h> | |
| 15 | 20 | |
| 16 | 21 | tv: connector { |
| 17 | 22 | compatible = "composite-video-connector"; |
| 18 | 23 | label = "tv"; |
| 24 | + sdtv-standards = <(SDTV_STD_PAL | SDTV_STD_NTSC)>; | |
| 19 | 25 | |
| 20 | 26 | port { |
| 21 | 27 | tv_connector_in: endpoint { |
| @@ -1,36 +0,0 @@ | ||
| 1 | −Vivante GPU core devices | |
| 2 | −======================== | |
| 3 | − | |
| 4 | −Required properties: | |
| 5 | −- compatible: Should be "vivante,gc" | |
| 6 | − A more specific compatible is not needed, as the cores contain chip | |
| 7 | − identification registers at fixed locations, which provide all the | |
| 8 | − necessary information to the driver. | |
| 9 | −- reg: should be register base and length as documented in the | |
| 10 | − datasheet | |
| 11 | −- interrupts: Should contain the cores interrupt line | |
| 12 | −- clocks: should contain one clock for entry in clock-names | |
| 13 | − see Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 14 | −- clock-names: | |
| 15 | − - "bus": AXI/master interface clock | |
| 16 | − - "reg": AHB/slave interface clock | |
| 17 | − (only required if GPU can gate slave interface independently) | |
| 18 | − - "core": GPU core clock | |
| 19 | − - "shader": Shader clock (only required if GPU has feature PIPE_3D) | |
| 20 | − | |
| 21 | −Optional properties: | |
| 22 | −- power-domains: a power domain consumer specifier according to | |
| 23 | − Documentation/devicetree/bindings/power/power_domain.txt | |
| 24 | − | |
| 25 | −example: | |
| 26 | − | |
| 27 | −gpu_3d: gpu@130000 { | |
| 28 | − compatible = "vivante,gc"; | |
| 29 | − reg = <0x00130000 0x4000>; | |
| 30 | − interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>; | |
| 31 | − clocks = <&clks IMX6QDL_CLK_GPU3D_AXI>, | |
| 32 | − <&clks IMX6QDL_CLK_GPU3D_CORE>, | |
| 33 | − <&clks IMX6QDL_CLK_GPU3D_SHADER>; | |
| 34 | − clock-names = "bus", "core", "shader"; | |
| 35 | − power-domains = <&gpc 1>; | |
| 36 | −}; | |
| @@ -1,116 +0,0 @@ | ||
| 1 | −Qualcomm adreno/snapdragon GMU (Graphics management unit) | |
| 2 | − | |
| 3 | −The GMU is a programmable power controller for the GPU. the CPU controls the | |
| 4 | −GMU which in turn handles power controls for the GPU. | |
| 5 | − | |
| 6 | −Required properties: | |
| 7 | −- compatible: "qcom,adreno-gmu-XYZ.W", "qcom,adreno-gmu" | |
| 8 | − for example: "qcom,adreno-gmu-630.2", "qcom,adreno-gmu" | |
| 9 | − Note that you need to list the less specific "qcom,adreno-gmu" | |
| 10 | − for generic matches and the more specific identifier to identify | |
| 11 | − the specific device. | |
| 12 | −- reg: Physical base address and length of the GMU registers. | |
| 13 | −- reg-names: Matching names for the register regions | |
| 14 | − * "gmu" | |
| 15 | − * "gmu_pdc" | |
| 16 | − * "gmu_pdc_seg" | |
| 17 | −- interrupts: The interrupt signals from the GMU. | |
| 18 | −- interrupt-names: Matching names for the interrupts | |
| 19 | − * "hfi" | |
| 20 | − * "gmu" | |
| 21 | −- clocks: phandles to the device clocks | |
| 22 | −- clock-names: Matching names for the clocks | |
| 23 | − * "gmu" | |
| 24 | − * "cxo" | |
| 25 | − * "axi" | |
| 26 | − * "mnoc" | |
| 27 | −- power-domains: should be: | |
| 28 | − <&clock_gpucc GPU_CX_GDSC> | |
| 29 | − <&clock_gpucc GPU_GX_GDSC> | |
| 30 | −- power-domain-names: Matching names for the power domains | |
| 31 | −- iommus: phandle to the adreno iommu | |
| 32 | −- operating-points-v2: phandle to the OPP operating points | |
| 33 | − | |
| 34 | −Optional properties: | |
| 35 | −- sram: phandle to the On Chip Memory (OCMEM) that's present on some Snapdragon | |
| 36 | − SoCs. See Documentation/devicetree/bindings/sram/qcom,ocmem.yaml. | |
| 37 | − | |
| 38 | −Example: | |
| 39 | − | |
| 40 | −/ { | |
| 41 | − ... | |
| 42 | − | |
| 43 | − gmu: gmu@506a000 { | |
| 44 | − compatible="qcom,adreno-gmu-630.2", "qcom,adreno-gmu"; | |
| 45 | − | |
| 46 | − reg = <0x506a000 0x30000>, | |
| 47 | − <0xb280000 0x10000>, | |
| 48 | − <0xb480000 0x10000>; | |
| 49 | − reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq"; | |
| 50 | − | |
| 51 | − interrupts = <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>, | |
| 52 | − <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>; | |
| 53 | − interrupt-names = "hfi", "gmu"; | |
| 54 | − | |
| 55 | − clocks = <&gpucc GPU_CC_CX_GMU_CLK>, | |
| 56 | − <&gpucc GPU_CC_CXO_CLK>, | |
| 57 | − <&gcc GCC_DDRSS_GPU_AXI_CLK>, | |
| 58 | − <&gcc GCC_GPU_MEMNOC_GFX_CLK>; | |
| 59 | − clock-names = "gmu", "cxo", "axi", "memnoc"; | |
| 60 | − | |
| 61 | − power-domains = <&gpucc GPU_CX_GDSC>, | |
| 62 | − <&gpucc GPU_GX_GDSC>; | |
| 63 | − power-domain-names = "cx", "gx"; | |
| 64 | − | |
| 65 | − iommus = <&adreno_smmu 5>; | |
| 66 | − | |
| 67 | − operating-points-v2 = <&gmu_opp_table>; | |
| 68 | − }; | |
| 69 | −}; | |
| 70 | − | |
| 71 | −a3xx example with OCMEM support: | |
| 72 | − | |
| 73 | −/ { | |
| 74 | − ... | |
| 75 | − | |
| 76 | − gpu: adreno@fdb00000 { | |
| 77 | − compatible = "qcom,adreno-330.2", | |
| 78 | − "qcom,adreno"; | |
| 79 | − reg = <0xfdb00000 0x10000>; | |
| 80 | − reg-names = "kgsl_3d0_reg_memory"; | |
| 81 | − interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>; | |
| 82 | − interrupt-names = "kgsl_3d0_irq"; | |
| 83 | − clock-names = "core", | |
| 84 | − "iface", | |
| 85 | − "mem_iface"; | |
| 86 | − clocks = <&mmcc OXILI_GFX3D_CLK>, | |
| 87 | − <&mmcc OXILICX_AHB_CLK>, | |
| 88 | − <&mmcc OXILICX_AXI_CLK>; | |
| 89 | − sram = <&gmu_sram>; | |
| 90 | − power-domains = <&mmcc OXILICX_GDSC>; | |
| 91 | − operating-points-v2 = <&gpu_opp_table>; | |
| 92 | − iommus = <&gpu_iommu 0>; | |
| 93 | − }; | |
| 94 | − | |
| 95 | − ocmem@fdd00000 { | |
| 96 | − compatible = "qcom,msm8974-ocmem"; | |
| 97 | − | |
| 98 | − reg = <0xfdd00000 0x2000>, | |
| 99 | − <0xfec00000 0x180000>; | |
| 100 | − reg-names = "ctrl", | |
| 101 | − "mem"; | |
| 102 | − | |
| 103 | − clocks = <&rpmcc RPM_SMD_OCMEMGX_CLK>, | |
| 104 | − <&mmcc OCMEMCX_OCMEMNOC_CLK>; | |
| 105 | − clock-names = "core", | |
| 106 | − "iface"; | |
| 107 | − | |
| 108 | − #address-cells = <1>; | |
| 109 | − #size-cells = <1>; | |
| 110 | − | |
| 111 | − gmu_sram: gmu-sram@0 { | |
| 112 | − reg = <0x0 0x100000>; | |
| 113 | − ranges = <0 0 0xfec00000 0x100000>; | |
| 114 | − }; | |
| 115 | − }; | |
| 116 | −}; | |
| @@ -0,0 +1,123 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0-only | |
| 2 | +# Copyright 2019-2020, The Linux Foundation, All Rights Reserved | |
| 3 | +%YAML 1.2 | |
| 4 | +--- | |
| 5 | + | |
| 6 | +$id: "http://devicetree.org/schemas/display/msm/gmu.yaml#" | |
| 7 | +$schema: "http://devicetree.org/meta-schemas/core.yaml#" | |
| 8 | + | |
| 9 | +title: Devicetree bindings for the GMU attached to certain Adreno GPUs | |
| 10 | + | |
| 11 | +maintainers: | |
| 12 | + - Rob Clark <robdclark@gmail.com> | |
| 13 | + | |
| 14 | +description: | | |
| 15 | + These bindings describe the Graphics Management Unit (GMU) that is attached | |
| 16 | + to members of the Adreno A6xx GPU family. The GMU provides on-device power | |
| 17 | + management and support to improve power efficiency and reduce the load on | |
| 18 | + the CPU. | |
| 19 | + | |
| 20 | +properties: | |
| 21 | + compatible: | |
| 22 | + items: | |
| 23 | + - enum: | |
| 24 | + - qcom,adreno-gmu-630.2 | |
| 25 | + - const: qcom,adreno-gmu | |
| 26 | + | |
| 27 | + reg: | |
| 28 | + items: | |
| 29 | + - description: Core GMU registers | |
| 30 | + - description: GMU PDC registers | |
| 31 | + - description: GMU PDC sequence registers | |
| 32 | + | |
| 33 | + reg-names: | |
| 34 | + items: | |
| 35 | + - const: gmu | |
| 36 | + - const: gmu_pdc | |
| 37 | + - const: gmu_pdc_seq | |
| 38 | + | |
| 39 | + clocks: | |
| 40 | + items: | |
| 41 | + - description: GMU clock | |
| 42 | + - description: GPU CX clock | |
| 43 | + - description: GPU AXI clock | |
| 44 | + - description: GPU MEMNOC clock | |
| 45 | + | |
| 46 | + clock-names: | |
| 47 | + items: | |
| 48 | + - const: gmu | |
| 49 | + - const: cxo | |
| 50 | + - const: axi | |
| 51 | + - const: memnoc | |
| 52 | + | |
| 53 | + interrupts: | |
| 54 | + items: | |
| 55 | + - description: GMU HFI interrupt | |
| 56 | + - description: GMU interrupt | |
| 57 | + | |
| 58 | + | |
| 59 | + interrupt-names: | |
| 60 | + items: | |
| 61 | + - const: hfi | |
| 62 | + - const: gmu | |
| 63 | + | |
| 64 | + power-domains: | |
| 65 | + items: | |
| 66 | + - description: CX power domain | |
| 67 | + - description: GX power domain | |
| 68 | + | |
| 69 | + power-domain-names: | |
| 70 | + items: | |
| 71 | + - const: cx | |
| 72 | + - const: gx | |
| 73 | + | |
| 74 | + iommus: | |
| 75 | + maxItems: 1 | |
| 76 | + | |
| 77 | + operating-points-v2: true | |
| 78 | + | |
| 79 | +required: | |
| 80 | + - compatible | |
| 81 | + - reg | |
| 82 | + - reg-names | |
| 83 | + - clocks | |
| 84 | + - clock-names | |
| 85 | + - interrupts | |
| 86 | + - interrupt-names | |
| 87 | + - power-domains | |
| 88 | + - power-domain-names | |
| 89 | + - iommus | |
| 90 | + - operating-points-v2 | |
| 91 | + | |
| 92 | +examples: | |
| 93 | + - | | |
| 94 | + #include <dt-bindings/clock/qcom,gpucc-sdm845.h> | |
| 95 | + #include <dt-bindings/clock/qcom,gcc-sdm845.h> | |
| 96 | + #include <dt-bindings/interrupt-controller/irq.h> | |
| 97 | + #include <dt-bindings/interrupt-controller/arm-gic.h> | |
| 98 | + | |
| 99 | + gmu: gmu@506a000 { | |
| 100 | + compatible="qcom,adreno-gmu-630.2", "qcom,adreno-gmu"; | |
| 101 | + | |
| 102 | + reg = <0x506a000 0x30000>, | |
| 103 | + <0xb280000 0x10000>, | |
| 104 | + <0xb480000 0x10000>; | |
| 105 | + reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq"; | |
| 106 | + | |
| 107 | + clocks = <&gpucc GPU_CC_CX_GMU_CLK>, | |
| 108 | + <&gpucc GPU_CC_CXO_CLK>, | |
| 109 | + <&gcc GCC_DDRSS_GPU_AXI_CLK>, | |
| 110 | + <&gcc GCC_GPU_MEMNOC_GFX_CLK>; | |
| 111 | + clock-names = "gmu", "cxo", "axi", "memnoc"; | |
| 112 | + | |
| 113 | + interrupts = <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>, | |
| 114 | + <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>; | |
| 115 | + interrupt-names = "hfi", "gmu"; | |
| 116 | + | |
| 117 | + power-domains = <&gpucc GPU_CX_GDSC>, | |
| 118 | + <&gpucc GPU_GX_GDSC>; | |
| 119 | + power-domain-names = "cx", "gx"; | |
| 120 | + | |
| 121 | + iommus = <&adreno_smmu 5>; | |
| 122 | + operating-points-v2 = <&gmu_opp_table>; | |
| 123 | + }; | |
| @@ -35,25 +35,54 @@ Required properties: · 34 unmodified lines | ||
| 35 | 35 | bring the GPU out of secure mode. |
| 36 | 36 | - firmware-name: optional property of the 'zap-shader' node, listing the |
| 37 | 37 | relative path of the device specific zap firmware. |
| 38 | +- sram: phandle to the On Chip Memory (OCMEM) that's present on some a3xx and | |
| 39 | + a4xx Snapdragon SoCs. See | |
| 40 | + Documentation/devicetree/bindings/sram/qcom,ocmem.yaml. | |
| 38 | 41 | |
| 39 | −Example 3xx/4xx/a5xx: | |
| 42 | +Example 3xx/4xx: | |
| 40 | 43 | |
| 41 | 44 | / { |
| 42 | 45 | ... |
| 43 | 46 | |
| 44 | − gpu: qcom,kgsl-3d0@4300000 { | |
| 45 | − compatible = "qcom,adreno-320.2", "qcom,adreno"; | |
| 46 | − reg = <0x04300000 0x20000>; | |
| 47 | + gpu: adreno@fdb00000 { | |
| 48 | + compatible = "qcom,adreno-330.2", | |
| 49 | + "qcom,adreno"; | |
| 50 | + reg = <0xfdb00000 0x10000>; | |
| 47 | 51 | reg-names = "kgsl_3d0_reg_memory"; |
| 48 | − interrupts = <GIC_SPI 80 0>; | |
| 49 | − clock-names = | |
| 50 | − "core", | |
| 51 | − "iface", | |
| 52 | − "mem_iface"; | |
| 53 | − clocks = | |
| 54 | − <&mmcc GFX3D_CLK>, | |
| 55 | − <&mmcc GFX3D_AHB_CLK>, | |
| 56 | − <&mmcc MMSS_IMEM_AHB_CLK>; | |
| 52 | + interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>; | |
| 53 | + interrupt-names = "kgsl_3d0_irq"; | |
| 54 | + clock-names = "core", | |
| 55 | + "iface", | |
| 56 | + "mem_iface"; | |
| 57 | + clocks = <&mmcc OXILI_GFX3D_CLK>, | |
| 58 | + <&mmcc OXILICX_AHB_CLK>, | |
| 59 | + <&mmcc OXILICX_AXI_CLK>; | |
| 60 | + sram = <&gpu_sram>; | |
| 61 | + power-domains = <&mmcc OXILICX_GDSC>; | |
| 62 | + operating-points-v2 = <&gpu_opp_table>; | |
| 63 | + iommus = <&gpu_iommu 0>; | |
| 64 | + }; | |
| 65 | + | |
| 66 | + gpu_sram: ocmem@fdd00000 { | |
| 67 | + compatible = "qcom,msm8974-ocmem"; | |
| 68 | + | |
| 69 | + reg = <0xfdd00000 0x2000>, | |
| 70 | + <0xfec00000 0x180000>; | |
| 71 | + reg-names = "ctrl", | |
| 72 | + "mem"; | |
| 73 | + | |
| 74 | + clocks = <&rpmcc RPM_SMD_OCMEMGX_CLK>, | |
| 75 | + <&mmcc OCMEMCX_OCMEMNOC_CLK>; | |
| 76 | + clock-names = "core", | |
| 77 | + "iface"; | |
| 78 | + | |
| 79 | + #address-cells = <1>; | |
| 80 | + #size-cells = <1>; | |
| 81 | + | |
| 82 | + gpu_sram: gpu-sram@0 { | |
| 83 | + reg = <0x0 0x100000>; | |
| 84 | + ranges = <0 0 0xfec00000 0x100000>; | |
| 85 | + }; | |
| 57 | 86 | }; |
| 58 | 87 | }; |
| 59 | 88 | |
| @@ -21,15 +21,6 @@ properties: · 20 unmodified lines | ||
| 21 | 21 | - {} |
| 22 | 22 | - const: panel-dpi |
| 23 | 23 | |
| 24 | − data-mapping: | |
| 25 | − enum: | |
| 26 | − - rgb24 | |
| 27 | − - rgb565 | |
| 28 | − - bgr666 | |
| 29 | − description: | | |
| 30 | − Describes the media format, how the display panel is connected | |
| 31 | − to the display interface. | |
| 32 | − | |
| 33 | 24 | backlight: true |
| 34 | 25 | enable-gpios: true |
| 35 | 26 | height-mm: true |
| @@ -52,7 +43,6 @@ examples: · 16 unmodified lines | ||
| 52 | 43 | compatible = "osddisplays,osd057T0559-34ts", "panel-dpi"; |
| 53 | 44 | label = "osddisplay"; |
| 54 | 45 | power-supply = <&vcc_supply>; |
| 55 | − data-mapping = "rgb565"; | |
| 56 | 46 | backlight = <&backlight>; |
| 57 | 47 | |
| 58 | 48 | port { |
| @@ -65,7 +65,7 @@ properties: · 64 unmodified lines | ||
| 65 | 65 | ports: |
| 66 | 66 | type: object |
| 67 | 67 | description: |
| 68 | − Ports as described in Documentation/devictree/bindings/graph.txt | |
| 68 | + Ports as described in Documentation/devicetree/bindings/graph.txt | |
| 69 | 69 | properties: |
| 70 | 70 | "#address-cells": |
| 71 | 71 | const: 1 |
| @@ -121,7 +121,7 @@ examples: · 49 unmodified lines | ||
| 121 | 121 | #include <dt-bindings/interrupt-controller/irq.h> |
| 122 | 122 | #include <dt-bindings/soc/ti,sci_pm_domain.h> |
| 123 | 123 | |
| 124 | − dss: dss@04a00000 { | |
| 124 | + dss: dss@4a00000 { | |
| 125 | 125 | compatible = "ti,am65x-dss"; |
| 126 | 126 | reg = <0x0 0x04a00000 0x0 0x1000>, /* common */ |
| 127 | 127 | <0x0 0x04a02000 0x0 0x1000>, /* vidl1 */ |
| @@ -98,7 +98,7 @@ properties: · 97 unmodified lines | ||
| 98 | 98 | ports: |
| 99 | 99 | type: object |
| 100 | 100 | description: |
| 101 | − Ports as described in Documentation/devictree/bindings/graph.txt | |
| 101 | + Ports as described in Documentation/devicetree/bindings/graph.txt | |
| 102 | 102 | properties: |
| 103 | 103 | "#address-cells": |
| 104 | 104 | const: 1 |
| @@ -154,7 +154,7 @@ examples: · 49 unmodified lines | ||
| 154 | 154 | #include <dt-bindings/interrupt-controller/irq.h> |
| 155 | 155 | #include <dt-bindings/soc/ti,sci_pm_domain.h> |
| 156 | 156 | |
| 157 | − dss: dss@04a00000 { | |
| 157 | + dss: dss@4a00000 { | |
| 158 | 158 | compatible = "ti,j721e-dss"; |
| 159 | 159 | reg = <0x00 0x04a00000 0x00 0x10000>, /* common_m */ |
| 160 | 160 | <0x00 0x04a10000 0x00 0x10000>, /* common_s0*/ |
| @@ -56,7 +56,7 @@ properties: · 55 unmodified lines | ||
| 56 | 56 | port: |
| 57 | 57 | type: object |
| 58 | 58 | description: |
| 59 | − Port as described in Documentation/devictree/bindings/graph.txt. | |
| 59 | + Port as described in Documentation/devicetree/bindings/graph.txt. | |
| 60 | 60 | The DSS DPI output port node |
| 61 | 61 | |
| 62 | 62 | max-memory-bandwidth: |
| @@ -81,7 +81,7 @@ examples: · 18 unmodified lines | ||
| 81 | 81 | #include <dt-bindings/interrupt-controller/arm-gic.h> |
| 82 | 82 | #include <dt-bindings/interrupt-controller/irq.h> |
| 83 | 83 | |
| 84 | − dss: dss@02540000 { | |
| 84 | + dss: dss@2540000 { | |
| 85 | 85 | compatible = "ti,k2g-dss"; |
| 86 | 86 | reg = <0x02540000 0x400>, |
| 87 | 87 | <0x02550000 0x1000>, |
| @@ -16,6 +16,7 @@ Required Properties: · 15 unmodified lines | ||
| 16 | 16 | - "renesas,r8a7794-usb-dmac" (R-Car E2) |
| 17 | 17 | - "renesas,r8a7795-usb-dmac" (R-Car H3) |
| 18 | 18 | - "renesas,r8a7796-usb-dmac" (R-Car M3-W) |
| 19 | + - "renesas,r8a77961-usb-dmac" (R-Car M3-W+) | |
| 19 | 20 | - "renesas,r8a77965-usb-dmac" (R-Car M3-N) |
| 20 | 21 | - "renesas,r8a77990-usb-dmac" (R-Car E3) |
| 21 | 22 | - "renesas,r8a77995-usb-dmac" (R-Car D3) |
| @@ -43,6 +43,8 @@ required: · 42 unmodified lines | ||
| 43 | 43 | - interrupts |
| 44 | 44 | - '#dma-cells' |
| 45 | 45 | |
| 46 | +additionalProperties: false | |
| 47 | + | |
| 46 | 48 | examples: |
| 47 | 49 | - | |
| 48 | 50 | dma@3000000 { |
| @@ -0,0 +1,63 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/dma/socionext,uniphier-mio-dmac.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: UniPhier Media IO DMA controller | |
| 8 | + | |
| 9 | +description: | | |
| 10 | + This works as an external DMA engine for SD/eMMC controllers etc. | |
| 11 | + found in UniPhier LD4, Pro4, sLD8 SoCs. | |
| 12 | + | |
| 13 | +maintainers: | |
| 14 | + - Masahiro Yamada <yamada.masahiro@socionext.com> | |
| 15 | + | |
| 16 | +allOf: | |
| 17 | + - $ref: "dma-controller.yaml#" | |
| 18 | + | |
| 19 | +properties: | |
| 20 | + compatible: | |
| 21 | + const: socionext,uniphier-mio-dmac | |
| 22 | + | |
| 23 | + reg: | |
| 24 | + maxItems: 1 | |
| 25 | + | |
| 26 | + interrupts: | |
| 27 | + description: | | |
| 28 | + A list of interrupt specifiers associated with the DMA channels. | |
| 29 | + The number of interrupt lines is SoC-dependent. | |
| 30 | + | |
| 31 | + clocks: | |
| 32 | + maxItems: 1 | |
| 33 | + | |
| 34 | + resets: | |
| 35 | + maxItems: 1 | |
| 36 | + | |
| 37 | + '#dma-cells': | |
| 38 | + description: The single cell represents the channel index. | |
| 39 | + const: 1 | |
| 40 | + | |
| 41 | +required: | |
| 42 | + - compatible | |
| 43 | + - reg | |
| 44 | + - interrupts | |
| 45 | + - clocks | |
| 46 | + - '#dma-cells' | |
| 47 | + | |
| 48 | +additionalProperties: false | |
| 49 | + | |
| 50 | +examples: | |
| 51 | + - | | |
| 52 | + // In the example below, "interrupts = <0 68 4>, <0 68 4>, ..." is not a | |
| 53 | + // typo. The first two channels share a single interrupt line. | |
| 54 | + | |
| 55 | + dmac: dma-controller@5a000000 { | |
| 56 | + compatible = "socionext,uniphier-mio-dmac"; | |
| 57 | + reg = <0x5a000000 0x1000>; | |
| 58 | + interrupts = <0 68 4>, <0 68 4>, <0 69 4>, <0 70 4>, | |
| 59 | + <0 71 4>, <0 72 4>, <0 73 4>, <0 74 4>; | |
| 60 | + clocks = <&mio_clk 7>; | |
| 61 | + resets = <&mio_rst 7>; | |
| 62 | + #dma-cells = <1>; | |
| 63 | + }; | |
| @@ -0,0 +1,63 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/dma/socionext,uniphier-xdmac.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Socionext UniPhier external DMA controller | |
| 8 | + | |
| 9 | +description: | | |
| 10 | + This describes the devicetree bindings for an external DMA engine to perform | |
| 11 | + memory-to-memory or peripheral-to-memory data transfer capable of supporting | |
| 12 | + 16 channels, implemented in Socionext UniPhier SoCs. | |
| 13 | + | |
| 14 | +maintainers: | |
| 15 | + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> | |
| 16 | + | |
| 17 | +allOf: | |
| 18 | + - $ref: "dma-controller.yaml#" | |
| 19 | + | |
| 20 | +properties: | |
| 21 | + compatible: | |
| 22 | + const: socionext,uniphier-xdmac | |
| 23 | + | |
| 24 | + reg: | |
| 25 | + items: | |
| 26 | + - description: XDMAC base register region (offset and length) | |
| 27 | + - description: XDMAC extension register region (offset and length) | |
| 28 | + | |
| 29 | + interrupts: | |
| 30 | + maxItems: 1 | |
| 31 | + | |
| 32 | + "#dma-cells": | |
| 33 | + const: 2 | |
| 34 | + description: | | |
| 35 | + DMA request from clients consists of 2 cells: | |
| 36 | + 1. Channel index | |
| 37 | + 2. Transfer request factor number, If no transfer factor, use 0. | |
| 38 | + The number is SoC-specific, and this should be specified with | |
| 39 | + relation to the device to use the DMA controller. | |
| 40 | + | |
| 41 | + dma-channels: | |
| 42 | + minimum: 1 | |
| 43 | + maximum: 16 | |
| 44 | + | |
| 45 | +additionalProperties: false | |
| 46 | + | |
| 47 | +required: | |
| 48 | + - compatible | |
| 49 | + - reg | |
| 50 | + - interrupts | |
| 51 | + - "#dma-cells" | |
| 52 | + | |
| 53 | +examples: | |
| 54 | + - | | |
| 55 | + xdmac: dma-controller@5fc10000 { | |
| 56 | + compatible = "socionext,uniphier-xdmac"; | |
| 57 | + reg = <0x5fc10000 0x1000>, <0x5fc20000 0x800>; | |
| 58 | + interrupts = <0 188 4>; | |
| 59 | + #dma-cells = <2>; | |
| 60 | + dma-channels = <16>; | |
| 61 | + }; | |
| 62 | + | |
| 63 | +... | |
| @@ -180,7 +180,7 @@ edma1_tptc0: tptc@27b0000 { · 179 unmodified lines | ||
| 180 | 180 | }; |
| 181 | 181 | |
| 182 | 182 | edma1_tptc1: tptc@27b8000 { |
| 183 | − compatible = "ti, k2g-edma3-tptc", "ti,edma3-tptc"; | |
| 183 | + compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc"; | |
| 184 | 184 | reg = <0x027b8000 0x400>; |
| 185 | 185 | power-domains = <&k2g_pds 0x4f>; |
| 186 | 186 | }; |
| @@ -45,7 +45,8 @@ allOf: · 44 unmodified lines | ||
| 45 | 45 | |
| 46 | 46 | properties: |
| 47 | 47 | "#dma-cells": |
| 48 | − const: 1 | |
| 48 | + minimum: 1 | |
| 49 | + maximum: 2 | |
| 49 | 50 | description: | |
| 50 | 51 | The cell is the PSI-L thread ID of the remote (to UDMAP) end. |
| 51 | 52 | Valid ranges for thread ID depends on the data movement direction: |
| @@ -55,6 +56,8 @@ properties: · 3 unmodified lines | ||
| 55 | 56 | Please refer to the device documentation for the PSI-L thread map and also |
| 56 | 57 | the PSI-L peripheral chapter for the correct thread ID. |
| 57 | 58 | |
| 59 | + When #dma-cells is 2, the second parameter is the channel ATYPE. | |
| 60 | + | |
| 58 | 61 | compatible: |
| 59 | 62 | enum: |
| 60 | 63 | - ti,am654-navss-main-udmap |
| @@ -131,6 +134,20 @@ required: · 70 unmodified lines | ||
| 131 | 134 | - ti,sci-rm-range-rchan |
| 132 | 135 | - ti,sci-rm-range-rflow |
| 133 | 136 | |
| 137 | +if: | |
| 138 | + properties: | |
| 139 | + "#dma-cells": | |
| 140 | + const: 2 | |
| 141 | +then: | |
| 142 | + properties: | |
| 143 | + ti,udma-atype: | |
| 144 | + description: ATYPE value which should be used by non slave channels | |
| 145 | + allOf: | |
| 146 | + - $ref: /schemas/types.yaml#/definitions/uint32 | |
| 147 | + | |
| 148 | + required: | |
| 149 | + - ti,udma-atype | |
| 150 | + | |
| 134 | 151 | examples: |
| 135 | 152 | - |+ |
| 136 | 153 | cbass_main { |
| @@ -1,25 +0,0 @@ | ||
| 1 | −UniPhier Media IO DMA controller | |
| 2 | − | |
| 3 | −This works as an external DMA engine for SD/eMMC controllers etc. | |
| 4 | −found in UniPhier LD4, Pro4, sLD8 SoCs. | |
| 5 | − | |
| 6 | −Required properties: | |
| 7 | −- compatible: should be "socionext,uniphier-mio-dmac". | |
| 8 | −- reg: offset and length of the register set for the device. | |
| 9 | −- interrupts: a list of interrupt specifiers associated with the DMA channels. | |
| 10 | −- clocks: a single clock specifier. | |
| 11 | −- #dma-cells: should be <1>. The single cell represents the channel index. | |
| 12 | − | |
| 13 | −Example: | |
| 14 | − dmac: dma-controller@5a000000 { | |
| 15 | − compatible = "socionext,uniphier-mio-dmac"; | |
| 16 | − reg = <0x5a000000 0x1000>; | |
| 17 | − interrupts = <0 68 4>, <0 68 4>, <0 69 4>, <0 70 4>, | |
| 18 | − <0 71 4>, <0 72 4>, <0 73 4>, <0 74 4>; | |
| 19 | − clocks = <&mio_clk 7>; | |
| 20 | − #dma-cells = <1>; | |
| 21 | − }; | |
| 22 | − | |
| 23 | −Note: | |
| 24 | −In the example above, "interrupts = <0 68 4>, <0 68 4>, ..." is not a typo. | |
| 25 | −The first two channels share a single interrupt line. | |
| @@ -68,6 +68,8 @@ required: · 67 unmodified lines | ||
| 68 | 68 | - mbox-names |
| 69 | 69 | - memory-region |
| 70 | 70 | |
| 71 | +additionalProperties: false | |
| 72 | + | |
| 71 | 73 | examples: |
| 72 | 74 | - | |
| 73 | 75 | #include <dt-bindings/firmware/imx/rsrc.h> |
| @@ -0,0 +1,59 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/edac/dmc-520.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: ARM DMC-520 EDAC bindings | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Lei Wang <lewan@microsoft.com> | |
| 11 | + | |
| 12 | +description: |+ | |
| 13 | + DMC-520 node is defined to describe DRAM error detection and correction. | |
| 14 | + | |
| 15 | + https://static.docs.arm.com/100000/0200/corelink_dmc520_trm_100000_0200_01_en.pdf | |
| 16 | + | |
| 17 | +properties: | |
| 18 | + compatible: | |
| 19 | + items: | |
| 20 | + - const: brcm,dmc-520 | |
| 21 | + - const: arm,dmc-520 | |
| 22 | + | |
| 23 | + reg: | |
| 24 | + maxItems: 1 | |
| 25 | + | |
| 26 | + interrupts: | |
| 27 | + minItems: 1 | |
| 28 | + maxItems: 10 | |
| 29 | + | |
| 30 | + interrupt-names: | |
| 31 | + minItems: 1 | |
| 32 | + maxItems: 10 | |
| 33 | + items: | |
| 34 | + enum: | |
| 35 | + - ram_ecc_errc | |
| 36 | + - ram_ecc_errd | |
| 37 | + - dram_ecc_errc | |
| 38 | + - dram_ecc_errd | |
| 39 | + - failed_access | |
| 40 | + - failed_prog | |
| 41 | + - link_err | |
| 42 | + - temperature_event | |
| 43 | + - arch_fsm | |
| 44 | + - phy_request | |
| 45 | + | |
| 46 | +required: | |
| 47 | + - compatible | |
| 48 | + - reg | |
| 49 | + - interrupts | |
| 50 | + - interrupt-names | |
| 51 | + | |
| 52 | +examples: | |
| 53 | + - | | |
| 54 | + dmc0: dmc@200000 { | |
| 55 | + compatible = "brcm,dmc-520", "arm,dmc-520"; | |
| 56 | + reg = <0x200000 0x80000>; | |
| 57 | + interrupts = <0x0 0x349 0x4>, <0x0 0x34B 0x4>; | |
| 58 | + interrupt-names = "dram_ecc_errc", "dram_ecc_errd"; | |
| 59 | + }; | |
| @@ -172,6 +172,8 @@ required: · 171 unmodified lines | ||
| 172 | 172 | - compatible |
| 173 | 173 | - reg |
| 174 | 174 | |
| 175 | +additionalProperties: false | |
| 176 | + | |
| 175 | 177 | examples: |
| 176 | 178 | - | |
| 177 | 179 | i2c { |
| @@ -7,9 +7,9 @@ · 6 unmodified lines | ||
| 7 | 7 | |
| 8 | 8 | # $id is a unique identifier based on the filename. There may or may not be a |
| 9 | 9 | # file present at the URL. |
| 10 | −$id: "http://devicetree.org/schemas/example-schema.yaml#" | |
| 10 | +$id: http://devicetree.org/schemas/example-schema.yaml# | |
| 11 | 11 | # $schema is the meta-schema this schema should be validated with. |
| 12 | −$schema: "http://devicetree.org/meta-schemas/core.yaml#" | |
| 12 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 13 | 13 | |
| 14 | 14 | title: An example schema annotated with jsonschema details |
| 15 | 15 | |
| @@ -1,24 +0,0 @@ | ||
| 1 | −ChromeOS EC USB Type-C cable and accessories detection | |
| 2 | − | |
| 3 | −On ChromeOS systems with USB Type C ports, the ChromeOS Embedded Controller is | |
| 4 | −able to detect the state of external accessories such as display adapters | |
| 5 | −or USB devices when said accessories are attached or detached. | |
| 6 | − | |
| 7 | −The node for this device must be under a cros-ec node like google,cros-ec-spi | |
| 8 | −or google,cros-ec-i2c. | |
| 9 | − | |
| 10 | −Required properties: | |
| 11 | −- compatible: Should be "google,extcon-usbc-cros-ec". | |
| 12 | −- google,usb-port-id: Specifies the USB port ID to use. | |
| 13 | − | |
| 14 | −Example: | |
| 15 | − cros-ec@0 { | |
| 16 | − compatible = "google,cros-ec-i2c"; | |
| 17 | − | |
| 18 | − ... | |
| 19 | − | |
| 20 | − extcon { | |
| 21 | − compatible = "google,extcon-usbc-cros-ec"; | |
| 22 | − google,usb-port-id = <0>; | |
| 23 | − }; | |
| 24 | − } | |
| @@ -0,0 +1,56 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/extcon/extcon-usbc-cros-ec.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: ChromeOS EC USB Type-C cable and accessories detection | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Benson Leung <bleung@chromium.org> | |
| 11 | + - Enric Balletbo i Serra <enric.balletbo@collabora.com> | |
| 12 | + | |
| 13 | +description: | | |
| 14 | + On ChromeOS systems with USB Type C ports, the ChromeOS Embedded Controller is | |
| 15 | + able to detect the state of external accessories such as display adapters | |
| 16 | + or USB devices when said accessories are attached or detached. | |
| 17 | + The node for this device must be under a cros-ec node like google,cros-ec-spi | |
| 18 | + or google,cros-ec-i2c. | |
| 19 | + | |
| 20 | +properties: | |
| 21 | + compatible: | |
| 22 | + const: google,extcon-usbc-cros-ec | |
| 23 | + | |
| 24 | + google,usb-port-id: | |
| 25 | + allOf: | |
| 26 | + - $ref: /schemas/types.yaml#/definitions/uint32 | |
| 27 | + description: the port id | |
| 28 | + minimum: 0 | |
| 29 | + maximum: 255 | |
| 30 | + | |
| 31 | +required: | |
| 32 | + - compatible | |
| 33 | + - google,usb-port-id | |
| 34 | + | |
| 35 | +additionalProperties: false | |
| 36 | + | |
| 37 | +examples: | |
| 38 | + - | | |
| 39 | + spi0 { | |
| 40 | + #address-cells = <1>; | |
| 41 | + #size-cells = <0>; | |
| 42 | + cros-ec@0 { | |
| 43 | + compatible = "google,cros-ec-spi"; | |
| 44 | + reg = <0>; | |
| 45 | + | |
| 46 | + usbc_extcon0: extcon0 { | |
| 47 | + compatible = "google,extcon-usbc-cros-ec"; | |
| 48 | + google,usb-port-id = <0>; | |
| 49 | + }; | |
| 50 | + | |
| 51 | + usbc_extcon1: extcon1 { | |
| 52 | + compatible = "google,extcon-usbc-cros-ec"; | |
| 53 | + google,usb-port-id = <1>; | |
| 54 | + }; | |
| 55 | + }; | |
| 56 | + }; | |
| @@ -34,9 +34,12 @@ required: · 33 unmodified lines | ||
| 34 | 34 | - compatible |
| 35 | 35 | - reg |
| 36 | 36 | |
| 37 | +additionalProperties: false | |
| 38 | + | |
| 37 | 39 | examples: |
| 38 | 40 | - | |
| 39 | 41 | npe@c8006000 { |
| 40 | 42 | compatible = "intel,ixp4xx-network-processing-engine"; |
| 41 | 43 | reg = <0xc8006000 0x1000>, <0xc8007000 0x1000>, <0xc8008000 0x1000>; |
| 42 | 44 | }; |
| 45 | +... | |
| @@ -10,6 +10,7 @@ Required properties: · 9 unmodified lines | ||
| 10 | 10 | * "qcom,scm-apq8064" |
| 11 | 11 | * "qcom,scm-apq8084" |
| 12 | 12 | * "qcom,scm-ipq4019" |
| 13 | + * "qcom,scm-ipq806x" | |
| 13 | 14 | * "qcom,scm-msm8660" |
| 14 | 15 | * "qcom,scm-msm8916" |
| 15 | 16 | * "qcom,scm-msm8960" |
| @@ -263,7 +263,7 @@ Overlay contains: · 262 unmodified lines | ||
| 263 | 263 | gpio@10040 { |
| 264 | 264 | compatible = "altr,pio-1.0"; |
| 265 | 265 | reg = <0x10040 0x20>; |
| 266 | − altr,gpio-bank-width = <4>; | |
| 266 | + altr,ngpio = <4>; | |
| 267 | 267 | #gpio-cells = <2>; |
| 268 | 268 | clocks = <2>; |
| 269 | 269 | gpio-controller; |
| @@ -468,8 +468,7 @@ programming is the FPGA based bridge of fpga_region1. · 198 unmodified lines | ||
| 468 | 468 | compatible = "altr,pio-1.0"; |
| 469 | 469 | reg = <0x10040 0x20>; |
| 470 | 470 | clocks = <0x2>; |
| 471 | − altr,gpio-bank-width = <0x4>; | |
| 472 | − resetvalue = <0x0>; | |
| 471 | + altr,ngpio = <0x4>; | |
| 473 | 472 | #gpio-cells = <0x2>; |
| 474 | 473 | gpio-controller; |
| 475 | 474 | }; |
| @@ -0,0 +1,36 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-or-later) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/fsi/ibm,fsi2spi.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: IBM FSI-attached SPI controllers | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Eddie James <eajames@linux.ibm.com> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + This binding describes an FSI CFAM engine called the FSI2SPI. Therefore this | |
| 14 | + node will always be a child of an FSI CFAM node; see fsi.txt for details on | |
| 15 | + FSI slave and CFAM nodes. This FSI2SPI engine provides access to a number of | |
| 16 | + SPI controllers. | |
| 17 | + | |
| 18 | +properties: | |
| 19 | + compatible: | |
| 20 | + enum: | |
| 21 | + - ibm,fsi2spi | |
| 22 | + | |
| 23 | + reg: | |
| 24 | + items: | |
| 25 | + - description: FSI slave address | |
| 26 | + | |
| 27 | +required: | |
| 28 | + - compatible | |
| 29 | + - reg | |
| 30 | + | |
| 31 | +examples: | |
| 32 | + - | | |
| 33 | + fsi2spi@1c00 { | |
| 34 | + compatible = "ibm,fsi2spi"; | |
| 35 | + reg = <0x1c00 0x400>; | |
| 36 | + }; | |
| @@ -8,7 +8,7 @@ bus (e.g. UART, I2C or SPI). · 7 unmodified lines | ||
| 8 | 8 | |
| 9 | 9 | Please refer to the following documents for generic properties: |
| 10 | 10 | |
| 11 | − Documentation/devicetree/bindings/serial/slave-device.txt | |
| 11 | + Documentation/devicetree/bindings/serial/serial.yaml | |
| 12 | 12 | Documentation/devicetree/bindings/spi/spi-bus.txt |
| 13 | 13 | |
| 14 | 14 | Required properties: |
| @@ -47,6 +47,8 @@ required: · 46 unmodified lines | ||
| 47 | 47 | - "#gpio-cells" |
| 48 | 48 | - gpio-controller |
| 49 | 49 | |
| 50 | +additionalProperties: false | |
| 51 | + | |
| 50 | 52 | dependencies: |
| 51 | 53 | interrupt-controller: [ interrupts ] |
| 52 | 54 | |
| @@ -14,7 +14,7 @@ Required properties: · 13 unmodified lines | ||
| 14 | 14 | |
| 15 | 15 | "marvell,armada-8k-gpio" should be used for the Armada 7K and 8K |
| 16 | 16 | SoCs (either from AP or CP), see |
| 17 | − Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt | |
| 17 | + Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt | |
| 18 | 18 | for specific details about the offset property. |
| 19 | 19 | |
| 20 | 20 | - reg: Address and length of the register set for the device. Only one |
| @@ -1,51 +0,0 @@ | ||
| 1 | −UniPhier GPIO controller | |
| 2 | − | |
| 3 | −Required properties: | |
| 4 | −- compatible: Should be "socionext,uniphier-gpio". | |
| 5 | −- reg: Specifies offset and length of the register set for the device. | |
| 6 | −- gpio-controller: Marks the device node as a GPIO controller. | |
| 7 | −- #gpio-cells: Should be 2. The first cell is the pin number and the second | |
| 8 | − cell is used to specify optional parameters. | |
| 9 | −- interrupt-controller: Marks the device node as an interrupt controller. | |
| 10 | −- #interrupt-cells: Should be 2. The first cell defines the interrupt number. | |
| 11 | − The second cell bits[3:0] is used to specify trigger type as follows: | |
| 12 | − 1 = low-to-high edge triggered | |
| 13 | − 2 = high-to-low edge triggered | |
| 14 | − 4 = active high level-sensitive | |
| 15 | − 8 = active low level-sensitive | |
| 16 | − Valid combinations are 1, 2, 3, 4, 8. | |
| 17 | −- ngpios: Specifies the number of GPIO lines. | |
| 18 | −- gpio-ranges: Mapping to pin controller pins (as described in gpio.txt) | |
| 19 | −- socionext,interrupt-ranges: Specifies an interrupt number mapping between | |
| 20 | − this GPIO controller and its interrupt parent, in the form of arbitrary | |
| 21 | − number of <child-interrupt-base parent-interrupt-base length> triplets. | |
| 22 | − | |
| 23 | −Optional properties: | |
| 24 | −- gpio-ranges-group-names: Used for named gpio ranges (as described in gpio.txt) | |
| 25 | − | |
| 26 | −Example: | |
| 27 | − gpio: gpio@55000000 { | |
| 28 | − compatible = "socionext,uniphier-gpio"; | |
| 29 | − reg = <0x55000000 0x200>; | |
| 30 | − interrupt-parent = <&aidet>; | |
| 31 | − interrupt-controller; | |
| 32 | − #interrupt-cells = <2>; | |
| 33 | − gpio-controller; | |
| 34 | − #gpio-cells = <2>; | |
| 35 | − gpio-ranges = <&pinctrl 0 0 0>; | |
| 36 | − gpio-ranges-group-names = "gpio_range"; | |
| 37 | − ngpios = <248>; | |
| 38 | − socionext,interrupt-ranges = <0 48 16>, <16 154 5>, <21 217 3>; | |
| 39 | − }; | |
| 40 | − | |
| 41 | −Consumer Example: | |
| 42 | − | |
| 43 | − sdhci0_pwrseq { | |
| 44 | − compatible = "mmc-pwrseq-emmc"; | |
| 45 | − reset-gpios = <&gpio UNIPHIER_GPIO_PORT(29, 4) GPIO_ACTIVE_LOW>; | |
| 46 | − }; | |
| 47 | − | |
| 48 | −Please note UNIPHIER_GPIO_PORT(29, 4) represents PORT294 in the SoC document. | |
| 49 | −Unfortunately, only the one's place is octal in the port numbering. (That is, | |
| 50 | −PORT 8, 9, 18, 19, 28, 29, ... are missing.) UNIPHIER_GPIO_PORT() is a helper | |
| 51 | −macro to calculate 29 * 8 + 4. | |
| @@ -0,0 +1,94 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/gpio/socionext,uniphier-gpio.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: UniPhier GPIO controller | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Masahiro Yamada <yamada.masahiro@socionext.com> | |
| 11 | + | |
| 12 | +properties: | |
| 13 | + $nodename: | |
| 14 | + pattern: "^gpio@[0-9a-f]+$" | |
| 15 | + | |
| 16 | + compatible: | |
| 17 | + const: socionext,uniphier-gpio | |
| 18 | + | |
| 19 | + reg: | |
| 20 | + maxItems: 1 | |
| 21 | + | |
| 22 | + gpio-controller: true | |
| 23 | + | |
| 24 | + "#gpio-cells": | |
| 25 | + const: 2 | |
| 26 | + | |
| 27 | + interrupt-controller: true | |
| 28 | + | |
| 29 | + "#interrupt-cells": | |
| 30 | + description: | | |
| 31 | + The first cell defines the interrupt number. | |
| 32 | + The second cell bits[3:0] is used to specify trigger type as follows: | |
| 33 | + 1 = low-to-high edge triggered | |
| 34 | + 2 = high-to-low edge triggered | |
| 35 | + 4 = active high level-sensitive | |
| 36 | + 8 = active low level-sensitive | |
| 37 | + Valid combinations are 1, 2, 3, 4, 8. | |
| 38 | + const: 2 | |
| 39 | + | |
| 40 | + ngpios: | |
| 41 | + minimum: 0 | |
| 42 | + maximum: 512 | |
| 43 | + | |
| 44 | + gpio-ranges: true | |
| 45 | + | |
| 46 | + gpio-ranges-group-names: | |
| 47 | + $ref: /schemas/types.yaml#/definitions/string-array | |
| 48 | + | |
| 49 | + socionext,interrupt-ranges: | |
| 50 | + description: | | |
| 51 | + Specifies an interrupt number mapping between this GPIO controller and | |
| 52 | + its interrupt parent, in the form of arbitrary number of | |
| 53 | + <child-interrupt-base parent-interrupt-base length> triplets. | |
| 54 | + $ref: /schemas/types.yaml#/definitions/uint32-matrix | |
| 55 | + | |
| 56 | +required: | |
| 57 | + - compatible | |
| 58 | + - reg | |
| 59 | + - gpio-controller | |
| 60 | + - "#gpio-cells" | |
| 61 | + - interrupt-controller | |
| 62 | + - "#interrupt-cells" | |
| 63 | + - ngpios | |
| 64 | + - gpio-ranges | |
| 65 | + - socionext,interrupt-ranges | |
| 66 | + | |
| 67 | +examples: | |
| 68 | + - | | |
| 69 | + #include <dt-bindings/gpio/gpio.h> | |
| 70 | + #include <dt-bindings/gpio/uniphier-gpio.h> | |
| 71 | + | |
| 72 | + gpio: gpio@55000000 { | |
| 73 | + compatible = "socionext,uniphier-gpio"; | |
| 74 | + reg = <0x55000000 0x200>; | |
| 75 | + interrupt-parent = <&aidet>; | |
| 76 | + interrupt-controller; | |
| 77 | + #interrupt-cells = <2>; | |
| 78 | + gpio-controller; | |
| 79 | + #gpio-cells = <2>; | |
| 80 | + gpio-ranges = <&pinctrl 0 0 0>; | |
| 81 | + gpio-ranges-group-names = "gpio_range"; | |
| 82 | + ngpios = <248>; | |
| 83 | + socionext,interrupt-ranges = <0 48 16>, <16 154 5>, <21 217 3>; | |
| 84 | + }; | |
| 85 | + | |
| 86 | + // Consumer: | |
| 87 | + // Please note UNIPHIER_GPIO_PORT(29, 4) represents PORT294 in the SoC | |
| 88 | + // document. Unfortunately, only the one's place is octal in the port | |
| 89 | + // numbering. (That is, PORT 8, 9, 18, 19, 28, 29, ... do not exist.) | |
| 90 | + // UNIPHIER_GPIO_PORT() is a helper macro to calculate 29 * 8 + 4. | |
| 91 | + sdhci0_pwrseq { | |
| 92 | + compatible = "mmc-pwrseq-emmc"; | |
| 93 | + reset-gpios = <&gpio UNIPHIER_GPIO_PORT(29, 4) GPIO_ACTIVE_LOW>; | |
| 94 | + }; | |
| @@ -49,6 +49,8 @@ required: · 48 unmodified lines | ||
| 49 | 49 | - "#gpio-cells" |
| 50 | 50 | - gpio-controller |
| 51 | 51 | |
| 52 | +additionalProperties: false | |
| 53 | + | |
| 52 | 54 | examples: |
| 53 | 55 | - | |
| 54 | 56 | logicvc: logicvc@43c00000 { |
| @@ -43,6 +43,9 @@ properties: · 42 unmodified lines | ||
| 43 | 43 | |
| 44 | 44 | operating-points-v2: true |
| 45 | 45 | |
| 46 | + resets: | |
| 47 | + maxItems: 2 | |
| 48 | + | |
| 46 | 49 | required: |
| 47 | 50 | - compatible |
| 48 | 51 | - reg |
| @@ -50,6 +53,8 @@ required: · 1 unmodified line | ||
| 50 | 53 | - interrupt-names |
| 51 | 54 | - clocks |
| 52 | 55 | |
| 56 | +additionalProperties: false | |
| 57 | + | |
| 53 | 58 | allOf: |
| 54 | 59 | - if: |
| 55 | 60 | properties: |
| @@ -57,9 +62,6 @@ allOf: · 1 unmodified line | ||
| 57 | 62 | contains: |
| 58 | 63 | const: amlogic,meson-g12a-mali |
| 59 | 64 | then: |
| 60 | − properties: | |
| 61 | − resets: | |
| 62 | − minItems: 2 | |
| 63 | 65 | required: |
| 64 | 66 | - resets |
| 65 | 67 | |
| @@ -75,6 +75,9 @@ properties: · 74 unmodified lines | ||
| 75 | 75 | |
| 76 | 76 | mali-supply: true |
| 77 | 77 | |
| 78 | + power-domains: | |
| 79 | + maxItems: 1 | |
| 80 | + | |
| 78 | 81 | resets: |
| 79 | 82 | minItems: 1 |
| 80 | 83 | maxItems: 2 |
| @@ -91,6 +94,8 @@ required: · 10 unmodified lines | ||
| 91 | 94 | - interrupt-names |
| 92 | 95 | - clocks |
| 93 | 96 | |
| 97 | +additionalProperties: false | |
| 98 | + | |
| 94 | 99 | allOf: |
| 95 | 100 | - if: |
| 96 | 101 | properties: |
| @@ -115,6 +115,8 @@ required: · 114 unmodified lines | ||
| 115 | 115 | - clocks |
| 116 | 116 | - clock-names |
| 117 | 117 | |
| 118 | +additionalProperties: false | |
| 119 | + | |
| 118 | 120 | allOf: |
| 119 | 121 | - if: |
| 120 | 122 | properties: |
| @@ -36,6 +36,8 @@ required: · 35 unmodified lines | ||
| 36 | 36 | - clocks |
| 37 | 37 | - clock-names |
| 38 | 38 | |
| 39 | +additionalProperties: false | |
| 40 | + | |
| 39 | 41 | examples: |
| 40 | 42 | - | |
| 41 | 43 | rotator@12810000 { |
| @@ -0,0 +1,69 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/gpu/vivante,gc.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Vivante GPU Bindings | |
| 8 | + | |
| 9 | +description: Vivante GPU core devices | |
| 10 | + | |
| 11 | +maintainers: | |
| 12 | + - Lucas Stach <l.stach@pengutronix.de> | |
| 13 | + | |
| 14 | +properties: | |
| 15 | + compatible: | |
| 16 | + const: vivante,gc | |
| 17 | + | |
| 18 | + reg: | |
| 19 | + maxItems: 1 | |
| 20 | + | |
| 21 | + interrupts: | |
| 22 | + maxItems: 1 | |
| 23 | + | |
| 24 | + clocks: | |
| 25 | + items: | |
| 26 | + - description: AXI/master interface clock | |
| 27 | + - description: GPU core clock | |
| 28 | + - description: Shader clock (only required if GPU has feature PIPE_3D) | |
| 29 | + - description: AHB/slave interface clock (only required if GPU can gate slave interface independently) | |
| 30 | + minItems: 1 | |
| 31 | + maxItems: 4 | |
| 32 | + | |
| 33 | + clock-names: | |
| 34 | + items: | |
| 35 | + enum: [ bus, core, shader, reg ] | |
| 36 | + minItems: 1 | |
| 37 | + maxItems: 4 | |
| 38 | + | |
| 39 | + resets: | |
| 40 | + maxItems: 1 | |
| 41 | + | |
| 42 | + power-domains: | |
| 43 | + maxItems: 1 | |
| 44 | + | |
| 45 | +required: | |
| 46 | + - compatible | |
| 47 | + - reg | |
| 48 | + - interrupts | |
| 49 | + - clocks | |
| 50 | + - clock-names | |
| 51 | + | |
| 52 | +additionalProperties: false | |
| 53 | + | |
| 54 | +examples: | |
| 55 | + - | | |
| 56 | + #include <dt-bindings/clock/imx6qdl-clock.h> | |
| 57 | + #include <dt-bindings/interrupt-controller/arm-gic.h> | |
| 58 | + gpu@130000 { | |
| 59 | + compatible = "vivante,gc"; | |
| 60 | + reg = <0x00130000 0x4000>; | |
| 61 | + interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>; | |
| 62 | + clocks = <&clks IMX6QDL_CLK_GPU3D_AXI>, | |
| 63 | + <&clks IMX6QDL_CLK_GPU3D_CORE>, | |
| 64 | + <&clks IMX6QDL_CLK_GPU3D_SHADER>; | |
| 65 | + clock-names = "bus", "core", "shader"; | |
| 66 | + power-domains = <&gpc 1>; | |
| 67 | + }; | |
| 68 | + | |
| 69 | +... | |
| @@ -47,6 +47,8 @@ required: · 46 unmodified lines | ||
| 47 | 47 | - compatible |
| 48 | 48 | - reg |
| 49 | 49 | |
| 50 | +additionalProperties: false | |
| 51 | + | |
| 50 | 52 | examples: |
| 51 | 53 | - | |
| 52 | 54 | #include <dt-bindings/gpio/gpio.h> |
| @@ -0,0 +1,62 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +# Copyright 2019 Analog Devices Inc. | |
| 3 | +%YAML 1.2 | |
| 4 | +--- | |
| 5 | +$id: http://devicetree.org/schemas/bindings/hwmon/adi,axi-fan-control.yaml# | |
| 6 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 7 | + | |
| 8 | +title: Analog Devices AXI FAN Control Device Tree Bindings | |
| 9 | + | |
| 10 | +maintainers: | |
| 11 | + - Nuno Sá <nuno.sa@analog.com> | |
| 12 | + | |
| 13 | +description: |+ | |
| 14 | + Bindings for the Analog Devices AXI FAN Control driver. Spefications of the | |
| 15 | + core can be found in: | |
| 16 | + | |
| 17 | + https://wiki.analog.com/resources/fpga/docs/axi_fan_control | |
| 18 | + | |
| 19 | +properties: | |
| 20 | + compatible: | |
| 21 | + enum: | |
| 22 | + - adi,axi-fan-control-1.00.a | |
| 23 | + | |
| 24 | + reg: | |
| 25 | + maxItems: 1 | |
| 26 | + | |
| 27 | + clocks: | |
| 28 | + maxItems: 1 | |
| 29 | + | |
| 30 | + interrupts: | |
| 31 | + maxItems: 1 | |
| 32 | + | |
| 33 | + pulses-per-revolution: | |
| 34 | + description: | |
| 35 | + Value specifying the number of pulses per revolution of the controlled | |
| 36 | + FAN. | |
| 37 | + allOf: | |
| 38 | + - $ref: /schemas/types.yaml#/definitions/uint32 | |
| 39 | + enum: [1, 2, 4] | |
| 40 | + | |
| 41 | +required: | |
| 42 | + - compatible | |
| 43 | + - reg | |
| 44 | + - clocks | |
| 45 | + - interrupts | |
| 46 | + - pulses-per-revolution | |
| 47 | + | |
| 48 | +examples: | |
| 49 | + - | | |
| 50 | + fpga_axi: fpga-axi@0 { | |
| 51 | + #address-cells = <0x2>; | |
| 52 | + #size-cells = <0x1>; | |
| 53 | + | |
| 54 | + axi_fan_control: axi-fan-control@80000000 { | |
| 55 | + compatible = "adi,axi-fan-control-1.00.a"; | |
| 56 | + reg = <0x0 0x80000000 0x10000>; | |
| 57 | + clocks = <&clk 71>; | |
| 58 | + interrupts = <0 110 0>; | |
| 59 | + pulses-per-revolution = <2>; | |
| 60 | + }; | |
| 61 | + }; | |
| 62 | +... | |
| @@ -87,6 +87,8 @@ required: · 86 unmodified lines | ||
| 87 | 87 | - reg |
| 88 | 88 | |
| 89 | 89 | |
| 90 | +additionalProperties: false | |
| 91 | + | |
| 90 | 92 | examples: |
| 91 | 93 | - | |
| 92 | 94 | spi { |
| @@ -0,0 +1,84 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/adt7475.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: ADT7475 hwmon sensor | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Jean Delvare <jdelvare@suse.com> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + The ADT7473, ADT7475, ADT7476, and ADT7490 are thermal monitors and multiple | |
| 14 | + PWN fan controllers. | |
| 15 | + | |
| 16 | + They support monitoring and controlling up to four fans (the ADT7490 can only | |
| 17 | + control up to three). They support reading a single on chip temperature | |
| 18 | + sensor and two off chip temperature sensors (the ADT7490 additionally | |
| 19 | + supports measuring up to three current external temperature sensors with | |
| 20 | + series resistance cancellation (SRC)). | |
| 21 | + | |
| 22 | + Datasheets: | |
| 23 | + https://www.onsemi.com/pub/Collateral/ADT7473-D.PDF | |
| 24 | + https://www.onsemi.com/pub/Collateral/ADT7475-D.PDF | |
| 25 | + https://www.onsemi.com/pub/Collateral/ADT7476-D.PDF | |
| 26 | + https://www.onsemi.com/pub/Collateral/ADT7490-D.PDF | |
| 27 | + | |
| 28 | + Description taken from onsemiconductors specification sheets, with minor | |
| 29 | + rephrasing. | |
| 30 | + | |
| 31 | +properties: | |
| 32 | + compatible: | |
| 33 | + enum: | |
| 34 | + - adi,adt7473 | |
| 35 | + - adi,adt7475 | |
| 36 | + - adi,adt7476 | |
| 37 | + - adi,adt7490 | |
| 38 | + | |
| 39 | + reg: | |
| 40 | + maxItems: 1 | |
| 41 | + | |
| 42 | +patternProperties: | |
| 43 | + "^adi,bypass-attenuator-in[0-4]$": | |
| 44 | + description: | | |
| 45 | + Configures bypassing the individual voltage input attenuator. If | |
| 46 | + set to 1 the attenuator is bypassed if set to 0 the attenuator is | |
| 47 | + not bypassed. If the property is absent then the attenuator | |
| 48 | + retains it's configuration from the bios/bootloader. | |
| 49 | + allOf: | |
| 50 | + - $ref: /schemas/types.yaml#/definitions/uint32 | |
| 51 | + - enum: [0, 1] | |
| 52 | + | |
| 53 | + "^adi,pwm-active-state$": | |
| 54 | + description: | | |
| 55 | + Integer array, represents the active state of the pwm outputs If set to 0 | |
| 56 | + the pwm uses a logic low output for 100% duty cycle. If set to 1 the pwm | |
| 57 | + uses a logic high output for 100% duty cycle. | |
| 58 | + allOf: | |
| 59 | + - $ref: /schemas/types.yaml#/definitions/uint32-array | |
| 60 | + - minItems: 3 | |
| 61 | + maxItems: 3 | |
| 62 | + items: | |
| 63 | + enum: [0, 1] | |
| 64 | + default: 1 | |
| 65 | + | |
| 66 | +required: | |
| 67 | + - compatible | |
| 68 | + - reg | |
| 69 | + | |
| 70 | +examples: | |
| 71 | + - | | |
| 72 | + i2c { | |
| 73 | + #address-cells = <1>; | |
| 74 | + #size-cells = <0>; | |
| 75 | + | |
| 76 | + hwmon@2e { | |
| 77 | + compatible = "adi,adt7476"; | |
| 78 | + reg = <0x2e>; | |
| 79 | + adi,bypass-attenuator-in0 = <1>; | |
| 80 | + adi,bypass-attenuator-in1 = <0>; | |
| 81 | + adi,pwm-active-state = <1 0 1>; | |
| 82 | + }; | |
| 83 | + }; | |
| 84 | + | |
| @@ -2,20 +2,30 @@ ltc2978 · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible: should contain one of: |
| 5 | + * "lltc,ltc2972" | |
| 5 | 6 | * "lltc,ltc2974" |
| 6 | 7 | * "lltc,ltc2975" |
| 7 | 8 | * "lltc,ltc2977" |
| 8 | 9 | * "lltc,ltc2978" |
| 10 | + * "lltc,ltc2979" | |
| 9 | 11 | * "lltc,ltc2980" |
| 10 | 12 | * "lltc,ltc3880" |
| 11 | 13 | * "lltc,ltc3882" |
| 12 | 14 | * "lltc,ltc3883" |
| 15 | + * "lltc,ltc3884" | |
| 13 | 16 | * "lltc,ltc3886" |
| 14 | 17 | * "lltc,ltc3887" |
| 18 | + * "lltc,ltc3889" | |
| 19 | + * "lltc,ltc7880" | |
| 15 | 20 | * "lltc,ltm2987" |
| 21 | + * "lltc,ltm4664" | |
| 16 | 22 | * "lltc,ltm4675" |
| 17 | 23 | * "lltc,ltm4676" |
| 24 | + * "lltc,ltm4677" | |
| 25 | + * "lltc,ltm4678" | |
| 26 | + * "lltc,ltm4680" | |
| 18 | 27 | * "lltc,ltm4686" |
| 28 | + * "lltc,ltm4700" | |
| 19 | 29 | - reg: I2C slave address |
| 20 | 30 | |
| 21 | 31 | Optional properties: |
| @@ -25,13 +35,17 @@ Optional properties: · 3 unmodified lines | ||
| 25 | 35 | standard binding for regulators; see regulator.txt. |
| 26 | 36 | |
| 27 | 37 | Valid names of regulators depend on number of supplies supported per device: |
| 38 | + * ltc2972 vout0 - vout1 | |
| 28 | 39 | * ltc2974, ltc2975 : vout0 - vout3 |
| 29 | − * ltc2977, ltc2980, ltm2987 : vout0 - vout7 | |
| 40 | + * ltc2977, ltc2979, ltc2980, ltm2987 : vout0 - vout7 | |
| 30 | 41 | * ltc2978 : vout0 - vout7 |
| 31 | − * ltc3880, ltc3882, ltc3886 : vout0 - vout1 | |
| 42 | + * ltc3880, ltc3882, ltc3884, ltc3886, ltc3887, ltc3889 : vout0 - vout1 | |
| 43 | + * ltc7880 : vout0 - vout1 | |
| 32 | 44 | * ltc3883 : vout0 |
| 33 | − * ltm4676 : vout0 - vout1 | |
| 34 | − * ltm4686 : vout0 - vout1 | |
| 45 | + * ltm4664 : vout0 - vout1 | |
| 46 | + * ltm4675, ltm4676, ltm4677, ltm4678 : vout0 - vout1 | |
| 47 | + * ltm4680, ltm4686 : vout0 - vout1 | |
| 48 | + * ltm4700 : vout0 - vout1 | |
| 35 | 49 | |
| 36 | 50 | Example: |
| 37 | 51 | ltc2978@5e { |
| @@ -32,6 +32,8 @@ required: · 31 unmodified lines | ||
| 32 | 32 | - compatible |
| 33 | 33 | - reg |
| 34 | 34 | |
| 35 | +additionalProperties: false | |
| 36 | + | |
| 35 | 37 | examples: |
| 36 | 38 | - | |
| 37 | 39 | i2c { |
| @@ -76,6 +76,8 @@ required: · 75 unmodified lines | ||
| 76 | 76 | - compatible |
| 77 | 77 | - reg |
| 78 | 78 | |
| 79 | +additionalProperties: false | |
| 80 | + | |
| 79 | 81 | examples: |
| 80 | 82 | - | |
| 81 | 83 | i2c { |
| @@ -0,0 +1,97 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/i2c/brcm,brcmstb-i2c.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Broadcom STB BSC IIC Master Controller | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Kamal Dasu <kdasu.kdev@gmail.com> | |
| 11 | + | |
| 12 | +allOf: | |
| 13 | + - $ref: /schemas/i2c/i2c-controller.yaml# | |
| 14 | + | |
| 15 | +properties: | |
| 16 | + compatible: | |
| 17 | + enum: | |
| 18 | + - brcm,bcm2711-hdmi-i2c | |
| 19 | + - brcm,brcmstb-i2c | |
| 20 | + - brcm,brcmper-i2c | |
| 21 | + | |
| 22 | + reg: | |
| 23 | + minItems: 1 | |
| 24 | + maxItems: 2 | |
| 25 | + items: | |
| 26 | + - description: BSC register range | |
| 27 | + - description: Auto-I2C register range | |
| 28 | + | |
| 29 | + reg-names: | |
| 30 | + items: | |
| 31 | + - const: bsc | |
| 32 | + - const: auto-i2c | |
| 33 | + | |
| 34 | + interrupts: | |
| 35 | + maxItems: 1 | |
| 36 | + | |
| 37 | + interrupt-names: | |
| 38 | + maxItems: 1 | |
| 39 | + | |
| 40 | + clock-frequency: | |
| 41 | + enum: | |
| 42 | + - 46875 | |
| 43 | + - 50000 | |
| 44 | + - 93750 | |
| 45 | + - 97500 | |
| 46 | + - 187500 | |
| 47 | + - 200000 | |
| 48 | + - 375000 | |
| 49 | + - 390000 | |
| 50 | + | |
| 51 | +required: | |
| 52 | + - compatible | |
| 53 | + - reg | |
| 54 | + - clock-frequency | |
| 55 | + | |
| 56 | +unevaluatedProperties: false | |
| 57 | + | |
| 58 | +if: | |
| 59 | + properties: | |
| 60 | + compatible: | |
| 61 | + contains: | |
| 62 | + enum: | |
| 63 | + - brcm,bcm2711-hdmi-i2c | |
| 64 | + | |
| 65 | +then: | |
| 66 | + properties: | |
| 67 | + reg: | |
| 68 | + minItems: 2 | |
| 69 | + | |
| 70 | + required: | |
| 71 | + - reg-names | |
| 72 | + | |
| 73 | +else: | |
| 74 | + properties: | |
| 75 | + reg: | |
| 76 | + maxItems: 1 | |
| 77 | + | |
| 78 | +examples: | |
| 79 | + - | | |
| 80 | + bsca: i2c@f0406200 { | |
| 81 | + clock-frequency = <390000>; | |
| 82 | + compatible = "brcm,brcmstb-i2c"; | |
| 83 | + interrupt-parent = <&irq0_intc>; | |
| 84 | + reg = <0xf0406200 0x58>; | |
| 85 | + interrupts = <0x18>; | |
| 86 | + interrupt-names = "upg_bsca"; | |
| 87 | + }; | |
| 88 | + | |
| 89 | + - | | |
| 90 | + ddc0: i2c@7ef04500 { | |
| 91 | + compatible = "brcm,bcm2711-hdmi-i2c"; | |
| 92 | + reg = <0x7ef04500 0x100>, <0x7ef00b00 0x300>; | |
| 93 | + reg-names = "bsc", "auto-i2c"; | |
| 94 | + clock-frequency = <390000>; | |
| 95 | + }; | |
| 96 | + | |
| 97 | +... | |
| @@ -28,8 +28,13 @@ Optional properties: · 27 unmodified lines | ||
| 28 | 28 | "atmel,sama5d4-i2c", |
| 29 | 29 | "atmel,sama5d2-i2c", |
| 30 | 30 | "microchip,sam9x60-i2c". |
| 31 | +- scl-gpios: specify the gpio related to SCL pin | |
| 32 | +- sda-gpios: specify the gpio related to SDA pin | |
| 33 | +- pinctrl: add extra pinctrl to configure i2c pins to gpio function for i2c | |
| 34 | + bus recovery, call it "gpio" state | |
| 31 | 35 | - Child nodes conforming to i2c bus binding |
| 32 | 36 | |
| 37 | + | |
| 33 | 38 | Examples : |
| 34 | 39 | |
| 35 | 40 | i2c0: i2c@fff84000 { |
| @@ -64,6 +69,11 @@ i2c0: i2c@f8034600 { · 28 unmodified lines | ||
| 64 | 69 | clocks = <&flx0>; |
| 65 | 70 | atmel,fifo-size = <16>; |
| 66 | 71 | i2c-sda-hold-time-ns = <336>; |
| 72 | + pinctrl-names = "default", "gpio"; | |
| 73 | + pinctrl-0 = <&pinctrl_i2c0>; | |
| 74 | + pinctrl-1 = <&pinctrl_i2c0_gpio>; | |
| 75 | + sda-gpios = <&pioA 30 GPIO_ACTIVE_HIGH>; | |
| 76 | + scl-gpios = <&pioA 31 GPIO_ACTIVE_HIGH>; | |
| 67 | 77 | |
| 68 | 78 | wm8731: wm8731@1a { |
| 69 | 79 | compatible = "wm8731"; |
| @@ -1,26 +0,0 @@ | ||
| 1 | −Broadcom stb bsc iic master controller | |
| 2 | − | |
| 3 | −Required properties: | |
| 4 | − | |
| 5 | −- compatible: should be "brcm,brcmstb-i2c" or "brcm,brcmper-i2c" | |
| 6 | −- clock-frequency: 32-bit decimal value of iic master clock freqency in Hz | |
| 7 | − valid values are 375000, 390000, 187500, 200000 | |
| 8 | − 93750, 97500, 46875 and 50000 | |
| 9 | −- reg: specifies the base physical address and size of the registers | |
| 10 | − | |
| 11 | −Optional properties : | |
| 12 | − | |
| 13 | −- interrupts: specifies the interrupt number, the irq line to be used | |
| 14 | −- interrupt-names: Interrupt name string | |
| 15 | − | |
| 16 | −Example: | |
| 17 | − | |
| 18 | −bsca: i2c@f0406200 { | |
| 19 | − clock-frequency = <390000>; | |
| 20 | − compatible = "brcm,brcmstb-i2c"; | |
| 21 | − interrupt-parent = <&irq0_intc>; | |
| 22 | − reg = <0xf0406200 0x58>; | |
| 23 | − interrupts = <0x18>; | |
| 24 | − interrupt-names = "upg_bsca"; | |
| 25 | −}; | |
| 26 | − | |
| @@ -1,68 +0,0 @@ | ||
| 1 | −* Rockchip RK3xxx I2C controller | |
| 2 | − | |
| 3 | −This driver interfaces with the native I2C controller present in Rockchip | |
| 4 | −RK3xxx SoCs. | |
| 5 | − | |
| 6 | −Required properties : | |
| 7 | − | |
| 8 | − - reg : Offset and length of the register set for the device | |
| 9 | − - compatible: should be one of the following: | |
| 10 | − - "rockchip,rv1108-i2c": for rv1108 | |
| 11 | − - "rockchip,rk3066-i2c": for rk3066 | |
| 12 | − - "rockchip,rk3188-i2c": for rk3188 | |
| 13 | − - "rockchip,rk3228-i2c": for rk3228 | |
| 14 | − - "rockchip,rk3288-i2c": for rk3288 | |
| 15 | − - "rockchip,rk3328-i2c", "rockchip,rk3399-i2c": for rk3328 | |
| 16 | − - "rockchip,rk3399-i2c": for rk3399 | |
| 17 | − - interrupts : interrupt number | |
| 18 | − - clocks: See ../clock/clock-bindings.txt | |
| 19 | − - For older hardware (rk3066, rk3188, rk3228, rk3288): | |
| 20 | − - There is one clock that's used both to derive the functional clock | |
| 21 | − for the device and as the bus clock. | |
| 22 | − - For newer hardware (rk3399): specified by name | |
| 23 | − - "i2c": This is used to derive the functional clock. | |
| 24 | − - "pclk": This is the bus clock. | |
| 25 | − | |
| 26 | −Required on RK3066, RK3188 : | |
| 27 | − | |
| 28 | − - rockchip,grf : the phandle of the syscon node for the general register | |
| 29 | − file (GRF) | |
| 30 | − - on those SoCs an alias with the correct I2C bus ID (bit offset in the GRF) | |
| 31 | − is also required. | |
| 32 | − | |
| 33 | −Optional properties : | |
| 34 | − | |
| 35 | − - clock-frequency : SCL frequency to use (in Hz). If omitted, 100kHz is used. | |
| 36 | − - i2c-scl-rising-time-ns : Number of nanoseconds the SCL signal takes to rise | |
| 37 | − (t(r) in I2C specification). If not specified this is assumed to be | |
| 38 | − the maximum the specification allows(1000 ns for Standard-mode, | |
| 39 | − 300 ns for Fast-mode) which might cause slightly slower communication. | |
| 40 | − - i2c-scl-falling-time-ns : Number of nanoseconds the SCL signal takes to fall | |
| 41 | − (t(f) in the I2C specification). If not specified this is assumed to | |
| 42 | − be the maximum the specification allows (300 ns) which might cause | |
| 43 | − slightly slower communication. | |
| 44 | − - i2c-sda-falling-time-ns : Number of nanoseconds the SDA signal takes to fall | |
| 45 | − (t(f) in the I2C specification). If not specified we'll use the SCL | |
| 46 | − value since they are the same in nearly all cases. | |
| 47 | − | |
| 48 | −Example: | |
| 49 | − | |
| 50 | −aliases { | |
| 51 | − i2c0 = &i2c0; | |
| 52 | −} | |
| 53 | − | |
| 54 | −i2c0: i2c@2002d000 { | |
| 55 | − compatible = "rockchip,rk3188-i2c"; | |
| 56 | − reg = <0x2002d000 0x1000>; | |
| 57 | − interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>; | |
| 58 | − #address-cells = <1>; | |
| 59 | − #size-cells = <0>; | |
| 60 | − | |
| 61 | − rockchip,grf = <&grf>; | |
| 62 | − | |
| 63 | − clock-names = "i2c"; | |
| 64 | − clocks = <&cru PCLK_I2C0>; | |
| 65 | − | |
| 66 | − i2c-scl-rising-time-ns = <800>; | |
| 67 | − i2c-scl-falling-time-ns = <100>; | |
| 68 | −}; | |
| @@ -0,0 +1,136 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/i2c/i2c-rk3x.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Rockchip RK3xxx I2C controller | |
| 8 | + | |
| 9 | +description: | |
| 10 | + This driver interfaces with the native I2C controller present in Rockchip | |
| 11 | + RK3xxx SoCs. | |
| 12 | + | |
| 13 | +allOf: | |
| 14 | + - $ref: /schemas/i2c/i2c-controller.yaml# | |
| 15 | + | |
| 16 | +maintainers: | |
| 17 | + - Heiko Stuebner <heiko@sntech.de> | |
| 18 | + | |
| 19 | +# Everything else is described in the common file | |
| 20 | +properties: | |
| 21 | + compatible: | |
| 22 | + oneOf: | |
| 23 | + - const: rockchip,rv1108-i2c | |
| 24 | + - const: rockchip,rk3066-i2c | |
| 25 | + - const: rockchip,rk3188-i2c | |
| 26 | + - const: rockchip,rk3228-i2c | |
| 27 | + - const: rockchip,rk3288-i2c | |
| 28 | + - const: rockchip,rk3399-i2c | |
| 29 | + - items: | |
| 30 | + - enum: | |
| 31 | + - rockchip,rk3036-i2c | |
| 32 | + - rockchip,rk3368-i2c | |
| 33 | + - const: rockchip,rk3288-i2c | |
| 34 | + - items: | |
| 35 | + - enum: | |
| 36 | + - rockchip,px30-i2c | |
| 37 | + - rockchip,rk3308-i2c | |
| 38 | + - rockchip,rk3328-i2c | |
| 39 | + - const: rockchip,rk3399-i2c | |
| 40 | + | |
| 41 | + reg: | |
| 42 | + maxItems: 1 | |
| 43 | + | |
| 44 | + interrupts: | |
| 45 | + maxItems: 1 | |
| 46 | + | |
| 47 | + clocks: | |
| 48 | + minItems: 1 | |
| 49 | + items: | |
| 50 | + - description: | |
| 51 | + For older hardware (rk3066, rk3188, rk3228, rk3288) | |
| 52 | + there is one clock that is used both to derive the functional clock | |
| 53 | + for the device and as the bus clock. | |
| 54 | + For newer hardware (rk3399) this clock is used to derive | |
| 55 | + the functional clock | |
| 56 | + - description: | |
| 57 | + For newer hardware (rk3399) this is the bus clock | |
| 58 | + | |
| 59 | + clock-names: | |
| 60 | + minItems: 1 | |
| 61 | + items: | |
| 62 | + - const: i2c | |
| 63 | + - const: pclk | |
| 64 | + | |
| 65 | + rockchip,grf: | |
| 66 | + $ref: /schemas/types.yaml#/definitions/phandle | |
| 67 | + description: | |
| 68 | + Required on RK3066, RK3188 the phandle of the syscon node for | |
| 69 | + the general register file (GRF) | |
| 70 | + On those SoCs an alias with the correct I2C bus ID | |
| 71 | + (bit offset in the GRF) is also required. | |
| 72 | + | |
| 73 | + clock-frequency: | |
| 74 | + default: 100000 | |
| 75 | + description: | |
| 76 | + SCL frequency to use (in Hz). If omitted, 100kHz is used. | |
| 77 | + | |
| 78 | + i2c-scl-rising-time-ns: | |
| 79 | + default: 1000 | |
| 80 | + description: | |
| 81 | + Number of nanoseconds the SCL signal takes to rise | |
| 82 | + (t(r) in I2C specification). If not specified this is assumed to be | |
| 83 | + the maximum the specification allows(1000 ns for Standard-mode, | |
| 84 | + 300 ns for Fast-mode) which might cause slightly slower communication. | |
| 85 | + | |
| 86 | + i2c-scl-falling-time-ns: | |
| 87 | + default: 300 | |
| 88 | + description: | |
| 89 | + Number of nanoseconds the SCL signal takes to fall | |
| 90 | + (t(f) in the I2C specification). If not specified this is assumed to | |
| 91 | + be the maximum the specification allows (300 ns) which might cause | |
| 92 | + slightly slower communication. | |
| 93 | + | |
| 94 | + i2c-sda-falling-time-ns: | |
| 95 | + default: 300 | |
| 96 | + description: | |
| 97 | + Number of nanoseconds the SDA signal takes to fall | |
| 98 | + (t(f) in the I2C specification). If not specified we will use the SCL | |
| 99 | + value since they are the same in nearly all cases. | |
| 100 | + | |
| 101 | +required: | |
| 102 | + - compatible | |
| 103 | + - reg | |
| 104 | + - interrupts | |
| 105 | + - clocks | |
| 106 | + - clock-names | |
| 107 | + | |
| 108 | +if: | |
| 109 | + properties: | |
| 110 | + compatible: | |
| 111 | + contains: | |
| 112 | + enum: | |
| 113 | + - rockchip,rk3066-i2c | |
| 114 | + - rockchip,rk3188-i2c | |
| 115 | + | |
| 116 | +then: | |
| 117 | + required: | |
| 118 | + - rockchip,grf | |
| 119 | + | |
| 120 | +examples: | |
| 121 | + - | | |
| 122 | + #include <dt-bindings/clock/rk3188-cru-common.h> | |
| 123 | + #include <dt-bindings/interrupt-controller/arm-gic.h> | |
| 124 | + #include <dt-bindings/interrupt-controller/irq.h> | |
| 125 | + i2c0: i2c@2002d000 { | |
| 126 | + compatible = "rockchip,rk3188-i2c"; | |
| 127 | + reg = <0x2002d000 0x1000>; | |
| 128 | + interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>; | |
| 129 | + clocks = <&cru PCLK_I2C0>; | |
| 130 | + clock-names = "i2c"; | |
| 131 | + rockchip,grf = <&grf>; | |
| 132 | + i2c-scl-falling-time-ns = <100>; | |
| 133 | + i2c-scl-rising-time-ns = <800>; | |
| 134 | + #address-cells = <1>; | |
| 135 | + #size-cells = <0>; | |
| 136 | + }; | |
| @@ -1,25 +0,0 @@ | ||
| 1 | −UniPhier I2C controller (FIFO-builtin) | |
| 2 | − | |
| 3 | −Required properties: | |
| 4 | −- compatible: should be "socionext,uniphier-fi2c". | |
| 5 | −- #address-cells: should be 1. | |
| 6 | −- #size-cells: should be 0. | |
| 7 | −- reg: offset and length of the register set for the device. | |
| 8 | −- interrupts: a single interrupt specifier. | |
| 9 | −- clocks: phandle to the input clock. | |
| 10 | − | |
| 11 | −Optional properties: | |
| 12 | −- clock-frequency: desired I2C bus frequency in Hz. The maximum supported | |
| 13 | − value is 400000. Defaults to 100000 if not specified. | |
| 14 | − | |
| 15 | −Examples: | |
| 16 | − | |
| 17 | − i2c0: i2c@58780000 { | |
| 18 | − compatible = "socionext,uniphier-fi2c"; | |
| 19 | − reg = <0x58780000 0x80>; | |
| 20 | − #address-cells = <1>; | |
| 21 | − #size-cells = <0>; | |
| 22 | − interrupts = <0 41 4>; | |
| 23 | − clocks = <&i2c_clk>; | |
| 24 | − clock-frequency = <100000>; | |
| 25 | − }; | |
| @@ -1,25 +0,0 @@ | ||
| 1 | −UniPhier I2C controller (FIFO-less) | |
| 2 | − | |
| 3 | −Required properties: | |
| 4 | −- compatible: should be "socionext,uniphier-i2c". | |
| 5 | −- #address-cells: should be 1. | |
| 6 | −- #size-cells: should be 0. | |
| 7 | −- reg: offset and length of the register set for the device. | |
| 8 | −- interrupts: a single interrupt specifier. | |
| 9 | −- clocks: phandle to the input clock. | |
| 10 | − | |
| 11 | −Optional properties: | |
| 12 | −- clock-frequency: desired I2C bus frequency in Hz. The maximum supported | |
| 13 | − value is 400000. Defaults to 100000 if not specified. | |
| 14 | − | |
| 15 | −Examples: | |
| 16 | − | |
| 17 | − i2c0: i2c@58400000 { | |
| 18 | − compatible = "socionext,uniphier-i2c"; | |
| 19 | − reg = <0x58400000 0x40>; | |
| 20 | − #address-cells = <1>; | |
| 21 | − #size-cells = <0>; | |
| 22 | − interrupts = <0 41 1>; | |
| 23 | − clocks = <&i2c_clk>; | |
| 24 | − clock-frequency = <100000>; | |
| 25 | − }; | |
| @@ -0,0 +1,50 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/i2c/socionext,uniphier-fi2c.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: UniPhier I2C controller (FIFO-builtin) | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Masahiro Yamada <yamada.masahiro@socionext.com> | |
| 11 | + | |
| 12 | +allOf: | |
| 13 | + - $ref: /schemas/i2c/i2c-controller.yaml# | |
| 14 | + | |
| 15 | +properties: | |
| 16 | + compatible: | |
| 17 | + const: socionext,uniphier-fi2c | |
| 18 | + | |
| 19 | + reg: | |
| 20 | + maxItems: 1 | |
| 21 | + | |
| 22 | + interrupts: | |
| 23 | + maxItems: 1 | |
| 24 | + | |
| 25 | + clocks: | |
| 26 | + maxItems: 1 | |
| 27 | + | |
| 28 | + clock-frequency: | |
| 29 | + minimum: 100000 | |
| 30 | + maximum: 400000 | |
| 31 | + | |
| 32 | +required: | |
| 33 | + - compatible | |
| 34 | + - reg | |
| 35 | + - "#address-cells" | |
| 36 | + - "#size-cells" | |
| 37 | + - interrupts | |
| 38 | + - clocks | |
| 39 | + | |
| 40 | +examples: | |
| 41 | + - | | |
| 42 | + i2c0: i2c@58780000 { | |
| 43 | + compatible = "socionext,uniphier-fi2c"; | |
| 44 | + reg = <0x58780000 0x80>; | |
| 45 | + #address-cells = <1>; | |
| 46 | + #size-cells = <0>; | |
| 47 | + interrupts = <0 41 4>; | |
| 48 | + clocks = <&i2c_clk>; | |
| 49 | + clock-frequency = <100000>; | |
| 50 | + }; | |
| @@ -0,0 +1,50 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/i2c/socionext,uniphier-i2c.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: UniPhier I2C controller (FIFO-less) | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Masahiro Yamada <yamada.masahiro@socionext.com> | |
| 11 | + | |
| 12 | +allOf: | |
| 13 | + - $ref: /schemas/i2c/i2c-controller.yaml# | |
| 14 | + | |
| 15 | +properties: | |
| 16 | + compatible: | |
| 17 | + const: socionext,uniphier-i2c | |
| 18 | + | |
| 19 | + reg: | |
| 20 | + maxItems: 1 | |
| 21 | + | |
| 22 | + interrupts: | |
| 23 | + maxItems: 1 | |
| 24 | + | |
| 25 | + clocks: | |
| 26 | + maxItems: 1 | |
| 27 | + | |
| 28 | + clock-frequency: | |
| 29 | + minimum: 100000 | |
| 30 | + maximum: 400000 | |
| 31 | + | |
| 32 | +required: | |
| 33 | + - compatible | |
| 34 | + - reg | |
| 35 | + - "#address-cells" | |
| 36 | + - "#size-cells" | |
| 37 | + - interrupts | |
| 38 | + - clocks | |
| 39 | + | |
| 40 | +examples: | |
| 41 | + - | | |
| 42 | + i2c0: i2c@58400000 { | |
| 43 | + compatible = "socionext,uniphier-i2c"; | |
| 44 | + reg = <0x58400000 0x40>; | |
| 45 | + #address-cells = <1>; | |
| 46 | + #size-cells = <0>; | |
| 47 | + interrupts = <0 41 1>; | |
| 48 | + clocks = <&i2c_clk>; | |
| 49 | + clock-frequency = <100000>; | |
| 50 | + }; | |
| @@ -17,9 +17,13 @@ description: | · 16 unmodified lines | ||
| 17 | 17 | |
| 18 | 18 | properties: |
| 19 | 19 | compatible: |
| 20 | − enum: | |
| 21 | − - adi,adxl345 | |
| 22 | − - adi,adxl375 | |
| 20 | + oneOf: | |
| 21 | + - items: | |
| 22 | + - const: adi,adxl346 | |
| 23 | + - const: adi,adxl345 | |
| 24 | + - enum: | |
| 25 | + - adi,adxl345 | |
| 26 | + - adi,adxl375 | |
| 23 | 27 | |
| 24 | 28 | reg: |
| 25 | 29 | maxItems: 1 |
| @@ -36,6 +36,8 @@ required: · 35 unmodified lines | ||
| 36 | 36 | - compatible |
| 37 | 37 | - reg |
| 38 | 38 | |
| 39 | +additionalProperties: false | |
| 40 | + | |
| 39 | 41 | examples: |
| 40 | 42 | - | |
| 41 | 43 | #include <dt-bindings/gpio/gpio.h> |
| @@ -106,7 +106,6 @@ examples: · 105 unmodified lines | ||
| 106 | 106 | spi-cpha; |
| 107 | 107 | clocks = <&ad7192_mclk>; |
| 108 | 108 | clock-names = "mclk"; |
| 109 | − #interrupt-cells = <2>; | |
| 110 | 109 | interrupts = <25 0x2>; |
| 111 | 110 | interrupt-parent = <&gpio>; |
| 112 | 111 | dvdd-supply = <&dvdd>; |
| @@ -67,6 +67,8 @@ required: · 66 unmodified lines | ||
| 67 | 67 | - compatible |
| 68 | 68 | - reg |
| 69 | 69 | |
| 70 | +additionalProperties: false | |
| 71 | + | |
| 70 | 72 | examples: |
| 71 | 73 | - | |
| 72 | 74 | #include <dt-bindings/gpio/gpio.h> |
| @@ -0,0 +1,65 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/iio/adc/adi,ad7923.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Analog Devices AD7923 and similars with 4 and 8 Channel ADCs. | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Michael Hennerich <michael.hennerich@analog.com> | |
| 11 | + - Patrick Vasseur <patrick.vasseur@c-s.fr> | |
| 12 | + | |
| 13 | +description: | | |
| 14 | + Analog Devices AD7904, AD7914, AD7923, AD7924 4 Channel ADCs, and AD7908, | |
| 15 | + AD7918, AD7928 8 Channels ADCs. | |
| 16 | + | |
| 17 | + Specifications about the part can be found at: | |
| 18 | + https://www.analog.com/media/en/technical-documentation/data-sheets/AD7923.pdf | |
| 19 | + https://www.analog.com/media/en/technical-documentation/data-sheets/AD7904_7914_7924.pdf | |
| 20 | + https://www.analog.com/media/en/technical-documentation/data-sheets/AD7908_7918_7928.pdf | |
| 21 | + | |
| 22 | +properties: | |
| 23 | + compatible: | |
| 24 | + enum: | |
| 25 | + - adi,ad7904 | |
| 26 | + - adi,ad7914 | |
| 27 | + - adi,ad7923 | |
| 28 | + - adi,ad7924 | |
| 29 | + - adi,ad7908 | |
| 30 | + - adi,ad7918 | |
| 31 | + - adi,ad7928 | |
| 32 | + | |
| 33 | + reg: | |
| 34 | + maxItems: 1 | |
| 35 | + | |
| 36 | + refin-supply: | |
| 37 | + description: | | |
| 38 | + The regulator supply for ADC reference voltage. | |
| 39 | + | |
| 40 | + '#address-cells': | |
| 41 | + const: 1 | |
| 42 | + | |
| 43 | + '#size-cells': | |
| 44 | + const: 0 | |
| 45 | + | |
| 46 | +required: | |
| 47 | + - compatible | |
| 48 | + - reg | |
| 49 | + | |
| 50 | +examples: | |
| 51 | + - | | |
| 52 | + spi { | |
| 53 | + #address-cells = <1>; | |
| 54 | + #size-cells = <0>; | |
| 55 | + | |
| 56 | + ad7928: adc@0 { | |
| 57 | + compatible = "adi,ad7928"; | |
| 58 | + reg = <0>; | |
| 59 | + spi-max-frequency = <25000000>; | |
| 60 | + refin-supply = <&adc_vref>; | |
| 61 | + | |
| 62 | + #address-cells = <1>; | |
| 63 | + #size-cells = <0>; | |
| 64 | + }; | |
| 65 | + }; | |
| @@ -53,6 +53,8 @@ required: · 52 unmodified lines | ||
| 53 | 53 | - dout-gpios |
| 54 | 54 | - avdd-supply |
| 55 | 55 | |
| 56 | +additionalProperties: false | |
| 57 | + | |
| 56 | 58 | examples: |
| 57 | 59 | - | |
| 58 | 60 | #include <dt-bindings/gpio/gpio.h> |
| @@ -32,6 +32,8 @@ required: · 31 unmodified lines | ||
| 32 | 32 | - vref-supply |
| 33 | 33 | - reg |
| 34 | 34 | |
| 35 | +additionalProperties: false | |
| 36 | + | |
| 35 | 37 | examples: |
| 36 | 38 | - | |
| 37 | 39 | spi { |
| @@ -1,63 +0,0 @@ | ||
| 1 | −* Maxim 1x3x/136x/116xx Analog to Digital Converter (ADC) | |
| 2 | − | |
| 3 | −The node for this driver must be a child node of a I2C controller, hence | |
| 4 | −all mandatory properties for your controller must be specified. See directory: | |
| 5 | − | |
| 6 | − Documentation/devicetree/bindings/i2c | |
| 7 | − | |
| 8 | −for more details. | |
| 9 | − | |
| 10 | −Required properties: | |
| 11 | − - compatible: Should be one of | |
| 12 | − "maxim,max1361" | |
| 13 | − "maxim,max1362" | |
| 14 | − "maxim,max1363" | |
| 15 | − "maxim,max1364" | |
| 16 | − "maxim,max1036" | |
| 17 | − "maxim,max1037" | |
| 18 | − "maxim,max1038" | |
| 19 | − "maxim,max1039" | |
| 20 | − "maxim,max1136" | |
| 21 | − "maxim,max1137" | |
| 22 | − "maxim,max1138" | |
| 23 | − "maxim,max1139" | |
| 24 | − "maxim,max1236" | |
| 25 | − "maxim,max1237" | |
| 26 | − "maxim,max1238" | |
| 27 | − "maxim,max1239" | |
| 28 | − "maxim,max11600" | |
| 29 | − "maxim,max11601" | |
| 30 | − "maxim,max11602" | |
| 31 | − "maxim,max11603" | |
| 32 | − "maxim,max11604" | |
| 33 | − "maxim,max11605" | |
| 34 | − "maxim,max11606" | |
| 35 | − "maxim,max11607" | |
| 36 | − "maxim,max11608" | |
| 37 | − "maxim,max11609" | |
| 38 | − "maxim,max11610" | |
| 39 | − "maxim,max11611" | |
| 40 | − "maxim,max11612" | |
| 41 | − "maxim,max11613" | |
| 42 | − "maxim,max11614" | |
| 43 | − "maxim,max11615" | |
| 44 | − "maxim,max11616" | |
| 45 | − "maxim,max11617" | |
| 46 | − "maxim,max11644" | |
| 47 | − "maxim,max11645" | |
| 48 | − "maxim,max11646" | |
| 49 | − "maxim,max11647" | |
| 50 | − - reg: Should contain the ADC I2C address | |
| 51 | − | |
| 52 | −Optional properties: | |
| 53 | − - vcc-supply: phandle to the regulator that provides power to the ADC. | |
| 54 | − - vref-supply: phandle to the regulator for ADC reference voltage. | |
| 55 | − - interrupts: IRQ line for the ADC. If not used the driver will use | |
| 56 | − polling. | |
| 57 | − | |
| 58 | −Example: | |
| 59 | −adc: max11644@36 { | |
| 60 | − compatible = "maxim,max11644"; | |
| 61 | − reg = <0x36>; | |
| 62 | − vref-supply = <&adc_vref>; | |
| 63 | −}; | |
| @@ -0,0 +1,76 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/iio/adc/maxim,max1238.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Maxim MAX1238 and similar ADCs | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Jonathan Cameron <jic23@kernel.org> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + Family of simple ADCs with i2c inteface and internal references. | |
| 14 | + | |
| 15 | +properties: | |
| 16 | + compatible: | |
| 17 | + enum: | |
| 18 | + - maxim,max1036 | |
| 19 | + - maxim,max1037 | |
| 20 | + - maxim,max1038 | |
| 21 | + - maxim,max1039 | |
| 22 | + - maxim,max1136 | |
| 23 | + - maxim,max1137 | |
| 24 | + - maxim,max1138 | |
| 25 | + - maxim,max1139 | |
| 26 | + - maxim,max1236 | |
| 27 | + - maxim,max1237 | |
| 28 | + - maxim,max1238 | |
| 29 | + - maxim,max1239 | |
| 30 | + - maxim,max11600 | |
| 31 | + - maxim,max11601 | |
| 32 | + - maxim,max11602 | |
| 33 | + - maxim,max11603 | |
| 34 | + - maxim,max11604 | |
| 35 | + - maxim,max11605 | |
| 36 | + - maxim,max11606 | |
| 37 | + - maxim,max11607 | |
| 38 | + - maxim,max11608 | |
| 39 | + - maxim,max11609 | |
| 40 | + - maxim,max11610 | |
| 41 | + - maxim,max11611 | |
| 42 | + - maxim,max11612 | |
| 43 | + - maxim,max11613 | |
| 44 | + - maxim,max11614 | |
| 45 | + - maxim,max11615 | |
| 46 | + - maxim,max11616 | |
| 47 | + - maxim,max11617 | |
| 48 | + - maxim,max11644 | |
| 49 | + - maxim,max11645 | |
| 50 | + - maxim,max11646 | |
| 51 | + - maxim,max11647 | |
| 52 | + | |
| 53 | + reg: | |
| 54 | + maxItems: 1 | |
| 55 | + | |
| 56 | + vcc-supply: true | |
| 57 | + vref-supply: | |
| 58 | + description: Optional external reference. If not supplied, internal | |
| 59 | + reference will be used. | |
| 60 | + | |
| 61 | +required: | |
| 62 | + - compatible | |
| 63 | + - reg | |
| 64 | + | |
| 65 | +examples: | |
| 66 | + - | | |
| 67 | + i2c { | |
| 68 | + #address-cells = <1>; | |
| 69 | + #size-cells = <0>; | |
| 70 | + | |
| 71 | + adc@36 { | |
| 72 | + compatible = "maxim,max1238"; | |
| 73 | + reg = <0x36>; | |
| 74 | + }; | |
| 75 | + }; | |
| 76 | +... | |
| @@ -0,0 +1,50 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/iio/adc/maxim,max1363.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Maxim MAX1363 and similar ADCs | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Jonathan Cameron <jic23@kernel.org> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + Family of ADCs with i2c inteface, internal references and threshold | |
| 14 | + monitoring. | |
| 15 | + | |
| 16 | +properties: | |
| 17 | + compatible: | |
| 18 | + enum: | |
| 19 | + - maxim,max1361 | |
| 20 | + - maxim,max1362 | |
| 21 | + - maxim,max1363 | |
| 22 | + - maxim,max1364 | |
| 23 | + | |
| 24 | + reg: | |
| 25 | + maxItems: 1 | |
| 26 | + | |
| 27 | + vcc-supply: true | |
| 28 | + vref-supply: | |
| 29 | + description: Optional external reference. If not supplied, internal | |
| 30 | + reference will be used. | |
| 31 | + | |
| 32 | + interrupts: | |
| 33 | + maxItems: 1 | |
| 34 | + | |
| 35 | +required: | |
| 36 | + - compatible | |
| 37 | + - reg | |
| 38 | + | |
| 39 | +examples: | |
| 40 | + - | | |
| 41 | + i2c { | |
| 42 | + #address-cells = <1>; | |
| 43 | + #size-cells = <0>; | |
| 44 | + | |
| 45 | + adc@36 { | |
| 46 | + compatible = "maxim,max1363"; | |
| 47 | + reg = <0x36>; | |
| 48 | + }; | |
| 49 | + }; | |
| 50 | +... | |
| @@ -52,6 +52,8 @@ required: · 51 unmodified lines | ||
| 52 | 52 | - compatible |
| 53 | 53 | - reg |
| 54 | 54 | |
| 55 | +additionalProperties: false | |
| 56 | + | |
| 55 | 57 | examples: |
| 56 | 58 | - | |
| 57 | 59 | spi { |
| @@ -6,6 +6,7 @@ Required properties: · 5 unmodified lines | ||
| 6 | 6 | - compatible: "nuvoton,npcm750-adc" for the NPCM7XX BMC. |
| 7 | 7 | - reg: specifies physical base address and size of the registers. |
| 8 | 8 | - interrupts: Contain the ADC interrupt with flags for falling edge. |
| 9 | +- resets : phandle to the reset control for this device. | |
| 9 | 10 | |
| 10 | 11 | Optional properties: |
| 11 | 12 | - clocks: phandle of ADC reference clock, in case the clock is not |
| @@ -21,4 +22,5 @@ adc: adc@f000c000 { · 9 unmodified lines | ||
| 21 | 22 | reg = <0xf000c000 0x8>; |
| 22 | 23 | interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>; |
| 23 | 24 | clocks = <&clk NPCM7XX_CLK_ADC>; |
| 25 | + resets = <&rstc NPCM7XX_RESET_IPSRST1 NPCM7XX_RESET_ADC>; | |
| 24 | 26 | }; |
| @@ -1,149 +0,0 @@ | ||
| 1 | −STMicroelectronics STM32 ADC device driver | |
| 2 | − | |
| 3 | −STM32 ADC is a successive approximation analog-to-digital converter. | |
| 4 | −It has several multiplexed input channels. Conversions can be performed | |
| 5 | −in single, continuous, scan or discontinuous mode. Result of the ADC is | |
| 6 | −stored in a left-aligned or right-aligned 32-bit data register. | |
| 7 | −Conversions can be launched in software or using hardware triggers. | |
| 8 | − | |
| 9 | −The analog watchdog feature allows the application to detect if the input | |
| 10 | −voltage goes beyond the user-defined, higher or lower thresholds. | |
| 11 | − | |
| 12 | −Each STM32 ADC block can have up to 3 ADC instances. | |
| 13 | − | |
| 14 | −Each instance supports two contexts to manage conversions, each one has its | |
| 15 | −own configurable sequence and trigger: | |
| 16 | −- regular conversion can be done in sequence, running in background | |
| 17 | −- injected conversions have higher priority, and so have the ability to | |
| 18 | − interrupt regular conversion sequence (either triggered in SW or HW). | |
| 19 | − Regular sequence is resumed, in case it has been interrupted. | |
| 20 | − | |
| 21 | −Contents of a stm32 adc root node: | |
| 22 | −----------------------------------- | |
| 23 | −Required properties: | |
| 24 | −- compatible: Should be one of: | |
| 25 | − "st,stm32f4-adc-core" | |
| 26 | − "st,stm32h7-adc-core" | |
| 27 | − "st,stm32mp1-adc-core" | |
| 28 | −- reg: Offset and length of the ADC block register set. | |
| 29 | −- interrupts: One or more interrupts for ADC block. Some parts like stm32f4 | |
| 30 | − and stm32h7 share a common ADC interrupt line. stm32mp1 has two separate | |
| 31 | − interrupt lines, one for each ADC within ADC block. | |
| 32 | −- clocks: Core can use up to two clocks, depending on part used: | |
| 33 | − - "adc" clock: for the analog circuitry, common to all ADCs. | |
| 34 | − It's required on stm32f4. | |
| 35 | − It's optional on stm32h7. | |
| 36 | − - "bus" clock: for registers access, common to all ADCs. | |
| 37 | − It's not present on stm32f4. | |
| 38 | − It's required on stm32h7. | |
| 39 | −- clock-names: Must be "adc" and/or "bus" depending on part used. | |
| 40 | −- interrupt-controller: Identifies the controller node as interrupt-parent | |
| 41 | −- vdda-supply: Phandle to the vdda input analog voltage. | |
| 42 | −- vref-supply: Phandle to the vref input analog reference voltage. | |
| 43 | −- #interrupt-cells = <1>; | |
| 44 | −- #address-cells = <1>; | |
| 45 | −- #size-cells = <0>; | |
| 46 | − | |
| 47 | −Optional properties: | |
| 48 | −- A pinctrl state named "default" for each ADC channel may be defined to set | |
| 49 | − inX ADC pins in mode of operation for analog input on external pin. | |
| 50 | −- booster-supply: Phandle to the embedded booster regulator that can be used | |
| 51 | − to supply ADC analog input switches on stm32h7 and stm32mp1. | |
| 52 | −- vdd-supply: Phandle to the vdd input voltage. It can be used to supply ADC | |
| 53 | − analog input switches on stm32mp1. | |
| 54 | −- st,syscfg: Phandle to system configuration controller. It can be used to | |
| 55 | − control the analog circuitry on stm32mp1. | |
| 56 | −- st,max-clk-rate-hz: Allow to specify desired max clock rate used by analog | |
| 57 | − circuitry. | |
| 58 | − | |
| 59 | −Contents of a stm32 adc child node: | |
| 60 | −----------------------------------- | |
| 61 | −An ADC block node should contain at least one subnode, representing an | |
| 62 | −ADC instance available on the machine. | |
| 63 | − | |
| 64 | −Required properties: | |
| 65 | −- compatible: Should be one of: | |
| 66 | − "st,stm32f4-adc" | |
| 67 | − "st,stm32h7-adc" | |
| 68 | − "st,stm32mp1-adc" | |
| 69 | −- reg: Offset of ADC instance in ADC block (e.g. may be 0x0, 0x100, 0x200). | |
| 70 | −- clocks: Input clock private to this ADC instance. It's required only on | |
| 71 | − stm32f4, that has per instance clock input for registers access. | |
| 72 | −- interrupts: IRQ Line for the ADC (e.g. may be 0 for adc@0, 1 for adc@100 or | |
| 73 | − 2 for adc@200). | |
| 74 | −- st,adc-channels: List of single-ended channels muxed for this ADC. | |
| 75 | − It can have up to 16 channels on stm32f4 or 20 channels on stm32h7, numbered | |
| 76 | − from 0 to 15 or 19 (resp. for in0..in15 or in0..in19). | |
| 77 | −- st,adc-diff-channels: List of differential channels muxed for this ADC. | |
| 78 | − Depending on part used, some channels can be configured as differential | |
| 79 | − instead of single-ended (e.g. stm32h7). List here positive and negative | |
| 80 | − inputs pairs as <vinp vinn>, <vinp vinn>,... vinp and vinn are numbered | |
| 81 | − from 0 to 19 on stm32h7) | |
| 82 | − Note: At least one of "st,adc-channels" or "st,adc-diff-channels" is required. | |
| 83 | − Both properties can be used together. Some channels can be used as | |
| 84 | − single-ended and some other ones as differential (mixed). But channels | |
| 85 | − can't be configured both as single-ended and differential (invalid). | |
| 86 | −- #io-channel-cells = <1>: See the IIO bindings section "IIO consumers" in | |
| 87 | − Documentation/devicetree/bindings/iio/iio-bindings.txt | |
| 88 | − | |
| 89 | −Optional properties: | |
| 90 | −- dmas: Phandle to dma channel for this ADC instance. | |
| 91 | − See ../../dma/dma.txt for details. | |
| 92 | −- dma-names: Must be "rx" when dmas property is being used. | |
| 93 | −- assigned-resolution-bits: Resolution (bits) to use for conversions. Must | |
| 94 | − match device available resolutions: | |
| 95 | − * can be 6, 8, 10 or 12 on stm32f4 | |
| 96 | − * can be 8, 10, 12, 14 or 16 on stm32h7 | |
| 97 | − Default is maximum resolution if unset. | |
| 98 | −- st,min-sample-time-nsecs: Minimum sampling time in nanoseconds. | |
| 99 | − Depending on hardware (board) e.g. high/low analog input source impedance, | |
| 100 | − fine tune of ADC sampling time may be recommended. | |
| 101 | − This can be either one value or an array that matches 'st,adc-channels' list, | |
| 102 | − to set sample time resp. for all channels, or independently for each channel. | |
| 103 | − | |
| 104 | −Example: | |
| 105 | − adc: adc@40012000 { | |
| 106 | − compatible = "st,stm32f4-adc-core"; | |
| 107 | − reg = <0x40012000 0x400>; | |
| 108 | − interrupts = <18>; | |
| 109 | − clocks = <&rcc 0 168>; | |
| 110 | − clock-names = "adc"; | |
| 111 | − vref-supply = <®_vref>; | |
| 112 | − interrupt-controller; | |
| 113 | − pinctrl-names = "default"; | |
| 114 | − pinctrl-0 = <&adc3_in8_pin>; | |
| 115 | − | |
| 116 | − #interrupt-cells = <1>; | |
| 117 | − #address-cells = <1>; | |
| 118 | − #size-cells = <0>; | |
| 119 | − | |
| 120 | − adc@0 { | |
| 121 | − compatible = "st,stm32f4-adc"; | |
| 122 | − #io-channel-cells = <1>; | |
| 123 | − reg = <0x0>; | |
| 124 | − clocks = <&rcc 0 168>; | |
| 125 | − interrupt-parent = <&adc>; | |
| 126 | − interrupts = <0>; | |
| 127 | − st,adc-channels = <8>; | |
| 128 | − dmas = <&dma2 0 0 0x400 0x0>; | |
| 129 | − dma-names = "rx"; | |
| 130 | − assigned-resolution-bits = <8>; | |
| 131 | − }; | |
| 132 | − ... | |
| 133 | − other adc child nodes follow... | |
| 134 | − }; | |
| 135 | − | |
| 136 | −Example to setup: | |
| 137 | −- channel 1 as single-ended | |
| 138 | −- channels 2 & 3 as differential (with resp. 6 & 7 negative inputs) | |
| 139 | − | |
| 140 | − adc: adc@40022000 { | |
| 141 | − compatible = "st,stm32h7-adc-core"; | |
| 142 | − ... | |
| 143 | − adc1: adc@0 { | |
| 144 | − compatible = "st,stm32h7-adc"; | |
| 145 | − ... | |
| 146 | − st,adc-channels = <1>; | |
| 147 | − st,adc-diff-channels = <2 6>, <3 7>; | |
| 148 | − }; | |
| 149 | − }; | |
| @@ -0,0 +1,458 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: "http://devicetree.org/schemas/bindings/iio/adc/st,stm32-adc.yaml#" | |
| 5 | +$schema: "http://devicetree.org/meta-schemas/core.yaml#" | |
| 6 | + | |
| 7 | +title: STMicroelectronics STM32 ADC bindings | |
| 8 | + | |
| 9 | +description: | | |
| 10 | + STM32 ADC is a successive approximation analog-to-digital converter. | |
| 11 | + It has several multiplexed input channels. Conversions can be performed | |
| 12 | + in single, continuous, scan or discontinuous mode. Result of the ADC is | |
| 13 | + stored in a left-aligned or right-aligned 32-bit data register. | |
| 14 | + Conversions can be launched in software or using hardware triggers. | |
| 15 | + | |
| 16 | + The analog watchdog feature allows the application to detect if the input | |
| 17 | + voltage goes beyond the user-defined, higher or lower thresholds. | |
| 18 | + | |
| 19 | + Each STM32 ADC block can have up to 3 ADC instances. | |
| 20 | + | |
| 21 | +maintainers: | |
| 22 | + - Fabrice Gasnier <fabrice.gasnier@st.com> | |
| 23 | + | |
| 24 | +properties: | |
| 25 | + compatible: | |
| 26 | + enum: | |
| 27 | + - st,stm32f4-adc-core | |
| 28 | + - st,stm32h7-adc-core | |
| 29 | + - st,stm32mp1-adc-core | |
| 30 | + | |
| 31 | + reg: | |
| 32 | + maxItems: 1 | |
| 33 | + | |
| 34 | + interrupts: | |
| 35 | + description: | | |
| 36 | + One or more interrupts for ADC block, depending on part used: | |
| 37 | + - stm32f4 and stm32h7 share a common ADC interrupt line. | |
| 38 | + - stm32mp1 has two separate interrupt lines, one for each ADC within | |
| 39 | + ADC block. | |
| 40 | + minItems: 1 | |
| 41 | + maxItems: 2 | |
| 42 | + | |
| 43 | + clocks: | |
| 44 | + description: | | |
| 45 | + Core can use up to two clocks, depending on part used: | |
| 46 | + - "adc" clock: for the analog circuitry, common to all ADCs. | |
| 47 | + It's required on stm32f4. | |
| 48 | + It's optional on stm32h7 and stm32mp1. | |
| 49 | + - "bus" clock: for registers access, common to all ADCs. | |
| 50 | + It's not present on stm32f4. | |
| 51 | + It's required on stm32h7 and stm32mp1. | |
| 52 | + | |
| 53 | + clock-names: true | |
| 54 | + | |
| 55 | + st,max-clk-rate-hz: | |
| 56 | + description: | |
| 57 | + Allow to specify desired max clock rate used by analog circuitry. | |
| 58 | + | |
| 59 | + vdda-supply: | |
| 60 | + description: Phandle to the vdda input analog voltage. | |
| 61 | + | |
| 62 | + vref-supply: | |
| 63 | + description: Phandle to the vref input analog reference voltage. | |
| 64 | + | |
| 65 | + booster-supply: | |
| 66 | + description: | |
| 67 | + Phandle to the embedded booster regulator that can be used to supply ADC | |
| 68 | + analog input switches on stm32h7 and stm32mp1. | |
| 69 | + | |
| 70 | + vdd-supply: | |
| 71 | + description: | |
| 72 | + Phandle to the vdd input voltage. It can be used to supply ADC analog | |
| 73 | + input switches on stm32mp1. | |
| 74 | + | |
| 75 | + st,syscfg: | |
| 76 | + description: | |
| 77 | + Phandle to system configuration controller. It can be used to control the | |
| 78 | + analog circuitry on stm32mp1. | |
| 79 | + allOf: | |
| 80 | + - $ref: "/schemas/types.yaml#/definitions/phandle-array" | |
| 81 | + | |
| 82 | + interrupt-controller: true | |
| 83 | + | |
| 84 | + '#interrupt-cells': | |
| 85 | + const: 1 | |
| 86 | + | |
| 87 | + '#address-cells': | |
| 88 | + const: 1 | |
| 89 | + | |
| 90 | + '#size-cells': | |
| 91 | + const: 0 | |
| 92 | + | |
| 93 | +allOf: | |
| 94 | + - if: | |
| 95 | + properties: | |
| 96 | + compatible: | |
| 97 | + contains: | |
| 98 | + const: st,stm32f4-adc-core | |
| 99 | + | |
| 100 | + then: | |
| 101 | + properties: | |
| 102 | + clocks: | |
| 103 | + maxItems: 1 | |
| 104 | + | |
| 105 | + clock-names: | |
| 106 | + const: adc | |
| 107 | + | |
| 108 | + interrupts: | |
| 109 | + items: | |
| 110 | + - description: interrupt line common for all ADCs | |
| 111 | + | |
| 112 | + st,max-clk-rate-hz: | |
| 113 | + minimum: 600000 | |
| 114 | + maximum: 36000000 | |
| 115 | + default: 36000000 | |
| 116 | + | |
| 117 | + booster-supply: false | |
| 118 | + | |
| 119 | + vdd-supply: false | |
| 120 | + | |
| 121 | + st,syscfg: false | |
| 122 | + | |
| 123 | + - if: | |
| 124 | + properties: | |
| 125 | + compatible: | |
| 126 | + contains: | |
| 127 | + const: st,stm32h7-adc-core | |
| 128 | + | |
| 129 | + then: | |
| 130 | + properties: | |
| 131 | + clocks: | |
| 132 | + minItems: 1 | |
| 133 | + maxItems: 2 | |
| 134 | + | |
| 135 | + clock-names: | |
| 136 | + items: | |
| 137 | + - const: bus | |
| 138 | + - const: adc | |
| 139 | + minItems: 1 | |
| 140 | + maxItems: 2 | |
| 141 | + | |
| 142 | + interrupts: | |
| 143 | + items: | |
| 144 | + - description: interrupt line common for all ADCs | |
| 145 | + | |
| 146 | + st,max-clk-rate-hz: | |
| 147 | + minimum: 120000 | |
| 148 | + maximum: 36000000 | |
| 149 | + default: 36000000 | |
| 150 | + | |
| 151 | + vdd-supply: false | |
| 152 | + | |
| 153 | + st,syscfg: false | |
| 154 | + | |
| 155 | + - if: | |
| 156 | + properties: | |
| 157 | + compatible: | |
| 158 | + contains: | |
| 159 | + const: st,stm32mp1-adc-core | |
| 160 | + | |
| 161 | + then: | |
| 162 | + properties: | |
| 163 | + clocks: | |
| 164 | + minItems: 1 | |
| 165 | + maxItems: 2 | |
| 166 | + | |
| 167 | + clock-names: | |
| 168 | + items: | |
| 169 | + - const: bus | |
| 170 | + - const: adc | |
| 171 | + minItems: 1 | |
| 172 | + maxItems: 2 | |
| 173 | + | |
| 174 | + interrupts: | |
| 175 | + items: | |
| 176 | + - description: interrupt line for ADC1 | |
| 177 | + - description: interrupt line for ADC2 | |
| 178 | + | |
| 179 | + st,max-clk-rate-hz: | |
| 180 | + minimum: 120000 | |
| 181 | + maximum: 36000000 | |
| 182 | + default: 36000000 | |
| 183 | + | |
| 184 | +additionalProperties: false | |
| 185 | + | |
| 186 | +required: | |
| 187 | + - compatible | |
| 188 | + - reg | |
| 189 | + - interrupts | |
| 190 | + - clocks | |
| 191 | + - clock-names | |
| 192 | + - vdda-supply | |
| 193 | + - vref-supply | |
| 194 | + - interrupt-controller | |
| 195 | + - '#interrupt-cells' | |
| 196 | + - '#address-cells' | |
| 197 | + - '#size-cells' | |
| 198 | + | |
| 199 | +patternProperties: | |
| 200 | + "^adc@[0-9]+$": | |
| 201 | + type: object | |
| 202 | + description: | |
| 203 | + An ADC block node should contain at least one subnode, representing an | |
| 204 | + ADC instance available on the machine. | |
| 205 | + | |
| 206 | + properties: | |
| 207 | + compatible: | |
| 208 | + enum: | |
| 209 | + - st,stm32f4-adc | |
| 210 | + - st,stm32h7-adc | |
| 211 | + - st,stm32mp1-adc | |
| 212 | + | |
| 213 | + reg: | |
| 214 | + description: | | |
| 215 | + Offset of ADC instance in ADC block. Valid values are: | |
| 216 | + - 0x0: ADC1 | |
| 217 | + - 0x100: ADC2 | |
| 218 | + - 0x200: ADC3 (stm32f4 only) | |
| 219 | + maxItems: 1 | |
| 220 | + | |
| 221 | + '#io-channel-cells': | |
| 222 | + const: 1 | |
| 223 | + | |
| 224 | + interrupts: | |
| 225 | + description: | | |
| 226 | + IRQ Line for the ADC instance. Valid values are: | |
| 227 | + - 0 for adc@0 | |
| 228 | + - 1 for adc@100 | |
| 229 | + - 2 for adc@200 (stm32f4 only) | |
| 230 | + maxItems: 1 | |
| 231 | + | |
| 232 | + clocks: | |
| 233 | + description: | |
| 234 | + Input clock private to this ADC instance. It's required only on | |
| 235 | + stm32f4, that has per instance clock input for registers access. | |
| 236 | + maxItems: 1 | |
| 237 | + | |
| 238 | + dmas: | |
| 239 | + description: RX DMA Channel | |
| 240 | + maxItems: 1 | |
| 241 | + | |
| 242 | + dma-names: | |
| 243 | + const: rx | |
| 244 | + | |
| 245 | + assigned-resolution-bits: | |
| 246 | + description: | | |
| 247 | + Resolution (bits) to use for conversions: | |
| 248 | + - can be 6, 8, 10 or 12 on stm32f4 | |
| 249 | + - can be 8, 10, 12, 14 or 16 on stm32h7 and stm32mp1 | |
| 250 | + allOf: | |
| 251 | + - $ref: /schemas/types.yaml#/definitions/uint32 | |
| 252 | + | |
| 253 | + st,adc-channels: | |
| 254 | + description: | | |
| 255 | + List of single-ended channels muxed for this ADC. It can have up to: | |
| 256 | + - 16 channels, numbered from 0 to 15 (for in0..in15) on stm32f4 | |
| 257 | + - 20 channels, numbered from 0 to 19 (for in0..in19) on stm32h7 and | |
| 258 | + stm32mp1. | |
| 259 | + allOf: | |
| 260 | + - $ref: /schemas/types.yaml#/definitions/uint32-array | |
| 261 | + | |
| 262 | + st,adc-diff-channels: | |
| 263 | + description: | | |
| 264 | + List of differential channels muxed for this ADC. Some channels can | |
| 265 | + be configured as differential instead of single-ended on stm32h7 and | |
| 266 | + on stm32mp1. Positive and negative inputs pairs are listed: | |
| 267 | + <vinp vinn>, <vinp vinn>,... vinp and vinn are numbered from 0 to 19. | |
| 268 | + | |
| 269 | + Note: At least one of "st,adc-channels" or "st,adc-diff-channels" is | |
| 270 | + required. Both properties can be used together. Some channels can be | |
| 271 | + used as single-ended and some other ones as differential (mixed). But | |
| 272 | + channels can't be configured both as single-ended and differential. | |
| 273 | + allOf: | |
| 274 | + - $ref: /schemas/types.yaml#/definitions/uint32-matrix | |
| 275 | + - items: | |
| 276 | + items: | |
| 277 | + - description: | | |
| 278 | + "vinp" indicates positive input number | |
| 279 | + minimum: 0 | |
| 280 | + maximum: 19 | |
| 281 | + - description: | | |
| 282 | + "vinn" indicates negative input number | |
| 283 | + minimum: 0 | |
| 284 | + maximum: 19 | |
| 285 | + | |
| 286 | + st,min-sample-time-nsecs: | |
| 287 | + description: | |
| 288 | + Minimum sampling time in nanoseconds. Depending on hardware (board) | |
| 289 | + e.g. high/low analog input source impedance, fine tune of ADC | |
| 290 | + sampling time may be recommended. This can be either one value or an | |
| 291 | + array that matches "st,adc-channels" and/or "st,adc-diff-channels" | |
| 292 | + list, to set sample time resp. for all channels, or independently for | |
| 293 | + each channel. | |
| 294 | + allOf: | |
| 295 | + - $ref: /schemas/types.yaml#/definitions/uint32-array | |
| 296 | + | |
| 297 | + allOf: | |
| 298 | + - if: | |
| 299 | + properties: | |
| 300 | + compatible: | |
| 301 | + contains: | |
| 302 | + const: st,stm32f4-adc | |
| 303 | + | |
| 304 | + then: | |
| 305 | + properties: | |
| 306 | + reg: | |
| 307 | + enum: | |
| 308 | + - 0x0 | |
| 309 | + - 0x100 | |
| 310 | + - 0x200 | |
| 311 | + | |
| 312 | + interrupts: | |
| 313 | + minimum: 0 | |
| 314 | + maximum: 2 | |
| 315 | + | |
| 316 | + assigned-resolution-bits: | |
| 317 | + enum: [6, 8, 10, 12] | |
| 318 | + default: 12 | |
| 319 | + | |
| 320 | + st,adc-channels: | |
| 321 | + minItems: 1 | |
| 322 | + maxItems: 16 | |
| 323 | + items: | |
| 324 | + minimum: 0 | |
| 325 | + maximum: 15 | |
| 326 | + | |
| 327 | + st,adc-diff-channels: false | |
| 328 | + | |
| 329 | + st,min-sample-time-nsecs: | |
| 330 | + minItems: 1 | |
| 331 | + maxItems: 16 | |
| 332 | + items: | |
| 333 | + minimum: 80 | |
| 334 | + | |
| 335 | + required: | |
| 336 | + - clocks | |
| 337 | + | |
| 338 | + - if: | |
| 339 | + properties: | |
| 340 | + compatible: | |
| 341 | + contains: | |
| 342 | + enum: | |
| 343 | + - st,stm32h7-adc | |
| 344 | + - st,stm32mp1-adc | |
| 345 | + | |
| 346 | + then: | |
| 347 | + properties: | |
| 348 | + reg: | |
| 349 | + enum: | |
| 350 | + - 0x0 | |
| 351 | + - 0x100 | |
| 352 | + | |
| 353 | + interrupts: | |
| 354 | + minimum: 0 | |
| 355 | + maximum: 1 | |
| 356 | + | |
| 357 | + assigned-resolution-bits: | |
| 358 | + enum: [8, 10, 12, 14, 16] | |
| 359 | + default: 16 | |
| 360 | + | |
| 361 | + st,adc-channels: | |
| 362 | + minItems: 1 | |
| 363 | + maxItems: 20 | |
| 364 | + items: | |
| 365 | + minimum: 0 | |
| 366 | + maximum: 19 | |
| 367 | + | |
| 368 | + st,min-sample-time-nsecs: | |
| 369 | + minItems: 1 | |
| 370 | + maxItems: 20 | |
| 371 | + items: | |
| 372 | + minimum: 40 | |
| 373 | + | |
| 374 | + additionalProperties: false | |
| 375 | + | |
| 376 | + anyOf: | |
| 377 | + - required: | |
| 378 | + - st,adc-channels | |
| 379 | + - required: | |
| 380 | + - st,adc-diff-channels | |
| 381 | + | |
| 382 | + required: | |
| 383 | + - compatible | |
| 384 | + - reg | |
| 385 | + - interrupts | |
| 386 | + - '#io-channel-cells' | |
| 387 | + | |
| 388 | +examples: | |
| 389 | + - | | |
| 390 | + // Example 1: with stm32f429, ADC1, single-ended channel 8 | |
| 391 | + adc123: adc@40012000 { | |
| 392 | + compatible = "st,stm32f4-adc-core"; | |
| 393 | + reg = <0x40012000 0x400>; | |
| 394 | + interrupts = <18>; | |
| 395 | + clocks = <&rcc 0 168>; | |
| 396 | + clock-names = "adc"; | |
| 397 | + st,max-clk-rate-hz = <36000000>; | |
| 398 | + vdda-supply = <&vdda>; | |
| 399 | + vref-supply = <&vref>; | |
| 400 | + interrupt-controller; | |
| 401 | + #interrupt-cells = <1>; | |
| 402 | + #address-cells = <1>; | |
| 403 | + #size-cells = <0>; | |
| 404 | + adc@0 { | |
| 405 | + compatible = "st,stm32f4-adc"; | |
| 406 | + #io-channel-cells = <1>; | |
| 407 | + reg = <0x0>; | |
| 408 | + clocks = <&rcc 0 168>; | |
| 409 | + interrupt-parent = <&adc123>; | |
| 410 | + interrupts = <0>; | |
| 411 | + st,adc-channels = <8>; | |
| 412 | + dmas = <&dma2 0 0 0x400 0x0>; | |
| 413 | + dma-names = "rx"; | |
| 414 | + assigned-resolution-bits = <8>; | |
| 415 | + }; | |
| 416 | + // ... | |
| 417 | + // other adc child nodes follow... | |
| 418 | + }; | |
| 419 | + | |
| 420 | + - | | |
| 421 | + // Example 2: with stm32mp157c to setup ADC1 with: | |
| 422 | + // - channels 0 & 1 as single-ended | |
| 423 | + // - channels 2 & 3 as differential (with resp. 6 & 7 negative inputs) | |
| 424 | + #include <dt-bindings/interrupt-controller/arm-gic.h> | |
| 425 | + #include <dt-bindings/clock/stm32mp1-clks.h> | |
| 426 | + adc12: adc@48003000 { | |
| 427 | + compatible = "st,stm32mp1-adc-core"; | |
| 428 | + reg = <0x48003000 0x400>; | |
| 429 | + interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>, | |
| 430 | + <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>; | |
| 431 | + clocks = <&rcc ADC12>, <&rcc ADC12_K>; | |
| 432 | + clock-names = "bus", "adc"; | |
| 433 | + booster-supply = <&booster>; | |
| 434 | + vdd-supply = <&vdd>; | |
| 435 | + vdda-supply = <&vdda>; | |
| 436 | + vref-supply = <&vref>; | |
| 437 | + st,syscfg = <&syscfg>; | |
| 438 | + interrupt-controller; | |
| 439 | + #interrupt-cells = <1>; | |
| 440 | + #address-cells = <1>; | |
| 441 | + #size-cells = <0>; | |
| 442 | + adc@0 { | |
| 443 | + compatible = "st,stm32mp1-adc"; | |
| 444 | + #io-channel-cells = <1>; | |
| 445 | + reg = <0x0>; | |
| 446 | + interrupt-parent = <&adc12>; | |
| 447 | + interrupts = <0>; | |
| 448 | + st,adc-channels = <0 1>; | |
| 449 | + st,adc-diff-channels = <2 6>, <3 7>; | |
| 450 | + st,min-sample-time-nsecs = <5000>; | |
| 451 | + dmas = <&dmamux1 9 0x400 0x05>; | |
| 452 | + dma-names = "rx"; | |
| 453 | + }; | |
| 454 | + // ... | |
| 455 | + // other adc child node follow... | |
| 456 | + }; | |
| 457 | + | |
| 458 | +... | |
| @@ -69,6 +69,8 @@ required: · 68 unmodified lines | ||
| 69 | 69 | - "#address-cells" |
| 70 | 70 | - "#size-cells" |
| 71 | 71 | |
| 72 | +additionalProperties: false | |
| 73 | + | |
| 72 | 74 | patternProperties: |
| 73 | 75 | "^filter@[0-9]+$": |
| 74 | 76 | type: object |
| @@ -0,0 +1,49 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/iio/amplifiers/adi,hmc425a.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: HMC425A 6-bit Digital Step Attenuator | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | +- Michael Hennerich <michael.hennerich@analog.com> | |
| 11 | +- Beniamin Bia <beniamin.bia@analog.com> | |
| 12 | + | |
| 13 | +description: | | |
| 14 | + Digital Step Attenuator IIO device with gpio interface. | |
| 15 | + HMC425A 0.5 dB LSB GaAs MMIC 6-BIT DIGITAL POSITIVE CONTROL ATTENUATOR, 2.2 - 8.0 GHz | |
| 16 | + https://www.analog.com/media/en/technical-documentation/data-sheets/hmc425A.pdf | |
| 17 | + | |
| 18 | +properties: | |
| 19 | + compatible: | |
| 20 | + enum: | |
| 21 | + - adi,hmc425a | |
| 22 | + | |
| 23 | + vcc-supply: true | |
| 24 | + | |
| 25 | + ctrl-gpios: | |
| 26 | + description: | |
| 27 | + Must contain an array of 6 GPIO specifiers, referring to the GPIO pins | |
| 28 | + connected to the control pins V1-V6. | |
| 29 | + minItems: 6 | |
| 30 | + maxItems: 6 | |
| 31 | + | |
| 32 | +required: | |
| 33 | + - compatible | |
| 34 | + - ctrl-gpios | |
| 35 | + | |
| 36 | +examples: | |
| 37 | + - | | |
| 38 | + #include <dt-bindings/gpio/gpio.h> | |
| 39 | + gpio_hmc425a: hmc425a { | |
| 40 | + compatible = "adi,hmc425a"; | |
| 41 | + ctrl-gpios = <&gpio 40 GPIO_ACTIVE_HIGH>, | |
| 42 | + <&gpio 39 GPIO_ACTIVE_HIGH>, | |
| 43 | + <&gpio 38 GPIO_ACTIVE_HIGH>, | |
| 44 | + <&gpio 37 GPIO_ACTIVE_HIGH>, | |
| 45 | + <&gpio 36 GPIO_ACTIVE_HIGH>, | |
| 46 | + <&gpio 35 GPIO_ACTIVE_HIGH>; | |
| 47 | + vcc-supply = <&foo>; | |
| 48 | + }; | |
| 49 | +... | |
| @@ -1,21 +0,0 @@ | ||
| 1 | −* Atlas Scientific EC-SM OEM sensor | |
| 2 | − | |
| 3 | −http://www.atlas-scientific.com/_files/_datasheets/_oem/EC_oem_datasheet.pdf | |
| 4 | − | |
| 5 | −Required properties: | |
| 6 | − | |
| 7 | − - compatible: must be "atlas,ec-sm" | |
| 8 | − - reg: the I2C address of the sensor | |
| 9 | − - interrupts: the sole interrupt generated by the device | |
| 10 | − | |
| 11 | − Refer to interrupt-controller/interrupts.txt for generic interrupt client | |
| 12 | − node bindings. | |
| 13 | − | |
| 14 | −Example: | |
| 15 | − | |
| 16 | −atlas@64 { | |
| 17 | − compatible = "atlas,ec-sm"; | |
| 18 | − reg = <0x64>; | |
| 19 | − interrupt-parent = <&gpio1>; | |
| 20 | − interrupts = <16 2>; | |
| 21 | −}; | |
| @@ -1,21 +0,0 @@ | ||
| 1 | −* Atlas Scientific ORP-SM OEM sensor | |
| 2 | − | |
| 3 | −https://www.atlas-scientific.com/_files/_datasheets/_oem/ORP_oem_datasheet.pdf | |
| 4 | − | |
| 5 | −Required properties: | |
| 6 | − | |
| 7 | − - compatible: must be "atlas,orp-sm" | |
| 8 | − - reg: the I2C address of the sensor | |
| 9 | − - interrupts: the sole interrupt generated by the device | |
| 10 | − | |
| 11 | − Refer to interrupt-controller/interrupts.txt for generic interrupt client | |
| 12 | − node bindings. | |
| 13 | − | |
| 14 | −Example: | |
| 15 | − | |
| 16 | −atlas@66 { | |
| 17 | − compatible = "atlas,orp-sm"; | |
| 18 | − reg = <0x66>; | |
| 19 | − interrupt-parent = <&gpio1>; | |
| 20 | − interrupts = <16 2>; | |
| 21 | −}; | |
| @@ -1,21 +0,0 @@ | ||
| 1 | −* Atlas Scientific pH-SM OEM sensor | |
| 2 | − | |
| 3 | −http://www.atlas-scientific.com/_files/_datasheets/_oem/pH_oem_datasheet.pdf | |
| 4 | − | |
| 5 | −Required properties: | |
| 6 | − | |
| 7 | − - compatible: must be "atlas,ph-sm" | |
| 8 | − - reg: the I2C address of the sensor | |
| 9 | − - interrupts: the sole interrupt generated by the device | |
| 10 | − | |
| 11 | − Refer to interrupt-controller/interrupts.txt for generic interrupt client | |
| 12 | − node bindings. | |
| 13 | − | |
| 14 | −Example: | |
| 15 | − | |
| 16 | −atlas@65 { | |
| 17 | − compatible = "atlas,ph-sm"; | |
| 18 | − reg = <0x65>; | |
| 19 | − interrupt-parent = <&gpio1>; | |
| 20 | − interrupts = <16 2>; | |
| 21 | −}; | |
| @@ -0,0 +1,53 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/iio/chemical/atlas,sensor.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Atlas Scientific OEM sensors | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Matt Ranostay <matt.ranostay@konsulko.com> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + Atlas Scientific OEM sensors connected via I2C | |
| 14 | + | |
| 15 | + Datasheets: | |
| 16 | + http://www.atlas-scientific.com/_files/_datasheets/_oem/DO_oem_datasheet.pdf | |
| 17 | + http://www.atlas-scientific.com/_files/_datasheets/_oem/EC_oem_datasheet.pdf | |
| 18 | + http://www.atlas-scientific.com/_files/_datasheets/_oem/ORP_oem_datasheet.pdf | |
| 19 | + http://www.atlas-scientific.com/_files/_datasheets/_oem/pH_oem_datasheet.pdf | |
| 20 | + | |
| 21 | +properties: | |
| 22 | + compatible: | |
| 23 | + enum: | |
| 24 | + - atlas,do-sm | |
| 25 | + - atlas,ec-sm | |
| 26 | + - atlas,orp-sm | |
| 27 | + - atlas,ph-sm | |
| 28 | + | |
| 29 | + reg: | |
| 30 | + maxItems: 1 | |
| 31 | + | |
| 32 | + interrupts: | |
| 33 | + maxItems: 1 | |
| 34 | + | |
| 35 | +required: | |
| 36 | + - compatible | |
| 37 | + - reg | |
| 38 | + | |
| 39 | +additionalProperties: false | |
| 40 | + | |
| 41 | +examples: | |
| 42 | + - | | |
| 43 | + i2c { | |
| 44 | + #address-cells = <1>; | |
| 45 | + #size-cells = <0>; | |
| 46 | + | |
| 47 | + atlas@66 { | |
| 48 | + compatible = "atlas,orp-sm"; | |
| 49 | + reg = <0x66>; | |
| 50 | + interrupt-parent = <&gpio1>; | |
| 51 | + interrupts = <16 2>; | |
| 52 | + }; | |
| 53 | + }; | |
| @@ -38,6 +38,8 @@ required: · 37 unmodified lines | ||
| 38 | 38 | - compatible |
| 39 | 39 | - vcc-supply |
| 40 | 40 | |
| 41 | +additionalProperties: false | |
| 42 | + | |
| 41 | 43 | examples: |
| 42 | 44 | - | |
| 43 | 45 | serial { |
| @@ -24,6 +24,8 @@ required: · 23 unmodified lines | ||
| 24 | 24 | - compatible |
| 25 | 25 | - reg |
| 26 | 26 | |
| 27 | +additionalProperties: false | |
| 28 | + | |
| 27 | 29 | examples: |
| 28 | 30 | - | |
| 29 | 31 | i2c { |
| @@ -0,0 +1,185 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | +# Copyright 2020 Analog Devices Inc. | |
| 3 | +%YAML 1.2 | |
| 4 | +--- | |
| 5 | +$id: http://devicetree.org/schemas/bindings/iio/dac/adi,ad5770r.yaml# | |
| 6 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 7 | + | |
| 8 | +title: Analog Devices AD5770R DAC device driver | |
| 9 | + | |
| 10 | +maintainers: | |
| 11 | + - Mircea Caprioru <mircea.caprioru@analog.com> | |
| 12 | + | |
| 13 | +description: | | |
| 14 | + Bindings for the Analog Devices AD5770R current DAC device. Datasheet can be | |
| 15 | + found here: | |
| 16 | + https://www.analog.com/media/en/technical-documentation/data-sheets/AD5770R.pdf | |
| 17 | + | |
| 18 | +properties: | |
| 19 | + compatible: | |
| 20 | + enum: | |
| 21 | + - adi,ad5770r | |
| 22 | + | |
| 23 | + reg: | |
| 24 | + maxItems: 1 | |
| 25 | + | |
| 26 | + avdd-supply: | |
| 27 | + description: | |
| 28 | + AVdd voltage supply. Represents two different supplies in the datasheet | |
| 29 | + that are in fact the same. | |
| 30 | + | |
| 31 | + iovdd-supply: | |
| 32 | + description: | |
| 33 | + Voltage supply for the chip interface. | |
| 34 | + | |
| 35 | + vref-supply: | |
| 36 | + description: Specify the voltage of the external reference used. | |
| 37 | + Available reference options are 1.25 V or 2.5 V. If no | |
| 38 | + external reference declared then the device will use the | |
| 39 | + internal reference of 1.25 V. | |
| 40 | + | |
| 41 | + adi,external-resistor: | |
| 42 | + description: Specify if an external 2.5k ohm resistor is used. If not | |
| 43 | + specified the device will use an internal 2.5k ohm resistor. | |
| 44 | + The precision resistor is used for reference current generation. | |
| 45 | + type: boolean | |
| 46 | + | |
| 47 | + reset-gpios: | |
| 48 | + description: GPIO spec for the RESET pin. If specified, it will be | |
| 49 | + asserted during driver probe. | |
| 50 | + maxItems: 1 | |
| 51 | + | |
| 52 | + channel0: | |
| 53 | + description: Represents an external channel which are | |
| 54 | + connected to the DAC. Channel 0 can act both as a current | |
| 55 | + source and sink. | |
| 56 | + type: object | |
| 57 | + | |
| 58 | + properties: | |
| 59 | + num: | |
| 60 | + description: This represents the channel number. | |
| 61 | + items: | |
| 62 | + const: 0 | |
| 63 | + | |
| 64 | + adi,range-microamp: | |
| 65 | + description: Output range of the channel. | |
| 66 | + oneOf: | |
| 67 | + - $ref: /schemas/types.yaml#/definitions/int32-array | |
| 68 | + - items: | |
| 69 | + - enum: [0 300000] | |
| 70 | + - enum: [-60000 0] | |
| 71 | + - enum: [-60000 300000] | |
| 72 | + | |
| 73 | + channel1: | |
| 74 | + description: Represents an external channel which are | |
| 75 | + connected to the DAC. | |
| 76 | + type: object | |
| 77 | + | |
| 78 | + properties: | |
| 79 | + num: | |
| 80 | + description: This represents the channel number. | |
| 81 | + items: | |
| 82 | + const: 1 | |
| 83 | + | |
| 84 | + adi,range-microamp: | |
| 85 | + description: Output range of the channel. | |
| 86 | + oneOf: | |
| 87 | + - $ref: /schemas/types.yaml#/definitions/uint32-array | |
| 88 | + - items: | |
| 89 | + - enum: [0 140000] | |
| 90 | + - enum: [0 250000] | |
| 91 | + | |
| 92 | + channel2: | |
| 93 | + description: Represents an external channel which are | |
| 94 | + connected to the DAC. | |
| 95 | + type: object | |
| 96 | + | |
| 97 | + properties: | |
| 98 | + num: | |
| 99 | + description: This represents the channel number. | |
| 100 | + items: | |
| 101 | + const: 2 | |
| 102 | + | |
| 103 | + adi,range-microamp: | |
| 104 | + description: Output range of the channel. | |
| 105 | + oneOf: | |
| 106 | + - $ref: /schemas/types.yaml#/definitions/uint32-array | |
| 107 | + - items: | |
| 108 | + - enum: [0 140000] | |
| 109 | + - enum: [0 250000] | |
| 110 | + | |
| 111 | +patternProperties: | |
| 112 | + "^channel@([3-5])$": | |
| 113 | + type: object | |
| 114 | + description: Represents the external channels which are connected to the DAC. | |
| 115 | + properties: | |
| 116 | + num: | |
| 117 | + description: This represents the channel number. | |
| 118 | + items: | |
| 119 | + minimum: 3 | |
| 120 | + maximum: 5 | |
| 121 | + | |
| 122 | + adi,range-microamp: | |
| 123 | + description: Output range of the channel. | |
| 124 | + oneOf: | |
| 125 | + - $ref: /schemas/types.yaml#/definitions/uint32-array | |
| 126 | + - items: | |
| 127 | + - enum: [0 45000] | |
| 128 | + - enum: [0 100000] | |
| 129 | + | |
| 130 | +required: | |
| 131 | +- reg | |
| 132 | +- diff-channels | |
| 133 | +- channel0 | |
| 134 | +- channel1 | |
| 135 | +- channel2 | |
| 136 | +- channel3 | |
| 137 | +- channel4 | |
| 138 | +- channel5 | |
| 139 | + | |
| 140 | +examples: | |
| 141 | + - | | |
| 142 | + spi { | |
| 143 | + #address-cells = <1>; | |
| 144 | + #size-cells = <0>; | |
| 145 | + | |
| 146 | + ad5770r@0 { | |
| 147 | + compatible = "ad5770r"; | |
| 148 | + reg = <0>; | |
| 149 | + spi-max-frequency = <1000000>; | |
| 150 | + vref-supply = <&vref>; | |
| 151 | + adi,external-resistor; | |
| 152 | + reset-gpios = <&gpio 22 0>; | |
| 153 | + | |
| 154 | + channel@0 { | |
| 155 | + num = <0>; | |
| 156 | + adi,range-microamp = <(-60000) 300000>; | |
| 157 | + }; | |
| 158 | + | |
| 159 | + channel@1 { | |
| 160 | + num = <1>; | |
| 161 | + adi,range-microamp = <0 140000>; | |
| 162 | + }; | |
| 163 | + | |
| 164 | + channel@2 { | |
| 165 | + num = <2>; | |
| 166 | + adi,range-microamp = <0 55000>; | |
| 167 | + }; | |
| 168 | + | |
| 169 | + channel@3 { | |
| 170 | + num = <3>; | |
| 171 | + adi,range-microamp = <0 45000>; | |
| 172 | + }; | |
| 173 | + | |
| 174 | + channel@4 { | |
| 175 | + num = <4>; | |
| 176 | + adi,range-microamp = <0 45000>; | |
| 177 | + }; | |
| 178 | + | |
| 179 | + channel@5 { | |
| 180 | + num = <5>; | |
| 181 | + adi,range-microamp = <0 45000>; | |
| 182 | + }; | |
| 183 | + }; | |
| 184 | + }; | |
| 185 | +... | |
| @@ -34,6 +34,8 @@ required: · 33 unmodified lines | ||
| 34 | 34 | - reg |
| 35 | 35 | - vref-supply |
| 36 | 36 | |
| 37 | +additionalProperties: false | |
| 38 | + | |
| 37 | 39 | examples: |
| 38 | 40 | - | |
| 39 | 41 | spi { |
| @@ -1,4 +1,4 @@ | ||
| 1 | −Linear Technology LTC2632 DAC device driver | |
| 1 | +Linear Technology LTC2632/2636 DAC | |
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible: Has to contain one of the following: |
| @@ -8,6 +8,12 @@ Required properties: · 3 unmodified lines | ||
| 8 | 8 | lltc,ltc2632-h12 |
| 9 | 9 | lltc,ltc2632-h10 |
| 10 | 10 | lltc,ltc2632-h8 |
| 11 | + lltc,ltc2636-l12 | |
| 12 | + lltc,ltc2636-l10 | |
| 13 | + lltc,ltc2636-l8 | |
| 14 | + lltc,ltc2636-h12 | |
| 15 | + lltc,ltc2636-h10 | |
| 16 | + lltc,ltc2636-h8 | |
| 11 | 17 | |
| 12 | 18 | Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt |
| 13 | 19 | apply. In particular, "reg" and "spi-max-frequency" properties must be given. |
| @@ -4,6 +4,7 @@ http://www.invensense.com/mems/gyro/mpu6050.html · 3 unmodified lines | ||
| 4 | 4 | |
| 5 | 5 | Required properties: |
| 6 | 6 | - compatible : should be one of |
| 7 | + "invensense,mpu6000" | |
| 7 | 8 | "invensense,mpu6050" |
| 8 | 9 | "invensense,mpu6500" |
| 9 | 10 | "invensense,mpu6515" |
| @@ -11,7 +12,11 @@ Required properties: · 1 unmodified line | ||
| 11 | 12 | "invensense,mpu9250" |
| 12 | 13 | "invensense,mpu9255" |
| 13 | 14 | "invensense,icm20608" |
| 15 | + "invensense,icm20609" | |
| 16 | + "invensense,icm20689" | |
| 14 | 17 | "invensense,icm20602" |
| 18 | + "invensense,icm20690" | |
| 19 | + "invensense,iam20680" | |
| 15 | 20 | - reg : the I2C address of the sensor |
| 16 | 21 | - interrupts: interrupt mapping for IRQ. It should be configured with flags |
| 17 | 22 | IRQ_TYPE_LEVEL_HIGH, IRQ_TYPE_EDGE_RISING, IRQ_TYPE_LEVEL_LOW or |
| @@ -28,6 +28,8 @@ required: · 27 unmodified lines | ||
| 28 | 28 | - compatible |
| 29 | 29 | - reg |
| 30 | 30 | |
| 31 | +additionalProperties: false | |
| 32 | + | |
| 31 | 33 | examples: |
| 32 | 34 | - | |
| 33 | 35 | #include <dt-bindings/interrupt-controller/irq.h> |
| @@ -28,6 +28,8 @@ required: · 27 unmodified lines | ||
| 28 | 28 | - compatible |
| 29 | 29 | - reg |
| 30 | 30 | |
| 31 | +additionalProperties: false | |
| 32 | + | |
| 31 | 33 | examples: |
| 32 | 34 | - | |
| 33 | 35 | i2c { |
| @@ -0,0 +1,43 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/iio/light/dynaimage,al3010.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Dyna-Image AL3010 sensor | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - David Heidelberg <david@ixit.cz> | |
| 11 | + | |
| 12 | +properties: | |
| 13 | + compatible: | |
| 14 | + const: dynaimage,al3010 | |
| 15 | + | |
| 16 | + reg: | |
| 17 | + maxItems: 1 | |
| 18 | + | |
| 19 | + interrupts: | |
| 20 | + maxItems: 1 | |
| 21 | + | |
| 22 | + vdd-supply: | |
| 23 | + description: Regulator that provides power to the sensor | |
| 24 | + | |
| 25 | +required: | |
| 26 | + - compatible | |
| 27 | + - reg | |
| 28 | + | |
| 29 | +examples: | |
| 30 | + - | | |
| 31 | + #include <dt-bindings/interrupt-controller/irq.h> | |
| 32 | + | |
| 33 | + i2c { | |
| 34 | + #address-cells = <1>; | |
| 35 | + #size-cells = <0>; | |
| 36 | + | |
| 37 | + light-sensor@1c { | |
| 38 | + compatible = "dynaimage,al3010"; | |
| 39 | + reg = <0x1c>; | |
| 40 | + vdd-supply = <&vdd_reg>; | |
| 41 | + interrupts = <0 99 4>; | |
| 42 | + }; | |
| 43 | + }; | |
| @@ -0,0 +1,43 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/iio/light/dynaimage,al3320a.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Dyna-Image AL3320A sensor | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - David Heidelberg <david@ixit.cz> | |
| 11 | + | |
| 12 | +properties: | |
| 13 | + compatible: | |
| 14 | + const: dynaimage,al3320a | |
| 15 | + | |
| 16 | + reg: | |
| 17 | + maxItems: 1 | |
| 18 | + | |
| 19 | + interrupts: | |
| 20 | + maxItems: 1 | |
| 21 | + | |
| 22 | + vdd-supply: | |
| 23 | + description: Regulator that provides power to the sensor | |
| 24 | + | |
| 25 | +required: | |
| 26 | + - compatible | |
| 27 | + - reg | |
| 28 | + | |
| 29 | +examples: | |
| 30 | + - | | |
| 31 | + #include <dt-bindings/interrupt-controller/irq.h> | |
| 32 | + | |
| 33 | + i2c { | |
| 34 | + #address-cells = <1>; | |
| 35 | + #size-cells = <0>; | |
| 36 | + | |
| 37 | + light-sensor@1c { | |
| 38 | + compatible = "dynaimage,al3320a"; | |
| 39 | + reg = <0x1c>; | |
| 40 | + vdd-supply = <&vdd_reg>; | |
| 41 | + interrupts = <0 99 4>; | |
| 42 | + }; | |
| 43 | + }; | |
| @@ -38,6 +38,8 @@ required: · 37 unmodified lines | ||
| 38 | 38 | - compatible |
| 39 | 39 | - reg |
| 40 | 40 | |
| 41 | +additionalProperties: false | |
| 42 | + | |
| 41 | 43 | examples: |
| 42 | 44 | - | |
| 43 | 45 | #include <dt-bindings/interrupt-controller/irq.h> |
| @@ -29,6 +29,8 @@ required: · 28 unmodified lines | ||
| 29 | 29 | - compatible |
| 30 | 30 | - reg |
| 31 | 31 | |
| 32 | +additionalProperties: false | |
| 33 | + | |
| 32 | 34 | examples: |
| 33 | 35 | - | |
| 34 | 36 | i2c { |
| @@ -0,0 +1,85 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/iio/light/sharp,gp2ap002.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Sharp GP2AP002A00F and GP2AP002S00F proximity and ambient light sensors | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Linus Walleij <linus.walleij@linaro.org> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + Proximity and ambient light sensor with IR LED for the proximity | |
| 14 | + sensing and an analog output for light intensity. The ambient light | |
| 15 | + sensor output is not available on the GP2AP002S00F variant. | |
| 16 | + | |
| 17 | +properties: | |
| 18 | + compatible: | |
| 19 | + enum: | |
| 20 | + - sharp,gp2ap002a00f | |
| 21 | + - sharp,gp2ap002s00f | |
| 22 | + | |
| 23 | + reg: | |
| 24 | + maxItems: 1 | |
| 25 | + | |
| 26 | + interrupts: | |
| 27 | + maxItems: 1 | |
| 28 | + description: an interrupt for proximity, usually a GPIO line | |
| 29 | + | |
| 30 | + vdd-supply: | |
| 31 | + description: VDD power supply a phandle to a regulator | |
| 32 | + | |
| 33 | + vio-supply: | |
| 34 | + description: VIO power supply a phandle to a regulator | |
| 35 | + | |
| 36 | + io-channels: | |
| 37 | + maxItems: 1 | |
| 38 | + description: ALSOUT ADC channel to read the ambient light | |
| 39 | + | |
| 40 | + io-channel-names: | |
| 41 | + const: alsout | |
| 42 | + | |
| 43 | + sharp,proximity-far-hysteresis: | |
| 44 | + $ref: /schemas/types.yaml#/definitions/uint8 | |
| 45 | + description: | | |
| 46 | + Hysteresis setting for "far" object detection, this setting is | |
| 47 | + device-unique and adjust the optical setting for proximity detection | |
| 48 | + of a "far away" object in front of the sensor. | |
| 49 | + | |
| 50 | + sharp,proximity-close-hysteresis: | |
| 51 | + $ref: /schemas/types.yaml#/definitions/uint8 | |
| 52 | + description: | | |
| 53 | + Hysteresis setting for "close" object detection, this setting is | |
| 54 | + device-unique and adjust the optical setting for proximity detection | |
| 55 | + of a "close" object in front of the sensor. | |
| 56 | + | |
| 57 | +required: | |
| 58 | + - compatible | |
| 59 | + - reg | |
| 60 | + - interrupts | |
| 61 | + - sharp,proximity-far-hysteresis | |
| 62 | + - sharp,proximity-close-hysteresis | |
| 63 | + | |
| 64 | +examples: | |
| 65 | + - | | |
| 66 | + #include <dt-bindings/interrupt-controller/irq.h> | |
| 67 | + | |
| 68 | + i2c { | |
| 69 | + #address-cells = <1>; | |
| 70 | + #size-cells = <0>; | |
| 71 | + | |
| 72 | + light-sensor@44 { | |
| 73 | + compatible = "sharp,gp2ap002a00f"; | |
| 74 | + reg = <0x44>; | |
| 75 | + interrupts = <18 IRQ_TYPE_EDGE_FALLING>; | |
| 76 | + vdd-supply = <&vdd_regulator>; | |
| 77 | + vio-supply = <&vio_regulator>; | |
| 78 | + io-channels = <&adc_channel>; | |
| 79 | + io-channel-names = "alsout"; | |
| 80 | + sharp,proximity-far-hysteresis = /bits/ 8 <0x2f>; | |
| 81 | + sharp,proximity-close-hysteresis = /bits/ 8 <0x0f>; | |
| 82 | + }; | |
| 83 | + }; | |
| 84 | + | |
| 85 | +... | |
| @@ -30,6 +30,8 @@ required: · 29 unmodified lines | ||
| 30 | 30 | - compatible |
| 31 | 31 | - reg |
| 32 | 32 | |
| 33 | +additionalProperties: false | |
| 34 | + | |
| 33 | 35 | examples: |
| 34 | 36 | - | |
| 35 | 37 | #include <dt-bindings/interrupt-controller/irq.h> |
| @@ -32,6 +32,8 @@ required: · 31 unmodified lines | ||
| 32 | 32 | - compatible |
| 33 | 33 | - reg |
| 34 | 34 | |
| 35 | +additionalProperties: false | |
| 36 | + | |
| 35 | 37 | examples: |
| 36 | 38 | - | |
| 37 | 39 | i2c { |
| @@ -62,6 +62,8 @@ required: · 61 unmodified lines | ||
| 62 | 62 | - compatible |
| 63 | 63 | - reg |
| 64 | 64 | |
| 65 | +additionalProperties: false | |
| 66 | + | |
| 65 | 67 | examples: |
| 66 | 68 | - | |
| 67 | 69 | #include <dt-bindings/interrupt-controller/irq.h> |
| @@ -45,6 +45,8 @@ required: · 44 unmodified lines | ||
| 45 | 45 | - compatible |
| 46 | 46 | - reg |
| 47 | 47 | |
| 48 | +additionalProperties: false | |
| 49 | + | |
| 48 | 50 | examples: |
| 49 | 51 | - | |
| 50 | 52 | #include <dt-bindings/interrupt-controller/irq.h> |
| @@ -33,6 +33,8 @@ required: · 32 unmodified lines | ||
| 33 | 33 | - compatible |
| 34 | 34 | - reg |
| 35 | 35 | |
| 36 | +additionalProperties: false | |
| 37 | + | |
| 36 | 38 | examples: |
| 37 | 39 | - | |
| 38 | 40 | #include <dt-bindings/interrupt-controller/irq.h> |
| @@ -25,6 +25,9 @@ properties: · 24 unmodified lines | ||
| 25 | 25 | - bosch,bmp280 |
| 26 | 26 | - bosch,bme280 |
| 27 | 27 | |
| 28 | + reg: | |
| 29 | + maxItems: 1 | |
| 30 | + | |
| 28 | 31 | vddd-supply: |
| 29 | 32 | description: |
| 30 | 33 | digital voltage regulator (see regulator/regulator.txt) |
| @@ -49,6 +52,8 @@ required: · 18 unmodified lines | ||
| 49 | 52 | - vddd-supply |
| 50 | 53 | - vdda-supply |
| 51 | 54 | |
| 55 | +additionalProperties: false | |
| 56 | + | |
| 52 | 57 | examples: |
| 53 | 58 | - | |
| 54 | 59 | #include <dt-bindings/gpio/gpio.h> |
| @@ -51,11 +51,31 @@ properties: · 50 unmodified lines | ||
| 51 | 51 | the time between two interrupts is measured in the driver. |
| 52 | 52 | maxItems: 1 |
| 53 | 53 | |
| 54 | + power-gpios: | |
| 55 | + description: | |
| 56 | + Definition of the GPIO for power management of connected peripheral | |
| 57 | + (output). | |
| 58 | + This GPIO can be used by the external hardware for power management. | |
| 59 | + When the device gets suspended it's switched off and when it resumes | |
| 60 | + it's switched on again. After some period of inactivity the driver | |
| 61 | + get suspended automatically (autosuspend feature). | |
| 62 | + maxItems: 1 | |
| 63 | + | |
| 64 | + startup-time-ms: | |
| 65 | + description: | |
| 66 | + This is the startup time the device needs after a resume to be up and | |
| 67 | + running. | |
| 68 | + minimum: 0 | |
| 69 | + maximum: 1000 | |
| 70 | + default: 100 | |
| 71 | + | |
| 54 | 72 | required: |
| 55 | 73 | - compatible |
| 56 | 74 | - trig-gpios |
| 57 | 75 | - echo-gpios |
| 58 | 76 | |
| 77 | +additionalProperties: false | |
| 78 | + | |
| 59 | 79 | examples: |
| 60 | 80 | - | |
| 61 | 81 | #include <dt-bindings/gpio/gpio.h> |
| @@ -42,6 +42,8 @@ required: · 41 unmodified lines | ||
| 42 | 42 | - compatible |
| 43 | 43 | - ping-gpios |
| 44 | 44 | |
| 45 | +additionalProperties: false | |
| 46 | + | |
| 45 | 47 | examples: |
| 46 | 48 | - | |
| 47 | 49 | #include <dt-bindings/gpio/gpio.h> |
| @@ -123,12 +123,11 @@ patternProperties: · 122 unmodified lines | ||
| 123 | 123 | sign. |
| 124 | 124 | allOf: |
| 125 | 125 | - $ref: /schemas/types.yaml#/definitions/uint64-matrix |
| 126 | + minItems: 3 | |
| 127 | + maxItems: 64 | |
| 126 | 128 | items: |
| 127 | − minItems: 3 | |
| 128 | − maxItems: 64 | |
| 129 | − items: | |
| 130 | − minItems: 2 | |
| 131 | − maxItems: 2 | |
| 129 | + minItems: 2 | |
| 130 | + maxItems: 2 | |
| 132 | 131 | |
| 133 | 132 | "^diode@": |
| 134 | 133 | type: object |
| @@ -328,12 +327,11 @@ patternProperties: · 193 unmodified lines | ||
| 328 | 327 | 78 and 79. |
| 329 | 328 | allOf: |
| 330 | 329 | - $ref: /schemas/types.yaml#/definitions/uint64-matrix |
| 330 | + minItems: 3 | |
| 331 | + maxItems: 64 | |
| 331 | 332 | items: |
| 332 | − minItems: 3 | |
| 333 | − maxItems: 64 | |
| 334 | − items: | |
| 335 | − minItems: 2 | |
| 336 | − maxItems: 2 | |
| 333 | + minItems: 2 | |
| 334 | + maxItems: 2 | |
| 337 | 335 | |
| 338 | 336 | adi,custom-steinhart: |
| 339 | 337 | description: |
| @@ -398,6 +396,8 @@ required: · 58 unmodified lines | ||
| 398 | 396 | - reg |
| 399 | 397 | - interrupts |
| 400 | 398 | |
| 399 | +additionalProperties: false | |
| 400 | + | |
| 401 | 401 | examples: |
| 402 | 402 | - | |
| 403 | 403 | #include <dt-bindings/interrupt-controller/irq.h> |
| @@ -463,16 +463,16 @@ examples: · 59 unmodified lines | ||
| 463 | 463 | adi,sensor-type = <9>; //custom thermocouple |
| 464 | 464 | adi,single-ended; |
| 465 | 465 | adi,custom-thermocouple = /bits/ 64 |
| 466 | − <(-50220000) 0 | |
| 467 | − (-30200000) 99100000 | |
| 468 | − (-5300000) 135400000 | |
| 469 | − 0 273150000 | |
| 470 | − 40200000 361200000 | |
| 471 | − 55300000 522100000 | |
| 472 | − 88300000 720300000 | |
| 473 | − 132200000 811200000 | |
| 474 | − 188700000 922500000 | |
| 475 | − 460400000 1000000000>; //10 pairs | |
| 466 | + <(-50220000) 0>, | |
| 467 | + <(-30200000) 99100000>, | |
| 468 | + <(-5300000) 135400000>, | |
| 469 | + <0 273150000>, | |
| 470 | + <40200000 361200000>, | |
| 471 | + <55300000 522100000>, | |
| 472 | + <88300000 720300000>, | |
| 473 | + <132200000 811200000>, | |
| 474 | + <188700000 922500000>, | |
| 475 | + <460400000 1000000000>; //10 pairs | |
| 476 | 476 | }; |
| 477 | 477 | |
| 478 | 478 | }; |
| @@ -5,6 +5,7 @@ Required properties: · 4 unmodified lines | ||
| 5 | 5 | * "cypress,tm2-touchkey" - for the touchkey found on the tm2 board |
| 6 | 6 | * "cypress,midas-touchkey" - for the touchkey found on midas boards |
| 7 | 7 | * "cypress,aries-touchkey" - for the touchkey found on aries boards |
| 8 | + * "coreriver,tc360-touchkey" - for the Coreriver TouchCore 360 touchkey | |
| 8 | 9 | - reg: I2C address of the chip. |
| 9 | 10 | - interrupts: interrupt to which the chip is connected (see interrupt |
| 10 | 11 | binding[0]). |
| @@ -26,6 +26,8 @@ required: · 25 unmodified lines | ||
| 26 | 26 | - compatible |
| 27 | 27 | - enable-gpios |
| 28 | 28 | |
| 29 | +additionalProperties: false | |
| 30 | + | |
| 29 | 31 | examples: |
| 30 | 32 | - | |
| 31 | 33 | #include <dt-bindings/gpio/gpio.h> |
| @@ -0,0 +1,132 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/input/iqs62x-keys.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Azoteq IQS620A/621/622/624/625 Keys and Switches | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Jeff LaBundy <jeff@labundy.com> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + The Azoteq IQS620A, IQS621, IQS622, IQS624 and IQS625 multi-function sensors | |
| 14 | + feature a variety of self-capacitive, mutual-inductive and Hall-effect sens- | |
| 15 | + ing capabilities that can facilitate a variety of contactless key and switch | |
| 16 | + applications. | |
| 17 | + | |
| 18 | + These functions are collectively represented by a "keys" child node from the | |
| 19 | + parent MFD driver. See Documentation/devicetree/bindings/mfd/iqs62x.yaml for | |
| 20 | + further details and examples. Sensor hardware configuration (self-capacitive | |
| 21 | + vs. mutual-inductive, etc.) is selected based on the device's firmware. | |
| 22 | + | |
| 23 | +properties: | |
| 24 | + compatible: | |
| 25 | + enum: | |
| 26 | + - azoteq,iqs620a-keys | |
| 27 | + - azoteq,iqs621-keys | |
| 28 | + - azoteq,iqs622-keys | |
| 29 | + - azoteq,iqs624-keys | |
| 30 | + - azoteq,iqs625-keys | |
| 31 | + | |
| 32 | + linux,keycodes: | |
| 33 | + allOf: | |
| 34 | + - $ref: /schemas/types.yaml#/definitions/uint32-array | |
| 35 | + - minItems: 1 | |
| 36 | + maxItems: 16 | |
| 37 | + description: | | |
| 38 | + Specifies the numeric keycodes associated with each available touch or | |
| 39 | + proximity event according to the following table. An 'x' indicates the | |
| 40 | + event is supported for a given device. Specify 0 for unused events. | |
| 41 | + | |
| 42 | + ------------------------------------------------------------------------- | |
| 43 | + | # | Event | IQS620A | IQS621 | IQS622 | IQS624 | IQS625 | | |
| 44 | + ------------------------------------------------------------------------- | |
| 45 | + | 0 | CH0 Touch | x | x | x | x | x | | |
| 46 | + | | Antenna 1 Touch* | x | | | | | | |
| 47 | + ------------------------------------------------------------------------- | |
| 48 | + | 1 | CH0 Proximity | x | x | x | x | x | | |
| 49 | + | | Antenna 1 Prox.* | x | | | | | | |
| 50 | + ------------------------------------------------------------------------- | |
| 51 | + | 2 | CH1 Touch | x | x | x | x | x | | |
| 52 | + | | Ant. 1 Deep Touch* | x | | | | | | |
| 53 | + ------------------------------------------------------------------------- | |
| 54 | + | 3 | CH1 Proximity | x | x | x | x | x | | |
| 55 | + ------------------------------------------------------------------------- | |
| 56 | + | 4 | CH2 Touch | x | | | | | | |
| 57 | + ------------------------------------------------------------------------- | |
| 58 | + | 5 | CH2 Proximity | x | | | | | | |
| 59 | + | | Antenna 2 Prox.* | x | | | | | | |
| 60 | + ------------------------------------------------------------------------- | |
| 61 | + | 6 | Metal (+) Touch** | x | x | | | | | |
| 62 | + | | Ant. 2 Deep Touch* | x | | | | | | |
| 63 | + ------------------------------------------------------------------------- | |
| 64 | + | 7 | Metal (+) Prox.** | x | x | | | | | |
| 65 | + | | Antenna 2 Touch* | x | | | | | | |
| 66 | + ------------------------------------------------------------------------- | |
| 67 | + | 8 | Metal (-) Touch** | x | x | | | | | |
| 68 | + ------------------------------------------------------------------------- | |
| 69 | + | 9 | Metal (-) Prox.** | x | x | | | | | |
| 70 | + ------------------------------------------------------------------------- | |
| 71 | + | 10 | SAR Active*** | x | | x | | | | |
| 72 | + ------------------------------------------------------------------------- | |
| 73 | + | 11 | SAR Quick Rel.*** | x | | x | | | | |
| 74 | + ------------------------------------------------------------------------- | |
| 75 | + | 12 | SAR Movement*** | x | | x | | | | |
| 76 | + ------------------------------------------------------------------------- | |
| 77 | + | 13 | SAR Filter Halt*** | x | | x | | | | |
| 78 | + ------------------------------------------------------------------------- | |
| 79 | + | 14 | Wheel Up | | | | x | | | |
| 80 | + ------------------------------------------------------------------------- | |
| 81 | + | 15 | Wheel Down | | | | x | | | |
| 82 | + ------------------------------------------------------------------------- | |
| 83 | + * Two-channel SAR. Replaces CH0-2 plus metal touch and proximity events | |
| 84 | + if enabled via firmware. | |
| 85 | + ** "+" and "-" refer to the polarity of a channel's delta (LTA - counts), | |
| 86 | + where "LTA" is defined as the channel's long-term average. | |
| 87 | + *** One-channel SAR. Replaces CH0-2 touch and proximity events if enabled | |
| 88 | + via firmware. | |
| 89 | + | |
| 90 | +patternProperties: | |
| 91 | + "^hall-switch-(north|south)$": | |
| 92 | + type: object | |
| 93 | + description: | |
| 94 | + Represents north/south-field Hall-effect sensor touch or proximity | |
| 95 | + events. Note that north/south-field orientation is reversed on the | |
| 96 | + IQS620AXzCSR device due to its flip-chip package. | |
| 97 | + | |
| 98 | + properties: | |
| 99 | + linux,code: | |
| 100 | + $ref: /schemas/types.yaml#/definitions/uint32 | |
| 101 | + description: Numeric switch code associated with the event. | |
| 102 | + | |
| 103 | + azoteq,use-prox: | |
| 104 | + $ref: /schemas/types.yaml#/definitions/flag | |
| 105 | + description: | |
| 106 | + If present, specifies that Hall-effect sensor reporting should | |
| 107 | + use the device's wide-range proximity threshold instead of its | |
| 108 | + close-range touch threshold (default). | |
| 109 | + | |
| 110 | + required: | |
| 111 | + - linux,code | |
| 112 | + | |
| 113 | + additionalProperties: false | |
| 114 | + | |
| 115 | +if: | |
| 116 | + properties: | |
| 117 | + compatible: | |
| 118 | + contains: | |
| 119 | + enum: | |
| 120 | + - azoteq,iqs624-keys | |
| 121 | + - azoteq,iqs625-keys | |
| 122 | +then: | |
| 123 | + patternProperties: | |
| 124 | + "^hall-switch-(north|south)$": false | |
| 125 | + | |
| 126 | +required: | |
| 127 | + - compatible | |
| 128 | + - linux,keycodes | |
| 129 | + | |
| 130 | +additionalProperties: false | |
| 131 | + | |
| 132 | +... | |
| @@ -33,3 +33,6 @@ properties: · 32 unmodified lines | ||
| 33 | 33 | |
| 34 | 34 | required: |
| 35 | 35 | - compatible |
| 36 | +additionalProperties: false | |
| 37 | + | |
| 38 | +... | |
| @@ -1,28 +0,0 @@ | ||
| 1 | −STMicroelectronics STPMIC1 Onkey | |
| 2 | − | |
| 3 | −Required properties: | |
| 4 | − | |
| 5 | −- compatible = "st,stpmic1-onkey"; | |
| 6 | −- interrupts: interrupt line to use | |
| 7 | −- interrupt-names = "onkey-falling", "onkey-rising" | |
| 8 | − onkey-falling: happens when onkey is pressed; IT_PONKEY_F of pmic | |
| 9 | − onkey-rising: happens when onkey is released; IT_PONKEY_R of pmic | |
| 10 | − | |
| 11 | −Optional properties: | |
| 12 | − | |
| 13 | −- st,onkey-clear-cc-flag: onkey is able power on after an | |
| 14 | − over-current shutdown event. | |
| 15 | −- st,onkey-pu-inactive: onkey pull up is not active | |
| 16 | −- power-off-time-sec: Duration in seconds which the key should be kept | |
| 17 | − pressed for device to power off automatically (from 1 to 16 seconds). | |
| 18 | − see See Documentation/devicetree/bindings/input/input.yaml | |
| 19 | − | |
| 20 | −Example: | |
| 21 | − | |
| 22 | −onkey { | |
| 23 | − compatible = "st,stpmic1-onkey"; | |
| 24 | − interrupt-parent = <&pmic>; | |
| 25 | − interrupts = <IT_PONKEY_F 0>,<IT_PONKEY_R 1>; | |
| 26 | − interrupt-names = "onkey-falling", "onkey-rising"; | |
| 27 | − power-off-time-sec = <10>; | |
| 28 | −}; | |
| @@ -1,77 +0,0 @@ | ||
| 1 | −FocalTech EDT-FT5x06 Polytouch driver | |
| 2 | −===================================== | |
| 3 | − | |
| 4 | −There are 5 variants of the chip for various touch panel sizes | |
| 5 | −FT5206GE1 2.8" .. 3.8" | |
| 6 | −FT5306DE4 4.3" .. 7" | |
| 7 | −FT5406EE8 7" .. 8.9" | |
| 8 | −FT5506EEG 7" .. 8.9" | |
| 9 | −FT5726NEI 5.7” .. 11.6" | |
| 10 | − | |
| 11 | −The software interface is identical for all those chips, so that | |
| 12 | −currently there is no need for the driver to distinguish between the | |
| 13 | −different chips. Nevertheless distinct compatible strings are used so | |
| 14 | −that a distinction can be added if necessary without changing the DT | |
| 15 | −bindings. | |
| 16 | − | |
| 17 | − | |
| 18 | −Required properties: | |
| 19 | − - compatible: "edt,edt-ft5206" | |
| 20 | − or: "edt,edt-ft5306" | |
| 21 | − or: "edt,edt-ft5406" | |
| 22 | − or: "edt,edt-ft5506" | |
| 23 | − or: "evervision,ev-ft5726" | |
| 24 | − or: "focaltech,ft6236" | |
| 25 | − | |
| 26 | − - reg: I2C slave address of the chip (0x38) | |
| 27 | − - interrupts: interrupt specification for the touchdetect | |
| 28 | − interrupt | |
| 29 | − | |
| 30 | −Optional properties: | |
| 31 | − - reset-gpios: GPIO specification for the RESET input | |
| 32 | − - wake-gpios: GPIO specification for the WAKE input | |
| 33 | − - vcc-supply: Regulator that supplies the touchscreen | |
| 34 | − | |
| 35 | − - pinctrl-names: should be "default" | |
| 36 | − - pinctrl-0: a phandle pointing to the pin settings for the | |
| 37 | − control gpios | |
| 38 | − | |
| 39 | − - wakeup-source: If present the device will act as wakeup-source | |
| 40 | − | |
| 41 | − - threshold: allows setting the "click"-threshold in the range | |
| 42 | − from 0 to 80. | |
| 43 | − | |
| 44 | − - gain: allows setting the sensitivity in the range from 0 to | |
| 45 | − 31. Note that lower values indicate higher | |
| 46 | − sensitivity. | |
| 47 | − | |
| 48 | − - offset: allows setting the edge compensation in the range from | |
| 49 | − 0 to 31. | |
| 50 | − | |
| 51 | − - offset-x: Same as offset, but applies only to the horizontal position. | |
| 52 | − Range from 0 to 80, only supported by evervision,ev-ft5726 | |
| 53 | − devices. | |
| 54 | − | |
| 55 | − - offset-y: Same as offset, but applies only to the vertical position. | |
| 56 | − Range from 0 to 80, only supported by evervision,ev-ft5726 | |
| 57 | − devices. | |
| 58 | − | |
| 59 | − - touchscreen-size-x : See touchscreen.txt | |
| 60 | − - touchscreen-size-y : See touchscreen.txt | |
| 61 | − - touchscreen-fuzz-x : See touchscreen.txt | |
| 62 | − - touchscreen-fuzz-y : See touchscreen.txt | |
| 63 | − - touchscreen-inverted-x : See touchscreen.txt | |
| 64 | − - touchscreen-inverted-y : See touchscreen.txt | |
| 65 | − - touchscreen-swapped-x-y : See touchscreen.txt | |
| 66 | − | |
| 67 | −Example: | |
| 68 | − polytouch: edt-ft5x06@38 { | |
| 69 | − compatible = "edt,edt-ft5406", "edt,edt-ft5x06"; | |
| 70 | − reg = <0x38>; | |
| 71 | − pinctrl-names = "default"; | |
| 72 | − pinctrl-0 = <&edt_ft5x06_pins>; | |
| 73 | − interrupt-parent = <&gpio2>; | |
| 74 | − interrupts = <5 IRQ_TYPE_EDGE_FALLING>; | |
| 75 | − reset-gpios = <&gpio2 6 GPIO_ACTIVE_LOW>; | |
| 76 | − wake-gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>; | |
| 77 | − }; | |
| @@ -0,0 +1,125 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/input/touchscreen/edt-ft5x06.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: FocalTech EDT-FT5x06 Polytouch Bindings | |
| 8 | + | |
| 9 | +description: | | |
| 10 | + There are 5 variants of the chip for various touch panel sizes | |
| 11 | + FT5206GE1 2.8" .. 3.8" | |
| 12 | + FT5306DE4 4.3" .. 7" | |
| 13 | + FT5406EE8 7" .. 8.9" | |
| 14 | + FT5506EEG 7" .. 8.9" | |
| 15 | + FT5726NEI 5.7” .. 11.6" | |
| 16 | + | |
| 17 | +maintainers: | |
| 18 | + - Dmitry Torokhov <dmitry.torokhov@gmail.com> | |
| 19 | + | |
| 20 | +allOf: | |
| 21 | + - $ref: touchscreen.yaml# | |
| 22 | + - if: | |
| 23 | + properties: | |
| 24 | + compatible: | |
| 25 | + contains: | |
| 26 | + enum: | |
| 27 | + - evervision,ev-ft5726 | |
| 28 | + | |
| 29 | + then: | |
| 30 | + properties: | |
| 31 | + offset-x: true | |
| 32 | + offset-y: true | |
| 33 | + | |
| 34 | +properties: | |
| 35 | + compatible: | |
| 36 | + enum: | |
| 37 | + - edt,edt-ft5206 | |
| 38 | + - edt,edt-ft5306 | |
| 39 | + - edt,edt-ft5406 | |
| 40 | + - edt,edt-ft5506 | |
| 41 | + - evervision,ev-ft5726 | |
| 42 | + - focaltech,ft6236 | |
| 43 | + | |
| 44 | + reg: | |
| 45 | + const: 0x38 | |
| 46 | + | |
| 47 | + interrupts: | |
| 48 | + maxItems: 1 | |
| 49 | + | |
| 50 | + reset-gpios: | |
| 51 | + maxItems: 1 | |
| 52 | + | |
| 53 | + wake-gpios: | |
| 54 | + maxItems: 1 | |
| 55 | + | |
| 56 | + wakeup-source: true | |
| 57 | + | |
| 58 | + vcc-supply: | |
| 59 | + maxItems: 1 | |
| 60 | + | |
| 61 | + gain: | |
| 62 | + description: Allows setting the sensitivity in the range from 0 to 31. | |
| 63 | + Note that lower values indicate higher sensitivity. | |
| 64 | + allOf: | |
| 65 | + - $ref: /schemas/types.yaml#/definitions/uint32 | |
| 66 | + - minimum: 0 | |
| 67 | + - maximum: 31 | |
| 68 | + | |
| 69 | + offset: | |
| 70 | + description: Allows setting the edge compensation in the range from 0 to 31. | |
| 71 | + allOf: | |
| 72 | + - $ref: /schemas/types.yaml#/definitions/uint32 | |
| 73 | + - minimum: 0 | |
| 74 | + - maximum: 31 | |
| 75 | + | |
| 76 | + offset-x: | |
| 77 | + description: Same as offset, but applies only to the horizontal position. | |
| 78 | + Range from 0 to 80, only supported by evervision,ev-ft5726 devices. | |
| 79 | + allOf: | |
| 80 | + - $ref: /schemas/types.yaml#/definitions/uint32 | |
| 81 | + - minimum: 0 | |
| 82 | + - maximum: 80 | |
| 83 | + | |
| 84 | + offset-y: | |
| 85 | + description: Same as offset, but applies only to the vertical position. | |
| 86 | + Range from 0 to 80, only supported by evervision,ev-ft5726 devices. | |
| 87 | + allOf: | |
| 88 | + - $ref: /schemas/types.yaml#/definitions/uint32 | |
| 89 | + - minimum: 0 | |
| 90 | + - maximum: 80 | |
| 91 | + | |
| 92 | + touchscreen-size-x: true | |
| 93 | + touchscreen-size-y: true | |
| 94 | + touchscreen-fuzz-x: true | |
| 95 | + touchscreen-fuzz-y: true | |
| 96 | + touchscreen-inverted-x: true | |
| 97 | + touchscreen-inverted-y: true | |
| 98 | + touchscreen-swapped-x-y: true | |
| 99 | + interrupt-controller: true | |
| 100 | + | |
| 101 | +additionalProperties: false | |
| 102 | + | |
| 103 | +required: | |
| 104 | + - compatible | |
| 105 | + - reg | |
| 106 | + - interrupts | |
| 107 | + | |
| 108 | +examples: | |
| 109 | + - | | |
| 110 | + #include <dt-bindings/gpio/gpio.h> | |
| 111 | + #include <dt-bindings/interrupt-controller/arm-gic.h> | |
| 112 | + i2c@00000000 { | |
| 113 | + #address-cells = <1>; | |
| 114 | + #size-cells = <0>; | |
| 115 | + edt-ft5x06@38 { | |
| 116 | + compatible = "edt,edt-ft5406"; | |
| 117 | + reg = <0x38>; | |
| 118 | + interrupt-parent = <&gpio2>; | |
| 119 | + interrupts = <5 IRQ_TYPE_EDGE_FALLING>; | |
| 120 | + reset-gpios = <&gpio2 6 GPIO_ACTIVE_LOW>; | |
| 121 | + wake-gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>; | |
| 122 | + }; | |
| 123 | + }; | |
| 124 | + | |
| 125 | +... | |
| @@ -21,6 +21,8 @@ properties: · 20 unmodified lines | ||
| 21 | 21 | - goodix,gt911 |
| 22 | 22 | - goodix,gt9110 |
| 23 | 23 | - goodix,gt912 |
| 24 | + - goodix,gt9147 | |
| 25 | + - goodix,gt917s | |
| 24 | 26 | - goodix,gt927 |
| 25 | 27 | - goodix,gt9271 |
| 26 | 28 | - goodix,gt928 |
| @@ -0,0 +1,45 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/interconnect/qcom,bcm-voter.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Qualcomm BCM-Voter Interconnect | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Georgi Djakov <georgi.djakov@linaro.org> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + The Bus Clock Manager (BCM) is a dedicated hardware accelerator that manages | |
| 14 | + shared system resources by aggregating requests from multiple Resource State | |
| 15 | + Coordinators (RSC). Interconnect providers are able to vote for aggregated | |
| 16 | + thresholds values from consumers by communicating through their respective | |
| 17 | + RSCs. | |
| 18 | + | |
| 19 | +properties: | |
| 20 | + compatible: | |
| 21 | + enum: | |
| 22 | + - qcom,bcm-voter | |
| 23 | + | |
| 24 | +required: | |
| 25 | + - compatible | |
| 26 | + | |
| 27 | +additionalProperties: false | |
| 28 | + | |
| 29 | +examples: | |
| 30 | + # Example 1: apps bcm_voter on SDM845 SoC should be defined inside &apps_rsc node | |
| 31 | + # as defined in Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt | |
| 32 | + - | | |
| 33 | + | |
| 34 | + apps_bcm_voter: bcm_voter { | |
| 35 | + compatible = "qcom,bcm-voter"; | |
| 36 | + }; | |
| 37 | + | |
| 38 | + # Example 2: disp bcm_voter on SDM845 should be defined inside &disp_rsc node | |
| 39 | + # as defined in Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt | |
| 40 | + - | | |
| 41 | + | |
| 42 | + disp_bcm_voter: bcm_voter { | |
| 43 | + compatible = "qcom,bcm-voter"; | |
| 44 | + }; | |
| 45 | +... | |
| @@ -0,0 +1,62 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/interconnect/qcom,osm-l3.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Qualcomm Operating State Manager (OSM) L3 Interconnect Provider | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Sibi Sankar <sibis@codeaurora.org> | |
| 11 | + | |
| 12 | +description: | |
| 13 | + L3 cache bandwidth requirements on Qualcomm SoCs is serviced by the OSM. | |
| 14 | + The OSM L3 interconnect provider aggregates the L3 bandwidth requests | |
| 15 | + from CPU/GPU and relays it to the OSM. | |
| 16 | + | |
| 17 | +properties: | |
| 18 | + compatible: | |
| 19 | + enum: | |
| 20 | + - qcom,sc7180-osm-l3 | |
| 21 | + - qcom,sdm845-osm-l3 | |
| 22 | + | |
| 23 | + reg: | |
| 24 | + maxItems: 1 | |
| 25 | + | |
| 26 | + clocks: | |
| 27 | + items: | |
| 28 | + - description: xo clock | |
| 29 | + - description: alternate clock | |
| 30 | + | |
| 31 | + clock-names: | |
| 32 | + items: | |
| 33 | + - const: xo | |
| 34 | + - const: alternate | |
| 35 | + | |
| 36 | + '#interconnect-cells': | |
| 37 | + const: 1 | |
| 38 | + | |
| 39 | +required: | |
| 40 | + - compatible | |
| 41 | + - reg | |
| 42 | + - clocks | |
| 43 | + - clock-names | |
| 44 | + - '#interconnect-cells' | |
| 45 | + | |
| 46 | +additionalProperties: false | |
| 47 | + | |
| 48 | +examples: | |
| 49 | + - | | |
| 50 | + | |
| 51 | + #define GPLL0 165 | |
| 52 | + #define RPMH_CXO_CLK 0 | |
| 53 | + | |
| 54 | + osm_l3: interconnect@17d41000 { | |
| 55 | + compatible = "qcom,sdm845-osm-l3"; | |
| 56 | + reg = <0x17d41000 0x1400>; | |
| 57 | + | |
| 58 | + clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>; | |
| 59 | + clock-names = "xo", "alternate"; | |
| 60 | + | |
| 61 | + #interconnect-cells = <1>; | |
| 62 | + }; | |
| @@ -0,0 +1,85 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/interconnect/qcom,sc7180.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Qualcomm SC7180 Network-On-Chip Interconnect | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Odelu Kukatla <okukatla@codeaurora.org> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + SC7180 interconnect providers support system bandwidth requirements through | |
| 14 | + RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is | |
| 15 | + able to communicate with the BCM through the Resource State Coordinator (RSC) | |
| 16 | + associated with each execution environment. Provider nodes must point to at | |
| 17 | + least one RPMh device child node pertaining to their RSC and each provider | |
| 18 | + can map to multiple RPMh resources. | |
| 19 | + | |
| 20 | +properties: | |
| 21 | + reg: | |
| 22 | + maxItems: 1 | |
| 23 | + | |
| 24 | + compatible: | |
| 25 | + enum: | |
| 26 | + - qcom,sc7180-aggre1-noc | |
| 27 | + - qcom,sc7180-aggre2-noc | |
| 28 | + - qcom,sc7180-camnoc-virt | |
| 29 | + - qcom,sc7180-compute-noc | |
| 30 | + - qcom,sc7180-config-noc | |
| 31 | + - qcom,sc7180-dc-noc | |
| 32 | + - qcom,sc7180-gem-noc | |
| 33 | + - qcom,sc7180-ipa-virt | |
| 34 | + - qcom,sc7180-mc-virt | |
| 35 | + - qcom,sc7180-mmss-noc | |
| 36 | + - qcom,sc7180-npu-noc | |
| 37 | + - qcom,sc7180-qup-virt | |
| 38 | + - qcom,sc7180-system-noc | |
| 39 | + | |
| 40 | + '#interconnect-cells': | |
| 41 | + const: 1 | |
| 42 | + | |
| 43 | + qcom,bcm-voters: | |
| 44 | + $ref: /schemas/types.yaml#/definitions/phandle-array | |
| 45 | + description: | | |
| 46 | + List of phandles to qcom,bcm-voter nodes that are required by | |
| 47 | + this interconnect to send RPMh commands. | |
| 48 | + | |
| 49 | + qcom,bcm-voter-names: | |
| 50 | + $ref: /schemas/types.yaml#/definitions/string-array | |
| 51 | + description: | | |
| 52 | + Names for each of the qcom,bcm-voters specified. | |
| 53 | + | |
| 54 | +required: | |
| 55 | + - compatible | |
| 56 | + - reg | |
| 57 | + - '#interconnect-cells' | |
| 58 | + - qcom,bcm-voters | |
| 59 | + | |
| 60 | +additionalProperties: false | |
| 61 | + | |
| 62 | +examples: | |
| 63 | + - | | |
| 64 | + #include <dt-bindings/interconnect/qcom,sc7180.h> | |
| 65 | + | |
| 66 | + config_noc: interconnect@1500000 { | |
| 67 | + compatible = "qcom,sc7180-config-noc"; | |
| 68 | + reg = <0 0x01500000 0 0x28000>; | |
| 69 | + #interconnect-cells = <1>; | |
| 70 | + qcom,bcm-voters = <&apps_bcm_voter>; | |
| 71 | + }; | |
| 72 | + | |
| 73 | + system_noc: interconnect@1620000 { | |
| 74 | + compatible = "qcom,sc7180-system-noc"; | |
| 75 | + reg = <0 0x01620000 0 0x17080>; | |
| 76 | + #interconnect-cells = <1>; | |
| 77 | + qcom,bcm-voters = <&apps_bcm_voter>; | |
| 78 | + }; | |
| 79 | + | |
| 80 | + mmss_noc: interconnect@1740000 { | |
| 81 | + compatible = "qcom,sc7180-mmss-noc"; | |
| 82 | + reg = <0 0x01740000 0 0x1c100>; | |
| 83 | + #interconnect-cells = <1>; | |
| 84 | + qcom,bcm-voters = <&apps_bcm_voter>; | |
| 85 | + }; | |
| @@ -1,24 +0,0 @@ | ||
| 1 | −Qualcomm SDM845 Network-On-Chip interconnect driver binding | |
| 2 | −----------------------------------------------------------- | |
| 3 | − | |
| 4 | −SDM845 interconnect providers support system bandwidth requirements through | |
| 5 | −RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is | |
| 6 | −able to communicate with the BCM through the Resource State Coordinator (RSC) | |
| 7 | −associated with each execution environment. Provider nodes must reside within | |
| 8 | −an RPMh device node pertaining to their RSC and each provider maps to a single | |
| 9 | −RPMh resource. | |
| 10 | − | |
| 11 | −Required properties : | |
| 12 | −- compatible : shall contain only one of the following: | |
| 13 | − "qcom,sdm845-rsc-hlos" | |
| 14 | −- #interconnect-cells : should contain 1 | |
| 15 | − | |
| 16 | −Examples: | |
| 17 | − | |
| 18 | −apps_rsc: rsc { | |
| 19 | − rsc_hlos: interconnect { | |
| 20 | − compatible = "qcom,sdm845-rsc-hlos"; | |
| 21 | − #interconnect-cells = <1>; | |
| 22 | − }; | |
| 23 | −}; | |
| 24 | − | |
| @@ -0,0 +1,74 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/interconnect/qcom,sdm845.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Qualcomm SDM845 Network-On-Chip Interconnect | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Georgi Djakov <georgi.djakov@linaro.org> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + SDM845 interconnect providers support system bandwidth requirements through | |
| 14 | + RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is | |
| 15 | + able to communicate with the BCM through the Resource State Coordinator (RSC) | |
| 16 | + associated with each execution environment. Provider nodes must point to at | |
| 17 | + least one RPMh device child node pertaining to their RSC and each provider | |
| 18 | + can map to multiple RPMh resources. | |
| 19 | + | |
| 20 | +properties: | |
| 21 | + reg: | |
| 22 | + maxItems: 1 | |
| 23 | + | |
| 24 | + compatible: | |
| 25 | + enum: | |
| 26 | + - qcom,sdm845-aggre1-noc | |
| 27 | + - qcom,sdm845-aggre2-noc | |
| 28 | + - qcom,sdm845-config-noc | |
| 29 | + - qcom,sdm845-dc-noc | |
| 30 | + - qcom,sdm845-gladiator-noc | |
| 31 | + - qcom,sdm845-mem-noc | |
| 32 | + - qcom,sdm845-mmss-noc | |
| 33 | + - qcom,sdm845-system-noc | |
| 34 | + | |
| 35 | + '#interconnect-cells': | |
| 36 | + const: 1 | |
| 37 | + | |
| 38 | + qcom,bcm-voters: | |
| 39 | + $ref: /schemas/types.yaml#/definitions/phandle-array | |
| 40 | + description: | | |
| 41 | + List of phandles to qcom,bcm-voter nodes that are required by | |
| 42 | + this interconnect to send RPMh commands. | |
| 43 | + | |
| 44 | + qcom,bcm-voter-names: | |
| 45 | + $ref: /schemas/types.yaml#/definitions/string-array | |
| 46 | + description: | | |
| 47 | + Names for each of the qcom,bcm-voters specified. | |
| 48 | + | |
| 49 | +required: | |
| 50 | + - compatible | |
| 51 | + - reg | |
| 52 | + - '#interconnect-cells' | |
| 53 | + - qcom,bcm-voters | |
| 54 | + | |
| 55 | +additionalProperties: false | |
| 56 | + | |
| 57 | +examples: | |
| 58 | + - | | |
| 59 | + #include <dt-bindings/interconnect/qcom,sdm845.h> | |
| 60 | + | |
| 61 | + mem_noc: interconnect@1380000 { | |
| 62 | + compatible = "qcom,sdm845-mem-noc"; | |
| 63 | + reg = <0 0x01380000 0 0x27200>; | |
| 64 | + #interconnect-cells = <1>; | |
| 65 | + qcom,bcm-voters = <&apps_bcm_voter>; | |
| 66 | + }; | |
| 67 | + | |
| 68 | + mmss_noc: interconnect@1740000 { | |
| 69 | + compatible = "qcom,sdm845-mmss-noc"; | |
| 70 | + reg = <0 0x01740000 0 0x1c1000>; | |
| 71 | + #interconnect-cells = <1>; | |
| 72 | + qcom,bcm-voter-names = "apps", "disp"; | |
| 73 | + qcom,bcm-voters = <&apps_bcm_voter>, <&disp_bcm_voter>; | |
| 74 | + }; | |
| @@ -44,6 +44,8 @@ required: · 43 unmodified lines | ||
| 44 | 44 | - interrupt-controller |
| 45 | 45 | - '#interrupt-cells' |
| 46 | 46 | |
| 47 | +additionalProperties: false | |
| 48 | + | |
| 47 | 49 | examples: |
| 48 | 50 | - | |
| 49 | 51 | intcon: interrupt-controller@c8003000 { |
| @@ -0,0 +1,59 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: "http://devicetree.org/schemas/interrupt-controller/loongson,htpic.yaml#" | |
| 5 | +$schema: "http://devicetree.org/meta-schemas/core.yaml#" | |
| 6 | + | |
| 7 | +title: Loongson-3 HyperTransport Interrupt Controller | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Jiaxun Yang <jiaxun.yang@flygoat.com> | |
| 11 | + | |
| 12 | +allOf: | |
| 13 | + - $ref: /schemas/interrupt-controller.yaml# | |
| 14 | + | |
| 15 | +description: | | |
| 16 | + This interrupt controller is found in the Loongson-3 family of chips to transmit | |
| 17 | + interrupts from PCH PIC connected on HyperTransport bus. | |
| 18 | + | |
| 19 | +properties: | |
| 20 | + compatible: | |
| 21 | + const: loongson,htpic-1.0 | |
| 22 | + | |
| 23 | + reg: | |
| 24 | + maxItems: 1 | |
| 25 | + | |
| 26 | + interrupts: | |
| 27 | + minItems: 1 | |
| 28 | + maxItems: 4 | |
| 29 | + description: | | |
| 30 | + Four parent interrupts that receive chained interrupts. | |
| 31 | + | |
| 32 | + interrupt-controller: true | |
| 33 | + | |
| 34 | + '#interrupt-cells': | |
| 35 | + const: 1 | |
| 36 | + | |
| 37 | +required: | |
| 38 | + - compatible | |
| 39 | + - reg | |
| 40 | + - interrupts | |
| 41 | + - interrupt-controller | |
| 42 | + - '#interrupt-cells' | |
| 43 | + | |
| 44 | +examples: | |
| 45 | + - | | |
| 46 | + #include <dt-bindings/interrupt-controller/irq.h> | |
| 47 | + htintc: interrupt-controller@1fb000080 { | |
| 48 | + compatible = "loongson,htintc-1.0"; | |
| 49 | + reg = <0xfb000080 0x40>; | |
| 50 | + interrupt-controller; | |
| 51 | + #interrupt-cells = <1>; | |
| 52 | + | |
| 53 | + interrupt-parent = <&liointc>; | |
| 54 | + interrupts = <24 IRQ_TYPE_LEVEL_HIGH>, | |
| 55 | + <25 IRQ_TYPE_LEVEL_HIGH>, | |
| 56 | + <26 IRQ_TYPE_LEVEL_HIGH>, | |
| 57 | + <27 IRQ_TYPE_LEVEL_HIGH>; | |
| 58 | + }; | |
| 59 | +... | |
| @@ -0,0 +1,93 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: "http://devicetree.org/schemas/interrupt-controller/loongson,liointc.yaml#" | |
| 5 | +$schema: "http://devicetree.org/meta-schemas/core.yaml#" | |
| 6 | + | |
| 7 | +title: Loongson Local I/O Interrupt Controller | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Jiaxun Yang <jiaxun.yang@flygoat.com> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + This interrupt controller is found in the Loongson-3 family of chips as the primary | |
| 14 | + package interrupt controller which can route local I/O interrupt to interrupt lines | |
| 15 | + of cores. | |
| 16 | + | |
| 17 | +allOf: | |
| 18 | + - $ref: /schemas/interrupt-controller.yaml# | |
| 19 | + | |
| 20 | +properties: | |
| 21 | + compatible: | |
| 22 | + oneOf: | |
| 23 | + - const: loongson,liointc-1.0 | |
| 24 | + - const: loongson,liointc-1.0a | |
| 25 | + | |
| 26 | + reg: | |
| 27 | + maxItems: 1 | |
| 28 | + | |
| 29 | + interrupt-controller: true | |
| 30 | + | |
| 31 | + interrupts: | |
| 32 | + description: | |
| 33 | + Interrupt source of the CPU interrupts. | |
| 34 | + minItems: 1 | |
| 35 | + maxItems: 4 | |
| 36 | + | |
| 37 | + interrupt-names: | |
| 38 | + description: List of names for the parent interrupts. | |
| 39 | + items: | |
| 40 | + - const: int0 | |
| 41 | + - const: int1 | |
| 42 | + - const: int2 | |
| 43 | + - const: int3 | |
| 44 | + minItems: 1 | |
| 45 | + maxItems: 4 | |
| 46 | + | |
| 47 | + '#interrupt-cells': | |
| 48 | + const: 2 | |
| 49 | + | |
| 50 | + 'loongson,parent_int_map': | |
| 51 | + description: | | |
| 52 | + This property points how the children interrupts will be mapped into CPU | |
| 53 | + interrupt lines. Each cell refers to a parent interrupt line from 0 to 3 | |
| 54 | + and each bit in the cell refers to a children interrupt fron 0 to 31. | |
| 55 | + If a CPU interrupt line didn't connected with liointc, then keep it's | |
| 56 | + cell with zero. | |
| 57 | + allOf: | |
| 58 | + - $ref: /schemas/types.yaml#/definitions/uint32-array | |
| 59 | + - items: | |
| 60 | + minItems: 4 | |
| 61 | + maxItems: 4 | |
| 62 | + | |
| 63 | + | |
| 64 | +required: | |
| 65 | + - compatible | |
| 66 | + - reg | |
| 67 | + - interrupts | |
| 68 | + - interrupt-controller | |
| 69 | + - '#interrupt-cells' | |
| 70 | + - 'loongson,parent_int_map' | |
| 71 | + | |
| 72 | + | |
| 73 | +examples: | |
| 74 | + - | | |
| 75 | + iointc: interrupt-controller@3ff01400 { | |
| 76 | + compatible = "loongson,liointc-1.0"; | |
| 77 | + reg = <0x3ff01400 0x64>; | |
| 78 | + | |
| 79 | + interrupt-controller; | |
| 80 | + #interrupt-cells = <2>; | |
| 81 | + | |
| 82 | + interrupt-parent = <&cpuintc>; | |
| 83 | + interrupts = <2>, <3>; | |
| 84 | + interrupt-names = "int0", "int1"; | |
| 85 | + | |
| 86 | + loongson,parent_int_map = <0xf0ffffff>, /* int0 */ | |
| 87 | + <0x0f000000>, /* int1 */ | |
| 88 | + <0x00000000>, /* int2 */ | |
| 89 | + <0x00000000>; /* int3 */ | |
| 90 | + | |
| 91 | + }; | |
| 92 | + | |
| 93 | +... | |
| @@ -98,7 +98,7 @@ Example · 97 unmodified lines | ||
| 98 | 98 | }; |
| 99 | 99 | |
| 100 | 100 | msi_c: msi-controller@c { |
| 101 | − reg = <0xb 0xf00>; | |
| 101 | + reg = <0xc 0xf00>; | |
| 102 | 102 | compatible = "vendor-b,another-controller"; |
| 103 | 103 | msi-controller; |
| 104 | 104 | /* Each device has some unique ID */ |
| @@ -1,32 +0,0 @@ | ||
| 1 | −UniPhier AIDET | |
| 2 | − | |
| 3 | −UniPhier AIDET (ARM Interrupt Detector) is an add-on block for ARM GIC (Generic | |
| 4 | −Interrupt Controller). GIC itself can handle only high level and rising edge | |
| 5 | −interrupts. The AIDET provides logic inverter to support low level and falling | |
| 6 | −edge interrupts. | |
| 7 | − | |
| 8 | −Required properties: | |
| 9 | −- compatible: Should be one of the following: | |
| 10 | − "socionext,uniphier-ld4-aidet" - for LD4 SoC | |
| 11 | − "socionext,uniphier-pro4-aidet" - for Pro4 SoC | |
| 12 | − "socionext,uniphier-sld8-aidet" - for sLD8 SoC | |
| 13 | − "socionext,uniphier-pro5-aidet" - for Pro5 SoC | |
| 14 | − "socionext,uniphier-pxs2-aidet" - for PXs2/LD6b SoC | |
| 15 | − "socionext,uniphier-ld11-aidet" - for LD11 SoC | |
| 16 | − "socionext,uniphier-ld20-aidet" - for LD20 SoC | |
| 17 | − "socionext,uniphier-pxs3-aidet" - for PXs3 SoC | |
| 18 | −- reg: Specifies offset and length of the register set for the device. | |
| 19 | −- interrupt-controller: Identifies the node as an interrupt controller | |
| 20 | −- #interrupt-cells : Specifies the number of cells needed to encode an interrupt | |
| 21 | − source. The value should be 2. The first cell defines the interrupt number | |
| 22 | − (corresponds to the SPI interrupt number of GIC). The second cell specifies | |
| 23 | − the trigger type as defined in interrupts.txt in this directory. | |
| 24 | − | |
| 25 | −Example: | |
| 26 | − | |
| 27 | − aidet: aidet@5fc20000 { | |
| 28 | − compatible = "socionext,uniphier-pro4-aidet"; | |
| 29 | − reg = <0x5fc20000 0x200>; | |
| 30 | − interrupt-controller; | |
| 31 | − #interrupt-cells = <2>; | |
| 32 | − }; | |
| @@ -0,0 +1,61 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/interrupt-controller/socionext,uniphier-aidet.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: UniPhier AIDET | |
| 8 | + | |
| 9 | +description: | | |
| 10 | + UniPhier AIDET (ARM Interrupt Detector) is an add-on block for ARM GIC | |
| 11 | + (Generic Interrupt Controller). GIC itself can handle only high level and | |
| 12 | + rising edge interrupts. The AIDET provides logic inverter to support low | |
| 13 | + level and falling edge interrupts. | |
| 14 | + | |
| 15 | +maintainers: | |
| 16 | + - Masahiro Yamada <yamada.masahiro@socionext.com> | |
| 17 | + | |
| 18 | +allOf: | |
| 19 | + - $ref: /schemas/interrupt-controller.yaml# | |
| 20 | + | |
| 21 | +properties: | |
| 22 | + compatible: | |
| 23 | + enum: | |
| 24 | + - socionext,uniphier-ld4-aidet | |
| 25 | + - socionext,uniphier-pro4-aidet | |
| 26 | + - socionext,uniphier-sld8-aidet | |
| 27 | + - socionext,uniphier-pro5-aidet | |
| 28 | + - socionext,uniphier-pxs2-aidet | |
| 29 | + - socionext,uniphier-ld6b-aidet | |
| 30 | + - socionext,uniphier-ld11-aidet | |
| 31 | + - socionext,uniphier-ld20-aidet | |
| 32 | + - socionext,uniphier-pxs3-aidet | |
| 33 | + | |
| 34 | + reg: | |
| 35 | + maxItems: 1 | |
| 36 | + | |
| 37 | + interrupt-controller: true | |
| 38 | + | |
| 39 | + '#interrupt-cells': | |
| 40 | + description: | | |
| 41 | + The first cell defines the interrupt number (corresponds to the SPI | |
| 42 | + interrupt number of GIC). The second cell specifies the trigger type as | |
| 43 | + defined in interrupts.txt in this directory. | |
| 44 | + const: 2 | |
| 45 | + | |
| 46 | +required: | |
| 47 | + - compatible | |
| 48 | + - reg | |
| 49 | + - interrupt-controller | |
| 50 | + - '#interrupt-cells' | |
| 51 | + | |
| 52 | +additionalProperties: false | |
| 53 | + | |
| 54 | +examples: | |
| 55 | + - | | |
| 56 | + interrupt-controller@5fc20000 { | |
| 57 | + compatible = "socionext,uniphier-pro4-aidet"; | |
| 58 | + reg = <0x5fc20000 0x200>; | |
| 59 | + interrupt-controller; | |
| 60 | + #interrupt-cells = <2>; | |
| 61 | + }; | |
| @@ -80,6 +80,8 @@ required: · 79 unmodified lines | ||
| 80 | 80 | - clock-names |
| 81 | 81 | - "#iommu-cells" |
| 82 | 82 | |
| 83 | +additionalProperties: false | |
| 84 | + | |
| 83 | 85 | examples: |
| 84 | 86 | - | |
| 85 | 87 | #include <dt-bindings/clock/exynos5250.h> |
| @@ -1,9 +1,10 @@ | ||
| 1 | −* Aspeed KCS (Keyboard Controller Style) IPMI interface | |
| 1 | +# Aspeed KCS (Keyboard Controller Style) IPMI interface | |
| 2 | 2 | |
| 3 | 3 | The Aspeed SOCs (AST2400 and AST2500) are commonly used as BMCs |
| 4 | 4 | (Baseboard Management Controllers) and the KCS interface can be |
| 5 | 5 | used to perform in-band IPMI communication with their host. |
| 6 | 6 | |
| 7 | +## v1 | |
| 7 | 8 | Required properties: |
| 8 | 9 | - compatible : should be one of |
| 9 | 10 | "aspeed,ast2400-kcs-bmc" |
| @@ -12,14 +13,21 @@ Required properties: · 2 unmodified lines | ||
| 12 | 13 | - kcs_chan : The LPC channel number in the controller |
| 13 | 14 | - kcs_addr : The host CPU IO map address |
| 14 | 15 | |
| 16 | +## v2 | |
| 17 | +Required properties: | |
| 18 | +- compatible : should be one of | |
| 19 | + "aspeed,ast2400-kcs-bmc-v2" | |
| 20 | + "aspeed,ast2500-kcs-bmc-v2" | |
| 21 | +- reg : The address and size of the IDR, ODR and STR registers | |
| 22 | +- interrupts : interrupt generated by the controller | |
| 23 | +- aspeed,lpc-io-reg : The host CPU LPC IO address for the device | |
| 15 | 24 | |
| 16 | 25 | Example: |
| 17 | 26 | |
| 18 | − kcs3: kcs3@0 { | |
| 19 | − compatible = "aspeed,ast2500-kcs-bmc"; | |
| 20 | − reg = <0x0 0x80>; | |
| 27 | + kcs3: kcs@24 { | |
| 28 | + compatible = "aspeed,ast2500-kcs-bmc-v2"; | |
| 29 | + reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>; | |
| 30 | + aspeed,lpc-reg = <0xca2>; | |
| 21 | 31 | interrupts = <8>; |
| 22 | − kcs_chan = <3>; | |
| 23 | − kcs_addr = <0xCA2>; | |
| 24 | 32 | status = "okay"; |
| 25 | 33 | }; |
| @@ -167,13 +167,13 @@ examples: · 166 unmodified lines | ||
| 167 | 167 | led-controller { |
| 168 | 168 | compatible = "gpio-leds"; |
| 169 | 169 | |
| 170 | − led0 { | |
| 170 | + led-0 { | |
| 171 | 171 | function = LED_FUNCTION_STATUS; |
| 172 | 172 | linux,default-trigger = "heartbeat"; |
| 173 | 173 | gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>; |
| 174 | 174 | }; |
| 175 | 175 | |
| 176 | − led1 { | |
| 176 | + led-1 { | |
| 177 | 177 | function = LED_FUNCTION_USB; |
| 178 | 178 | gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>; |
| 179 | 179 | trigger-sources = <&ohci_port1>, <&ehci_port1>; |
| @@ -49,3 +49,6 @@ required: · 48 unmodified lines | ||
| 49 | 49 | - compatible |
| 50 | 50 | - "#address-cells" |
| 51 | 51 | - "#size-cells" |
| 52 | +additionalProperties: false | |
| 53 | + | |
| 54 | +... | |
| @@ -50,3 +50,6 @@ patternProperties: · 49 unmodified lines | ||
| 50 | 50 | |
| 51 | 51 | required: |
| 52 | 52 | - compatible |
| 53 | +additionalProperties: false | |
| 54 | + | |
| 55 | +... | |
| @@ -0,0 +1,80 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0 | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/mailbox/allwinner,sun6i-a31-msgbox.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Allwinner sunxi Message Box | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Samuel Holland <samuel@sholland.org> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + The hardware message box on sun6i, sun8i, sun9i, and sun50i SoCs is a | |
| 14 | + two-user mailbox controller containing 8 unidirectional FIFOs. An interrupt | |
| 15 | + is raised for received messages, but software must poll to know when a | |
| 16 | + transmitted message has been acknowledged by the remote user. Each FIFO can | |
| 17 | + hold four 32-bit messages; when a FIFO is full, clients must wait before | |
| 18 | + attempting more transmissions. | |
| 19 | + | |
| 20 | + Refer to ./mailbox.txt for generic information about mailbox device-tree | |
| 21 | + bindings. | |
| 22 | + | |
| 23 | +properties: | |
| 24 | + compatible: | |
| 25 | + oneOf: | |
| 26 | + - items: | |
| 27 | + - enum: | |
| 28 | + - allwinner,sun8i-a83t-msgbox | |
| 29 | + - allwinner,sun8i-h3-msgbox | |
| 30 | + - allwinner,sun9i-a80-msgbox | |
| 31 | + - allwinner,sun50i-a64-msgbox | |
| 32 | + - allwinner,sun50i-h6-msgbox | |
| 33 | + - const: allwinner,sun6i-a31-msgbox | |
| 34 | + - const: allwinner,sun6i-a31-msgbox | |
| 35 | + | |
| 36 | + reg: | |
| 37 | + maxItems: 1 | |
| 38 | + | |
| 39 | + clocks: | |
| 40 | + maxItems: 1 | |
| 41 | + description: bus clock | |
| 42 | + | |
| 43 | + resets: | |
| 44 | + maxItems: 1 | |
| 45 | + description: bus reset | |
| 46 | + | |
| 47 | + interrupts: | |
| 48 | + maxItems: 1 | |
| 49 | + | |
| 50 | + '#mbox-cells': | |
| 51 | + const: 1 | |
| 52 | + description: first cell is the channel number (0-7) | |
| 53 | + | |
| 54 | +required: | |
| 55 | + - compatible | |
| 56 | + - reg | |
| 57 | + - clocks | |
| 58 | + - resets | |
| 59 | + - interrupts | |
| 60 | + - '#mbox-cells' | |
| 61 | + | |
| 62 | +additionalProperties: false | |
| 63 | + | |
| 64 | +examples: | |
| 65 | + - | | |
| 66 | + #include <dt-bindings/clock/sun8i-h3-ccu.h> | |
| 67 | + #include <dt-bindings/interrupt-controller/arm-gic.h> | |
| 68 | + #include <dt-bindings/reset/sun8i-h3-ccu.h> | |
| 69 | + | |
| 70 | + msgbox: mailbox@1c17000 { | |
| 71 | + compatible = "allwinner,sun8i-h3-msgbox", | |
| 72 | + "allwinner,sun6i-a31-msgbox"; | |
| 73 | + reg = <0x01c17000 0x1000>; | |
| 74 | + clocks = <&ccu CLK_BUS_MSGBOX>; | |
| 75 | + resets = <&ccu RST_BUS_MSGBOX>; | |
| 76 | + interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; | |
| 77 | + #mbox-cells = <1>; | |
| 78 | + }; | |
| 79 | + | |
| 80 | +... | |
| @@ -41,6 +41,8 @@ required: · 40 unmodified lines | ||
| 41 | 41 | - interrupts |
| 42 | 42 | - "#mbox-cells" |
| 43 | 43 | |
| 44 | +additionalProperties: false | |
| 45 | + | |
| 44 | 46 | examples: |
| 45 | 47 | - | |
| 46 | 48 | mailbox@c883c404 { |
| @@ -23,6 +23,8 @@ Required properties: · 22 unmodified lines | ||
| 23 | 23 | be included together with SoC specific compatible. |
| 24 | 24 | There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu" |
| 25 | 25 | compatible to support it. |
| 26 | + To communicate with i.MX8 SCU, "fsl,imx8-mu-scu" could be | |
| 27 | + used for fast IPC | |
| 26 | 28 | - reg : Should contain the registers location and length |
| 27 | 29 | - interrupts : Interrupt number. The interrupt specifier format depends |
| 28 | 30 | on the interrupt controller parent. |
| @@ -14,13 +14,11 @@ Required properties: · 13 unmodified lines | ||
| 14 | 14 | - interrupts: The interrupt signal from the GCE block |
| 15 | 15 | - clock: Clocks according to the common clock binding |
| 16 | 16 | - clock-names: Must be "gce" to stand for GCE clock |
| 17 | −- #mbox-cells: Should be 3. | |
| 18 | − <&phandle channel priority atomic_exec> | |
| 17 | +- #mbox-cells: Should be 2. | |
| 18 | + <&phandle channel priority> | |
| 19 | 19 | phandle: Label name of a gce node. |
| 20 | 20 | channel: Channel of mailbox. Be equal to the thread id of GCE. |
| 21 | 21 | priority: Priority of GCE thread. |
| 22 | − atomic_exec: GCE processing continuous packets of commands in atomic | |
| 23 | − way. | |
| 24 | 22 | |
| 25 | 23 | Required properties for a client device: |
| 26 | 24 | - mboxes: Client use mailbox to communicate with GCE, it should have this |
| @@ -54,8 +52,8 @@ Example for a client device: · 27 unmodified lines | ||
| 54 | 52 | |
| 55 | 53 | mmsys: clock-controller@14000000 { |
| 56 | 54 | compatible = "mediatek,mt8173-mmsys"; |
| 57 | − mboxes = <&gce 0 CMDQ_THR_PRIO_LOWEST 1>, | |
| 58 | − <&gce 1 CMDQ_THR_PRIO_LOWEST 1>; | |
| 55 | + mboxes = <&gce 0 CMDQ_THR_PRIO_LOWEST>, | |
| 56 | + <&gce 1 CMDQ_THR_PRIO_LOWEST>; | |
| 59 | 57 | mutex-event-eof = <CMDQ_EVENT_MUTEX0_STREAM_EOF |
| 60 | 58 | CMDQ_EVENT_MUTEX1_STREAM_EOF>; |
| 61 | 59 | mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x3000 0x1000>, |
| @@ -0,0 +1,70 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/media/allwinner,sun8i-a83t-de2-rotate.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Allwinner A83T DE2 Rotate Device Tree Bindings | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Jernej Skrabec <jernej.skrabec@siol.net> | |
| 11 | + - Chen-Yu Tsai <wens@csie.org> | |
| 12 | + - Maxime Ripard <mripard@kernel.org> | |
| 13 | + | |
| 14 | +description: |- | |
| 15 | + The Allwinner A83T and A64 have a rotation core used for | |
| 16 | + rotating and flipping images. | |
| 17 | + | |
| 18 | +properties: | |
| 19 | + compatible: | |
| 20 | + oneOf: | |
| 21 | + - const: allwinner,sun8i-a83t-de2-rotate | |
| 22 | + - items: | |
| 23 | + - const: allwinner,sun50i-a64-de2-rotate | |
| 24 | + - const: allwinner,sun8i-a83t-de2-rotate | |
| 25 | + | |
| 26 | + reg: | |
| 27 | + maxItems: 1 | |
| 28 | + | |
| 29 | + interrupts: | |
| 30 | + maxItems: 1 | |
| 31 | + | |
| 32 | + clocks: | |
| 33 | + items: | |
| 34 | + - description: Rotate interface clock | |
| 35 | + - description: Rotate module clock | |
| 36 | + | |
| 37 | + clock-names: | |
| 38 | + items: | |
| 39 | + - const: bus | |
| 40 | + - const: mod | |
| 41 | + | |
| 42 | + resets: | |
| 43 | + maxItems: 1 | |
| 44 | + | |
| 45 | +required: | |
| 46 | + - compatible | |
| 47 | + - reg | |
| 48 | + - interrupts | |
| 49 | + - clocks | |
| 50 | + | |
| 51 | +additionalProperties: false | |
| 52 | + | |
| 53 | +examples: | |
| 54 | + - | | |
| 55 | + #include <dt-bindings/interrupt-controller/arm-gic.h> | |
| 56 | + #include <dt-bindings/clock/sun8i-de2.h> | |
| 57 | + #include <dt-bindings/reset/sun8i-de2.h> | |
| 58 | + | |
| 59 | + rotate: rotate@1020000 { | |
| 60 | + compatible = "allwinner,sun8i-a83t-de2-rotate"; | |
| 61 | + reg = <0x1020000 0x10000>; | |
| 62 | + interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>; | |
| 63 | + clocks = <&display_clocks CLK_BUS_ROT>, | |
| 64 | + <&display_clocks CLK_ROT>; | |
| 65 | + clock-names = "bus", | |
| 66 | + "mod"; | |
| 67 | + resets = <&display_clocks RST_ROT>; | |
| 68 | + }; | |
| 69 | + | |
| 70 | +... | |
| @@ -17,7 +17,11 @@ description: |- · 16 unmodified lines | ||
| 17 | 17 | |
| 18 | 18 | properties: |
| 19 | 19 | compatible: |
| 20 | − const: allwinner,sun8i-h3-deinterlace | |
| 20 | + oneOf: | |
| 21 | + - const: allwinner,sun8i-h3-deinterlace | |
| 22 | + - items: | |
| 23 | + - const: allwinner,sun50i-a64-deinterlace | |
| 24 | + - const: allwinner,sun8i-h3-deinterlace | |
| 21 | 25 | |
| 22 | 26 | reg: |
| 23 | 27 | maxItems: 1 |
| @@ -124,6 +124,8 @@ required: · 123 unmodified lines | ||
| 124 | 124 | - amlogic,ao-sysctrl |
| 125 | 125 | - amlogic,canvas |
| 126 | 126 | |
| 127 | +additionalProperties: false | |
| 128 | + | |
| 127 | 129 | examples: |
| 128 | 130 | - | |
| 129 | 131 | vdec: video-decoder@c8820000 { |
| @@ -24,6 +24,12 @@ properties: · 23 unmodified lines | ||
| 24 | 24 | reg: |
| 25 | 25 | maxItems: 1 |
| 26 | 26 | |
| 27 | + clocks: | |
| 28 | + maxItems: 1 | |
| 29 | + | |
| 30 | + clock-names: | |
| 31 | + maxItems: 1 | |
| 32 | + | |
| 27 | 33 | interrupts: |
| 28 | 34 | maxItems: 1 |
| 29 | 35 | |
| @@ -47,7 +53,6 @@ allOf: · 17 unmodified lines | ||
| 47 | 53 | - description: AO-CEC clock |
| 48 | 54 | |
| 49 | 55 | clock-names: |
| 50 | − maxItems: 1 | |
| 51 | 56 | items: |
| 52 | 57 | - const: core |
| 53 | 58 | |
| @@ -66,7 +71,6 @@ allOf: · 12 unmodified lines | ||
| 66 | 71 | - description: AO-CEC clock generator source |
| 67 | 72 | |
| 68 | 73 | clock-names: |
| 69 | − maxItems: 1 | |
| 70 | 74 | items: |
| 71 | 75 | - const: oscin |
| 72 | 76 | |
| @@ -78,6 +82,8 @@ required: · 5 unmodified lines | ||
| 78 | 82 | - clocks |
| 79 | 83 | - clock-names |
| 80 | 84 | |
| 85 | +additionalProperties: false | |
| 86 | + | |
| 81 | 87 | examples: |
| 82 | 88 | - | |
| 83 | 89 | cec_AO: cec@100 { |
| @@ -88,4 +94,3 @@ examples: · 4 unmodified lines | ||
| 88 | 94 | clock-names = "core"; |
| 89 | 95 | hdmi-phandle = <&hdmi_tx>; |
| 90 | 96 | }; |
| 91 | − | |
| @@ -1,11 +1,12 @@ | ||
| 1 | 1 | * Device tree bindings for Aspeed Video Engine |
| 2 | 2 | |
| 3 | −The Video Engine (VE) embedded in the Aspeed AST2400 and AST2500 SOCs can | |
| 3 | +The Video Engine (VE) embedded in the Aspeed AST2400/2500/2600 SOCs can | |
| 4 | 4 | capture and compress video data from digital or analog sources. |
| 5 | 5 | |
| 6 | 6 | Required properties: |
| 7 | 7 | - compatible: "aspeed,ast2400-video-engine" or |
| 8 | − "aspeed,ast2500-video-engine" | |
| 8 | + "aspeed,ast2500-video-engine" or | |
| 9 | + "aspeed,ast2600-video-engine" | |
| 9 | 10 | - reg: contains the offset and length of the VE memory region |
| 10 | 11 | - clocks: clock specifiers for the syscon clocks associated with |
| 11 | 12 | the VE (ordering must match the clock-names property) |
| @@ -0,0 +1,114 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/media/i2c/imx219.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Sony 1/4.0-Inch 8Mpixel CMOS Digital Image Sensor | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Dave Stevenson <dave.stevenson@raspberrypi.com> | |
| 11 | + | |
| 12 | +description: |- | |
| 13 | + The Sony imx219 is a 1/4.0-inch CMOS active pixel digital image sensor | |
| 14 | + with an active array size of 3280H x 2464V. It is programmable through | |
| 15 | + I2C interface. The I2C address is fixed to 0x10 as per sensor data sheet. | |
| 16 | + Image data is sent through MIPI CSI-2, which is configured as either 2 or | |
| 17 | + 4 data lanes. | |
| 18 | + | |
| 19 | +properties: | |
| 20 | + compatible: | |
| 21 | + const: sony,imx219 | |
| 22 | + | |
| 23 | + reg: | |
| 24 | + description: I2C device address | |
| 25 | + maxItems: 1 | |
| 26 | + | |
| 27 | + clocks: | |
| 28 | + maxItems: 1 | |
| 29 | + | |
| 30 | + VDIG-supply: | |
| 31 | + description: | |
| 32 | + Digital I/O voltage supply, 1.8 volts | |
| 33 | + | |
| 34 | + VANA-supply: | |
| 35 | + description: | |
| 36 | + Analog voltage supply, 2.8 volts | |
| 37 | + | |
| 38 | + VDDL-supply: | |
| 39 | + description: | |
| 40 | + Digital core voltage supply, 1.2 volts | |
| 41 | + | |
| 42 | + reset-gpios: | |
| 43 | + description: |- | |
| 44 | + Reference to the GPIO connected to the xclr pin, if any. | |
| 45 | + Must be released (set high) after all supplies are applied. | |
| 46 | + | |
| 47 | + # See ../video-interfaces.txt for more details | |
| 48 | + port: | |
| 49 | + type: object | |
| 50 | + properties: | |
| 51 | + endpoint: | |
| 52 | + type: object | |
| 53 | + properties: | |
| 54 | + data-lanes: | |
| 55 | + description: |- | |
| 56 | + The sensor supports either two-lane, or four-lane operation. | |
| 57 | + If this property is omitted four-lane operation is assumed. | |
| 58 | + For two-lane operation the property must be set to <1 2>. | |
| 59 | + items: | |
| 60 | + - const: 1 | |
| 61 | + - const: 2 | |
| 62 | + | |
| 63 | + clock-noncontinuous: | |
| 64 | + type: boolean | |
| 65 | + description: |- | |
| 66 | + MIPI CSI-2 clock is non-continuous if this property is present, | |
| 67 | + otherwise it's continuous. | |
| 68 | + | |
| 69 | + link-frequencies: | |
| 70 | + allOf: | |
| 71 | + - $ref: /schemas/types.yaml#/definitions/uint64-array | |
| 72 | + description: | |
| 73 | + Allowed data bus frequencies. | |
| 74 | + | |
| 75 | + required: | |
| 76 | + - link-frequencies | |
| 77 | + | |
| 78 | +required: | |
| 79 | + - compatible | |
| 80 | + - reg | |
| 81 | + - clocks | |
| 82 | + - VANA-supply | |
| 83 | + - VDIG-supply | |
| 84 | + - VDDL-supply | |
| 85 | + - port | |
| 86 | + | |
| 87 | +additionalProperties: false | |
| 88 | + | |
| 89 | +examples: | |
| 90 | + - | | |
| 91 | + i2c0 { | |
| 92 | + #address-cells = <1>; | |
| 93 | + #size-cells = <0>; | |
| 94 | + | |
| 95 | + imx219: sensor@10 { | |
| 96 | + compatible = "sony,imx219"; | |
| 97 | + reg = <0x10>; | |
| 98 | + clocks = <&imx219_clk>; | |
| 99 | + VANA-supply = <&imx219_vana>; /* 2.8v */ | |
| 100 | + VDIG-supply = <&imx219_vdig>; /* 1.8v */ | |
| 101 | + VDDL-supply = <&imx219_vddl>; /* 1.2v */ | |
| 102 | + | |
| 103 | + port { | |
| 104 | + imx219_0: endpoint { | |
| 105 | + remote-endpoint = <&csi1_ep>; | |
| 106 | + data-lanes = <1 2>; | |
| 107 | + clock-noncontinuous; | |
| 108 | + link-frequencies = /bits/ 64 <456000000>; | |
| 109 | + }; | |
| 110 | + }; | |
| 111 | + }; | |
| 112 | + }; | |
| 113 | + | |
| 114 | +... | |
| @@ -5,38 +5,150 @@ The TVP5150 and TVP5151 are video decoders that convert baseband NTSC and PAL · 4 unmodified lines | ||
| 5 | 5 | with discrete syncs or 8-bit ITU-R BT.656 with embedded syncs output formats. |
| 6 | 6 | |
| 7 | 7 | Required Properties: |
| 8 | −- compatible: value must be "ti,tvp5150" | |
| 9 | −- reg: I2C slave address | |
| 8 | +==================== | |
| 9 | +- compatible: Value must be "ti,tvp5150". | |
| 10 | +- reg: I2C slave address. | |
| 10 | 11 | |
| 11 | 12 | Optional Properties: |
| 12 | −- pdn-gpios: phandle for the GPIO connected to the PDN pin, if any. | |
| 13 | −- reset-gpios: phandle for the GPIO connected to the RESETB pin, if any. | |
| 13 | +==================== | |
| 14 | +- pdn-gpios: Phandle for the GPIO connected to the PDN pin, if any. | |
| 15 | +- reset-gpios: Phandle for the GPIO connected to the RESETB pin, if any. | |
| 14 | 16 | |
| 15 | −The device node must contain one 'port' child node for its digital output | |
| 16 | −video port, in accordance with the video interface bindings defined in | |
| 17 | −Documentation/devicetree/bindings/media/video-interfaces.txt. | |
| 17 | +The device node must contain one 'port' child node per device physical input | |
| 18 | +and output port, in accordance with the video interface bindings defined in | |
| 19 | +Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes | |
| 20 | +are numbered as follows | |
| 18 | 21 | |
| 19 | −Required Endpoint Properties for parallel synchronization: | |
| 22 | + Name Type Port | |
| 23 | + -------------------------------------- | |
| 24 | + AIP1A sink 0 | |
| 25 | + AIP1B sink 1 | |
| 26 | + Y-OUT src 2 | |
| 20 | 27 | |
| 21 | −- hsync-active: active state of the HSYNC signal. Must be <1> (HIGH). | |
| 22 | −- vsync-active: active state of the VSYNC signal. Must be <1> (HIGH). | |
| 23 | −- field-even-active: field signal level during the even field data | |
| 24 | − transmission. Must be <0>. | |
| 28 | +The device node must contain at least one sink port and the src port. Each input | |
| 29 | +port must be linked to an endpoint defined in [1]. The port/connector layout is | |
| 30 | +as follows | |
| 25 | 31 | |
| 26 | −If none of hsync-active, vsync-active and field-even-active is specified, | |
| 27 | −the endpoint is assumed to use embedded BT.656 synchronization. | |
| 32 | +tvp-5150 port@0 (AIP1A) | |
| 33 | + endpoint@0 -----------> Comp0-Con port | |
| 34 | + endpoint@1 ------+----> Svideo-Con port | |
| 35 | +tvp-5150 port@1 (AIP1B) | | |
| 36 | + endpoint@1 ------+ | |
| 37 | + endpoint@0 -----------> Comp1-Con port | |
| 38 | +tvp-5150 port@2 | |
| 39 | + endpoint (video bitstream output at YOUT[0-7] parallel bus) | |
| 28 | 40 | |
| 29 | −Example: | |
| 41 | +Required Endpoint Properties for parallel synchronization on output port: | |
| 42 | +========================================================================= | |
| 43 | + | |
| 44 | +- hsync-active: Active state of the HSYNC signal. Must be <1> (HIGH). | |
| 45 | +- vsync-active: Active state of the VSYNC signal. Must be <1> (HIGH). | |
| 46 | +- field-even-active: Field signal level during the even field data | |
| 47 | + transmission. Must be <0>. | |
| 48 | + | |
| 49 | +Note: Do not specify any of these properties if you want to use the embedded | |
| 50 | + BT.656 synchronization. | |
| 51 | + | |
| 52 | +Optional Connector Properties: | |
| 53 | +============================== | |
| 54 | + | |
| 55 | +- sdtv-standards: Set the possible signals to which the hardware tries to lock | |
| 56 | + instead of using the autodetection mechnism. Please look at | |
| 57 | + [1] for more information. | |
| 58 | + | |
| 59 | +[1] Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt. | |
| 60 | + | |
| 61 | +Example - three input sources: | |
| 62 | +#include <dt-bindings/display/sdtv-standards.h> | |
| 63 | + | |
| 64 | +comp_connector_0 { | |
| 65 | + compatible = "composite-video-connector"; | |
| 66 | + label = "Composite0"; | |
| 67 | + sdtv-standards = <SDTV_STD_PAL_M>; /* limit to pal-m signals */ | |
| 68 | + | |
| 69 | + port { | |
| 70 | + composite0_to_tvp5150: endpoint { | |
| 71 | + remote-endpoint = <&tvp5150_to_composite0>; | |
| 72 | + }; | |
| 73 | + }; | |
| 74 | +}; | |
| 75 | + | |
| 76 | +comp_connector_1 { | |
| 77 | + compatible = "composite-video-connector"; | |
| 78 | + label = "Composite1"; | |
| 79 | + sdtv-standards = <SDTV_STD_NTSC_M>; /* limit to ntsc-m signals */ | |
| 80 | + | |
| 81 | + port { | |
| 82 | + composite1_to_tvp5150: endpoint { | |
| 83 | + remote-endpoint = <&tvp5150_to_composite1>; | |
| 84 | + }; | |
| 85 | + }; | |
| 86 | +}; | |
| 87 | + | |
| 88 | +svideo_connector { | |
| 89 | + compatible = "svideo-connector"; | |
| 90 | + label = "S-Video"; | |
| 91 | + | |
| 92 | + port { | |
| 93 | + #address-cells = <1>; | |
| 94 | + #size-cells = <0>; | |
| 95 | + | |
| 96 | + svideo_luma_to_tvp5150: endpoint@0 { | |
| 97 | + reg = <0>; | |
| 98 | + remote-endpoint = <&tvp5150_to_svideo_luma>; | |
| 99 | + }; | |
| 100 | + | |
| 101 | + svideo_chroma_to_tvp5150: endpoint@1 { | |
| 102 | + reg = <1>; | |
| 103 | + remote-endpoint = <&tvp5150_to_svideo_chroma>; | |
| 104 | + }; | |
| 105 | + }; | |
| 106 | +}; | |
| 30 | 107 | |
| 31 | 108 | &i2c2 { |
| 32 | − ... | |
| 33 | 109 | tvp5150@5c { |
| 34 | 110 | compatible = "ti,tvp5150"; |
| 35 | 111 | reg = <0x5c>; |
| 36 | 112 | pdn-gpios = <&gpio4 30 GPIO_ACTIVE_LOW>; |
| 37 | 113 | reset-gpios = <&gpio6 7 GPIO_ACTIVE_LOW>; |
| 114 | + #address-cells = <1>; | |
| 115 | + #size-cells = <0>; | |
| 116 | + | |
| 117 | + port@0 { | |
| 118 | + #address-cells = <1>; | |
| 119 | + #size-cells = <0>; | |
| 120 | + reg = <0>; | |
| 121 | + | |
| 122 | + tvp5150_to_composite0: endpoint@0 { | |
| 123 | + reg = <0>; | |
| 124 | + remote-endpoint = <&composite0_to_tvp5150>; | |
| 125 | + }; | |
| 126 | + | |
| 127 | + tvp5150_to_svideo_luma: endpoint@1 { | |
| 128 | + reg = <1>; | |
| 129 | + remote-endpoint = <&svideo_luma_to_tvp5150>; | |
| 130 | + }; | |
| 131 | + }; | |
| 132 | + | |
| 133 | + port@1 { | |
| 134 | + #address-cells = <1>; | |
| 135 | + #size-cells = <0>; | |
| 136 | + reg = <1>; | |
| 137 | + | |
| 138 | + tvp5150_to_composite1: endpoint@0 { | |
| 139 | + reg = <0>; | |
| 140 | + remote-endpoint = <&composite1_to_tvp5150>; | |
| 141 | + }; | |
| 142 | + | |
| 143 | + tvp5150_to_svideo_chroma: endpoint@1 { | |
| 144 | + reg = <1>; | |
| 145 | + remote-endpoint = <&svideo_chroma_to_tvp5150>; | |
| 146 | + }; | |
| 147 | + }; | |
| 148 | + | |
| 149 | + port@2 { | |
| 150 | + reg = <2>; | |
| 38 | 151 | |
| 39 | − port { | |
| 40 | 152 | tvp5150_1: endpoint { |
| 41 | 153 | remote-endpoint = <&ccdc_ep>; |
| 42 | 154 | }; |
| @@ -0,0 +1,77 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | + | |
| 3 | +%YAML 1.2 | |
| 4 | +--- | |
| 5 | +$id: "http://devicetree.org/schemas/media/nxp,imx8mq-vpu.yaml#" | |
| 6 | +$schema: "http://devicetree.org/meta-schemas/core.yaml#" | |
| 7 | + | |
| 8 | +title: Hantro G1/G2 VPU codecs implemented on i.MX8MQ SoCs | |
| 9 | + | |
| 10 | +maintainers: | |
| 11 | + - Philipp Zabel <p.zabel@pengutronix.de> | |
| 12 | + | |
| 13 | +description: | |
| 14 | + Hantro G1/G2 video decode accelerators present on i.MX8MQ SoCs. | |
| 15 | + | |
| 16 | +properties: | |
| 17 | + compatible: | |
| 18 | + const: nxp,imx8mq-vpu | |
| 19 | + | |
| 20 | + reg: | |
| 21 | + maxItems: 3 | |
| 22 | + | |
| 23 | + reg-names: | |
| 24 | + items: | |
| 25 | + - const: g1 | |
| 26 | + - const: g2 | |
| 27 | + - const: ctrl | |
| 28 | + | |
| 29 | + interrupts: | |
| 30 | + maxItems: 2 | |
| 31 | + | |
| 32 | + interrupt-names: | |
| 33 | + items: | |
| 34 | + - const: g1 | |
| 35 | + - const: g2 | |
| 36 | + | |
| 37 | + clocks: | |
| 38 | + maxItems: 3 | |
| 39 | + | |
| 40 | + clock-names: | |
| 41 | + items: | |
| 42 | + - const: g1 | |
| 43 | + - const: g2 | |
| 44 | + - const: bus | |
| 45 | + | |
| 46 | + power-domains: | |
| 47 | + maxItems: 1 | |
| 48 | + | |
| 49 | +required: | |
| 50 | + - compatible | |
| 51 | + - reg | |
| 52 | + - reg-names | |
| 53 | + - interrupts | |
| 54 | + - interrupt-names | |
| 55 | + - clocks | |
| 56 | + - clock-names | |
| 57 | + | |
| 58 | +examples: | |
| 59 | + - | | |
| 60 | + #include <dt-bindings/clock/imx8mq-clock.h> | |
| 61 | + #include <dt-bindings/interrupt-controller/arm-gic.h> | |
| 62 | + | |
| 63 | + vpu: video-codec@38300000 { | |
| 64 | + compatible = "nxp,imx8mq-vpu"; | |
| 65 | + reg = <0x38300000 0x10000>, | |
| 66 | + <0x38310000 0x10000>, | |
| 67 | + <0x38320000 0x10000>; | |
| 68 | + reg-names = "g1", "g2", "ctrl"; | |
| 69 | + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>, | |
| 70 | + <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>; | |
| 71 | + interrupt-names = "g1", "g2"; | |
| 72 | + clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>, | |
| 73 | + <&clk IMX8MQ_CLK_VPU_G2_ROOT>, | |
| 74 | + <&clk IMX8MQ_CLK_VPU_DEC_ROOT>; | |
| 75 | + clock-names = "g1", "g2", "bus"; | |
| 76 | + power-domains = <&pgc_vpu>; | |
| 77 | + }; | |
| @@ -0,0 +1,119 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | + | |
| 3 | +%YAML 1.2 | |
| 4 | +--- | |
| 5 | +$id: "http://devicetree.org/schemas/media/qcom,msm8916-venus.yaml#" | |
| 6 | +$schema: "http://devicetree.org/meta-schemas/core.yaml#" | |
| 7 | + | |
| 8 | +title: Qualcomm Venus video encode and decode accelerators | |
| 9 | + | |
| 10 | +maintainers: | |
| 11 | + - Stanimir Varbanov <stanimir.varbanov@linaro.org> | |
| 12 | + | |
| 13 | +description: | | |
| 14 | + The Venus IP is a video encode and decode accelerator present | |
| 15 | + on Qualcomm platforms | |
| 16 | + | |
| 17 | +properties: | |
| 18 | + compatible: | |
| 19 | + const: qcom,msm8916-venus | |
| 20 | + | |
| 21 | + reg: | |
| 22 | + maxItems: 1 | |
| 23 | + | |
| 24 | + interrupts: | |
| 25 | + maxItems: 1 | |
| 26 | + | |
| 27 | + power-domains: | |
| 28 | + maxItems: 1 | |
| 29 | + | |
| 30 | + clocks: | |
| 31 | + maxItems: 3 | |
| 32 | + | |
| 33 | + clock-names: | |
| 34 | + items: | |
| 35 | + - const: core | |
| 36 | + - const: iface | |
| 37 | + - const: bus | |
| 38 | + | |
| 39 | + iommus: | |
| 40 | + maxItems: 1 | |
| 41 | + | |
| 42 | + memory-region: | |
| 43 | + maxItems: 1 | |
| 44 | + | |
| 45 | + video-decoder: | |
| 46 | + type: object | |
| 47 | + | |
| 48 | + properties: | |
| 49 | + compatible: | |
| 50 | + const: "venus-decoder" | |
| 51 | + | |
| 52 | + required: | |
| 53 | + - compatible | |
| 54 | + | |
| 55 | + additionalProperties: false | |
| 56 | + | |
| 57 | + video-encoder: | |
| 58 | + type: object | |
| 59 | + | |
| 60 | + properties: | |
| 61 | + compatible: | |
| 62 | + const: "venus-encoder" | |
| 63 | + | |
| 64 | + required: | |
| 65 | + - compatible | |
| 66 | + | |
| 67 | + additionalProperties: false | |
| 68 | + | |
| 69 | + video-firmware: | |
| 70 | + type: object | |
| 71 | + | |
| 72 | + description: | | |
| 73 | + Firmware subnode is needed when the platform does not | |
| 74 | + have TrustZone. | |
| 75 | + | |
| 76 | + properties: | |
| 77 | + iommus: | |
| 78 | + maxItems: 1 | |
| 79 | + | |
| 80 | + required: | |
| 81 | + - iommus | |
| 82 | + | |
| 83 | +required: | |
| 84 | + - compatible | |
| 85 | + - reg | |
| 86 | + - interrupts | |
| 87 | + - power-domains | |
| 88 | + - clocks | |
| 89 | + - clock-names | |
| 90 | + - iommus | |
| 91 | + - memory-region | |
| 92 | + - video-decoder | |
| 93 | + - video-encoder | |
| 94 | + | |
| 95 | +examples: | |
| 96 | + - | | |
| 97 | + #include <dt-bindings/interrupt-controller/arm-gic.h> | |
| 98 | + #include <dt-bindings/clock/qcom,gcc-msm8916.h> | |
| 99 | + | |
| 100 | + video-codec@1d00000 { | |
| 101 | + compatible = "qcom,msm8916-venus"; | |
| 102 | + reg = <0x01d00000 0xff000>; | |
| 103 | + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>; | |
| 104 | + clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>, | |
| 105 | + <&gcc GCC_VENUS0_AHB_CLK>, | |
| 106 | + <&gcc GCC_VENUS0_AXI_CLK>; | |
| 107 | + clock-names = "core", "iface", "bus"; | |
| 108 | + power-domains = <&gcc VENUS_GDSC>; | |
| 109 | + iommus = <&apps_iommu 5>; | |
| 110 | + memory-region = <&venus_mem>; | |
| 111 | + | |
| 112 | + video-decoder { | |
| 113 | + compatible = "venus-decoder"; | |
| 114 | + }; | |
| 115 | + | |
| 116 | + video-encoder { | |
| 117 | + compatible = "venus-encoder"; | |
| 118 | + }; | |
| 119 | + }; | |
| @@ -0,0 +1,172 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | + | |
| 3 | +%YAML 1.2 | |
| 4 | +--- | |
| 5 | +$id: "http://devicetree.org/schemas/media/qcom,msm8996-venus.yaml#" | |
| 6 | +$schema: "http://devicetree.org/meta-schemas/core.yaml#" | |
| 7 | + | |
| 8 | +title: Qualcomm Venus video encode and decode accelerators | |
| 9 | + | |
| 10 | +maintainers: | |
| 11 | + - Stanimir Varbanov <stanimir.varbanov@linaro.org> | |
| 12 | + | |
| 13 | +description: | | |
| 14 | + The Venus IP is a video encode and decode accelerator present | |
| 15 | + on Qualcomm platforms | |
| 16 | + | |
| 17 | +properties: | |
| 18 | + compatible: | |
| 19 | + const: qcom,msm8996-venus | |
| 20 | + | |
| 21 | + reg: | |
| 22 | + maxItems: 1 | |
| 23 | + | |
| 24 | + interrupts: | |
| 25 | + maxItems: 1 | |
| 26 | + | |
| 27 | + power-domains: | |
| 28 | + maxItems: 1 | |
| 29 | + | |
| 30 | + clocks: | |
| 31 | + maxItems: 4 | |
| 32 | + | |
| 33 | + clock-names: | |
| 34 | + items: | |
| 35 | + - const: core | |
| 36 | + - const: iface | |
| 37 | + - const: bus | |
| 38 | + - const: mbus | |
| 39 | + | |
| 40 | + iommus: | |
| 41 | + maxItems: 20 | |
| 42 | + | |
| 43 | + memory-region: | |
| 44 | + maxItems: 1 | |
| 45 | + | |
| 46 | + video-decoder: | |
| 47 | + type: object | |
| 48 | + | |
| 49 | + properties: | |
| 50 | + compatible: | |
| 51 | + const: venus-decoder | |
| 52 | + | |
| 53 | + clocks: | |
| 54 | + maxItems: 1 | |
| 55 | + | |
| 56 | + clock-names: | |
| 57 | + items: | |
| 58 | + - const: core | |
| 59 | + | |
| 60 | + power-domains: | |
| 61 | + maxItems: 1 | |
| 62 | + | |
| 63 | + required: | |
| 64 | + - compatible | |
| 65 | + - clocks | |
| 66 | + - clock-names | |
| 67 | + - power-domains | |
| 68 | + | |
| 69 | + additionalProperties: false | |
| 70 | + | |
| 71 | + video-encoder: | |
| 72 | + type: object | |
| 73 | + | |
| 74 | + properties: | |
| 75 | + compatible: | |
| 76 | + const: venus-encoder | |
| 77 | + | |
| 78 | + clocks: | |
| 79 | + maxItems: 1 | |
| 80 | + | |
| 81 | + clock-names: | |
| 82 | + items: | |
| 83 | + - const: core | |
| 84 | + | |
| 85 | + power-domains: | |
| 86 | + maxItems: 1 | |
| 87 | + | |
| 88 | + required: | |
| 89 | + - compatible | |
| 90 | + - clocks | |
| 91 | + - clock-names | |
| 92 | + - power-domains | |
| 93 | + | |
| 94 | + additionalProperties: false | |
| 95 | + | |
| 96 | + video-firmware: | |
| 97 | + type: object | |
| 98 | + | |
| 99 | + description: | | |
| 100 | + Firmware subnode is needed when the platform does not | |
| 101 | + have TrustZone. | |
| 102 | + | |
| 103 | + properties: | |
| 104 | + iommus: | |
| 105 | + maxItems: 1 | |
| 106 | + | |
| 107 | + required: | |
| 108 | + - iommus | |
| 109 | + | |
| 110 | +required: | |
| 111 | + - compatible | |
| 112 | + - reg | |
| 113 | + - interrupts | |
| 114 | + - power-domains | |
| 115 | + - clocks | |
| 116 | + - clock-names | |
| 117 | + - iommus | |
| 118 | + - memory-region | |
| 119 | + - video-decoder | |
| 120 | + - video-encoder | |
| 121 | + | |
| 122 | +examples: | |
| 123 | + - | | |
| 124 | + #include <dt-bindings/interrupt-controller/arm-gic.h> | |
| 125 | + #include <dt-bindings/clock/qcom,mmcc-msm8996.h> | |
| 126 | + | |
| 127 | + video-codec@c00000 { | |
| 128 | + compatible = "qcom,msm8996-venus"; | |
| 129 | + reg = <0x00c00000 0xff000>; | |
| 130 | + interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>; | |
| 131 | + clocks = <&mmcc VIDEO_CORE_CLK>, | |
| 132 | + <&mmcc VIDEO_AHB_CLK>, | |
| 133 | + <&mmcc VIDEO_AXI_CLK>, | |
| 134 | + <&mmcc VIDEO_MAXI_CLK>; | |
| 135 | + clock-names = "core", "iface", "bus", "mbus"; | |
| 136 | + power-domains = <&mmcc VENUS_GDSC>; | |
| 137 | + iommus = <&venus_smmu 0x00>, | |
| 138 | + <&venus_smmu 0x01>, | |
| 139 | + <&venus_smmu 0x0a>, | |
| 140 | + <&venus_smmu 0x07>, | |
| 141 | + <&venus_smmu 0x0e>, | |
| 142 | + <&venus_smmu 0x0f>, | |
| 143 | + <&venus_smmu 0x08>, | |
| 144 | + <&venus_smmu 0x09>, | |
| 145 | + <&venus_smmu 0x0b>, | |
| 146 | + <&venus_smmu 0x0c>, | |
| 147 | + <&venus_smmu 0x0d>, | |
| 148 | + <&venus_smmu 0x10>, | |
| 149 | + <&venus_smmu 0x11>, | |
| 150 | + <&venus_smmu 0x21>, | |
| 151 | + <&venus_smmu 0x28>, | |
| 152 | + <&venus_smmu 0x29>, | |
| 153 | + <&venus_smmu 0x2b>, | |
| 154 | + <&venus_smmu 0x2c>, | |
| 155 | + <&venus_smmu 0x2d>, | |
| 156 | + <&venus_smmu 0x31>; | |
| 157 | + memory-region = <&venus_mem>; | |
| 158 | + | |
| 159 | + video-decoder { | |
| 160 | + compatible = "venus-decoder"; | |
| 161 | + clocks = <&mmcc VIDEO_SUBCORE0_CLK>; | |
| 162 | + clock-names = "core"; | |
| 163 | + power-domains = <&mmcc VENUS_CORE0_GDSC>; | |
| 164 | + }; | |
| 165 | + | |
| 166 | + video-encoder { | |
| 167 | + compatible = "venus-encoder"; | |
| 168 | + clocks = <&mmcc VIDEO_SUBCORE1_CLK>; | |
| 169 | + clock-names = "core"; | |
| 170 | + power-domains = <&mmcc VENUS_CORE1_GDSC>; | |
| 171 | + }; | |
| 172 | + }; | |
| @@ -0,0 +1,140 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | + | |
| 3 | +%YAML 1.2 | |
| 4 | +--- | |
| 5 | +$id: "http://devicetree.org/schemas/media/qcom,sc7180-venus.yaml#" | |
| 6 | +$schema: "http://devicetree.org/meta-schemas/core.yaml#" | |
| 7 | + | |
| 8 | +title: Qualcomm Venus video encode and decode accelerators | |
| 9 | + | |
| 10 | +maintainers: | |
| 11 | + - Stanimir Varbanov <stanimir.varbanov@linaro.org> | |
| 12 | + | |
| 13 | +description: | | |
| 14 | + The Venus IP is a video encode and decode accelerator present | |
| 15 | + on Qualcomm platforms | |
| 16 | + | |
| 17 | +properties: | |
| 18 | + compatible: | |
| 19 | + const: qcom,sc7180-venus | |
| 20 | + | |
| 21 | + reg: | |
| 22 | + maxItems: 1 | |
| 23 | + | |
| 24 | + interrupts: | |
| 25 | + maxItems: 1 | |
| 26 | + | |
| 27 | + power-domains: | |
| 28 | + maxItems: 2 | |
| 29 | + | |
| 30 | + power-domain-names: | |
| 31 | + items: | |
| 32 | + - const: venus | |
| 33 | + - const: vcodec0 | |
| 34 | + | |
| 35 | + clocks: | |
| 36 | + maxItems: 5 | |
| 37 | + | |
| 38 | + clock-names: | |
| 39 | + items: | |
| 40 | + - const: core | |
| 41 | + - const: iface | |
| 42 | + - const: bus | |
| 43 | + - const: vcodec0_core | |
| 44 | + - const: vcodec0_bus | |
| 45 | + | |
| 46 | + iommus: | |
| 47 | + maxItems: 1 | |
| 48 | + | |
| 49 | + memory-region: | |
| 50 | + maxItems: 1 | |
| 51 | + | |
| 52 | + interconnects: | |
| 53 | + maxItems: 2 | |
| 54 | + | |
| 55 | + interconnect-names: | |
| 56 | + items: | |
| 57 | + - const: video-mem | |
| 58 | + - const: cpu-cfg | |
| 59 | + | |
| 60 | + video-decoder: | |
| 61 | + type: object | |
| 62 | + | |
| 63 | + properties: | |
| 64 | + compatible: | |
| 65 | + const: venus-decoder | |
| 66 | + | |
| 67 | + required: | |
| 68 | + - compatible | |
| 69 | + | |
| 70 | + additionalProperties: false | |
| 71 | + | |
| 72 | + video-encoder: | |
| 73 | + type: object | |
| 74 | + | |
| 75 | + properties: | |
| 76 | + compatible: | |
| 77 | + const: venus-encoder | |
| 78 | + | |
| 79 | + required: | |
| 80 | + - compatible | |
| 81 | + | |
| 82 | + additionalProperties: false | |
| 83 | + | |
| 84 | + video-firmware: | |
| 85 | + type: object | |
| 86 | + | |
| 87 | + description: | | |
| 88 | + Firmware subnode is needed when the platform does not | |
| 89 | + have TrustZone. | |
| 90 | + | |
| 91 | + properties: | |
| 92 | + iommus: | |
| 93 | + maxItems: 1 | |
| 94 | + | |
| 95 | + required: | |
| 96 | + - iommus | |
| 97 | + | |
| 98 | +required: | |
| 99 | + - compatible | |
| 100 | + - reg | |
| 101 | + - interrupts | |
| 102 | + - power-domains | |
| 103 | + - power-domain-names | |
| 104 | + - clocks | |
| 105 | + - clock-names | |
| 106 | + - iommus | |
| 107 | + - memory-region | |
| 108 | + - video-decoder | |
| 109 | + - video-encoder | |
| 110 | + | |
| 111 | +examples: | |
| 112 | + - | | |
| 113 | + #include <dt-bindings/interrupt-controller/arm-gic.h> | |
| 114 | + #include <dt-bindings/clock/qcom,videocc-sc7180.h> | |
| 115 | + | |
| 116 | + venus: video-codec@aa00000 { | |
| 117 | + compatible = "qcom,sc7180-venus"; | |
| 118 | + reg = <0 0x0aa00000 0 0xff000>; | |
| 119 | + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; | |
| 120 | + power-domains = <&videocc VENUS_GDSC>, | |
| 121 | + <&videocc VCODEC0_GDSC>; | |
| 122 | + power-domain-names = "venus", "vcodec0"; | |
| 123 | + clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>, | |
| 124 | + <&videocc VIDEO_CC_VENUS_AHB_CLK>, | |
| 125 | + <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>, | |
| 126 | + <&videocc VIDEO_CC_VCODEC0_CORE_CLK>, | |
| 127 | + <&videocc VIDEO_CC_VCODEC0_AXI_CLK>; | |
| 128 | + clock-names = "core", "iface", "bus", | |
| 129 | + "vcodec0_core", "vcodec0_bus"; | |
| 130 | + iommus = <&apps_smmu 0x0c00 0x60>; | |
| 131 | + memory-region = <&venus_mem>; | |
| 132 | + | |
| 133 | + video-decoder { | |
| 134 | + compatible = "venus-decoder"; | |
| 135 | + }; | |
| 136 | + | |
| 137 | + video-encoder { | |
| 138 | + compatible = "venus-encoder"; | |
| 139 | + }; | |
| 140 | + }; | |
| @@ -0,0 +1,140 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | + | |
| 3 | +%YAML 1.2 | |
| 4 | +--- | |
| 5 | +$id: "http://devicetree.org/schemas/media/qcom,sdm845-venus-v2.yaml#" | |
| 6 | +$schema: "http://devicetree.org/meta-schemas/core.yaml#" | |
| 7 | + | |
| 8 | +title: Qualcomm Venus video encode and decode accelerators | |
| 9 | + | |
| 10 | +maintainers: | |
| 11 | + - Stanimir Varbanov <stanimir.varbanov@linaro.org> | |
| 12 | + | |
| 13 | +description: | | |
| 14 | + The Venus IP is a video encode and decode accelerator present | |
| 15 | + on Qualcomm platforms | |
| 16 | + | |
| 17 | +properties: | |
| 18 | + compatible: | |
| 19 | + const: qcom,sdm845-venus-v2 | |
| 20 | + | |
| 21 | + reg: | |
| 22 | + maxItems: 1 | |
| 23 | + | |
| 24 | + interrupts: | |
| 25 | + maxItems: 1 | |
| 26 | + | |
| 27 | + power-domains: | |
| 28 | + maxItems: 3 | |
| 29 | + | |
| 30 | + power-domain-names: | |
| 31 | + items: | |
| 32 | + - const: venus | |
| 33 | + - const: vcodec0 | |
| 34 | + - const: vcodec1 | |
| 35 | + | |
| 36 | + clocks: | |
| 37 | + maxItems: 7 | |
| 38 | + | |
| 39 | + clock-names: | |
| 40 | + items: | |
| 41 | + - const: core | |
| 42 | + - const: iface | |
| 43 | + - const: bus | |
| 44 | + - const: vcodec0_core | |
| 45 | + - const: vcodec0_bus | |
| 46 | + - const: vcodec1_core | |
| 47 | + - const: vcodec1_bus | |
| 48 | + | |
| 49 | + iommus: | |
| 50 | + maxItems: 2 | |
| 51 | + | |
| 52 | + memory-region: | |
| 53 | + maxItems: 1 | |
| 54 | + | |
| 55 | + video-core0: | |
| 56 | + type: object | |
| 57 | + | |
| 58 | + properties: | |
| 59 | + compatible: | |
| 60 | + const: venus-decoder | |
| 61 | + | |
| 62 | + required: | |
| 63 | + - compatible | |
| 64 | + | |
| 65 | + additionalProperties: false | |
| 66 | + | |
| 67 | + video-core1: | |
| 68 | + type: object | |
| 69 | + | |
| 70 | + properties: | |
| 71 | + compatible: | |
| 72 | + const: venus-encoder | |
| 73 | + | |
| 74 | + required: | |
| 75 | + - compatible | |
| 76 | + | |
| 77 | + additionalProperties: false | |
| 78 | + | |
| 79 | + video-firmware: | |
| 80 | + type: object | |
| 81 | + | |
| 82 | + description: | | |
| 83 | + Firmware subnode is needed when the platform does not | |
| 84 | + have TrustZone. | |
| 85 | + | |
| 86 | + properties: | |
| 87 | + iommus: | |
| 88 | + maxItems: 1 | |
| 89 | + | |
| 90 | + required: | |
| 91 | + - iommus | |
| 92 | + | |
| 93 | +required: | |
| 94 | + - compatible | |
| 95 | + - reg | |
| 96 | + - interrupts | |
| 97 | + - power-domains | |
| 98 | + - power-domain-names | |
| 99 | + - clocks | |
| 100 | + - clock-names | |
| 101 | + - iommus | |
| 102 | + - memory-region | |
| 103 | + - video-core0 | |
| 104 | + - video-core1 | |
| 105 | + | |
| 106 | +examples: | |
| 107 | + - | | |
| 108 | + #include <dt-bindings/interrupt-controller/arm-gic.h> | |
| 109 | + #include <dt-bindings/clock/qcom,videocc-sdm845.h> | |
| 110 | + | |
| 111 | + video-codec@aa00000 { | |
| 112 | + compatible = "qcom,sdm845-venus-v2"; | |
| 113 | + reg = <0 0x0aa00000 0 0xff000>; | |
| 114 | + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; | |
| 115 | + clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>, | |
| 116 | + <&videocc VIDEO_CC_VENUS_AHB_CLK>, | |
| 117 | + <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>, | |
| 118 | + <&videocc VIDEO_CC_VCODEC0_CORE_CLK>, | |
| 119 | + <&videocc VIDEO_CC_VCODEC0_AXI_CLK>, | |
| 120 | + <&videocc VIDEO_CC_VCODEC1_CORE_CLK>, | |
| 121 | + <&videocc VIDEO_CC_VCODEC1_AXI_CLK>; | |
| 122 | + clock-names = "core", "iface", "bus", | |
| 123 | + "vcodec0_core", "vcodec0_bus", | |
| 124 | + "vcodec1_core", "vcodec1_bus"; | |
| 125 | + power-domains = <&videocc VENUS_GDSC>, | |
| 126 | + <&videocc VCODEC0_GDSC>, | |
| 127 | + <&videocc VCODEC1_GDSC>; | |
| 128 | + power-domain-names = "venus", "vcodec0", "vcodec1"; | |
| 129 | + iommus = <&apps_smmu 0x10a0 0x8>, | |
| 130 | + <&apps_smmu 0x10b0 0x0>; | |
| 131 | + memory-region = <&venus_mem>; | |
| 132 | + | |
| 133 | + video-core0 { | |
| 134 | + compatible = "venus-decoder"; | |
| 135 | + }; | |
| 136 | + | |
| 137 | + video-core1 { | |
| 138 | + compatible = "venus-encoder"; | |
| 139 | + }; | |
| 140 | + }; | |
| @@ -0,0 +1,156 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | + | |
| 3 | +%YAML 1.2 | |
| 4 | +--- | |
| 5 | +$id: "http://devicetree.org/schemas/media/qcom,sdm845-venus.yaml#" | |
| 6 | +$schema: "http://devicetree.org/meta-schemas/core.yaml#" | |
| 7 | + | |
| 8 | +title: Qualcomm Venus video encode and decode accelerators | |
| 9 | + | |
| 10 | +maintainers: | |
| 11 | + - Stanimir Varbanov <stanimir.varbanov@linaro.org> | |
| 12 | + | |
| 13 | +description: | | |
| 14 | + The Venus IP is a video encode and decode accelerator present | |
| 15 | + on Qualcomm platforms | |
| 16 | + | |
| 17 | +properties: | |
| 18 | + compatible: | |
| 19 | + const: qcom,sdm845-venus | |
| 20 | + | |
| 21 | + reg: | |
| 22 | + maxItems: 1 | |
| 23 | + | |
| 24 | + interrupts: | |
| 25 | + maxItems: 1 | |
| 26 | + | |
| 27 | + power-domains: | |
| 28 | + maxItems: 1 | |
| 29 | + | |
| 30 | + clocks: | |
| 31 | + maxItems: 3 | |
| 32 | + | |
| 33 | + clock-names: | |
| 34 | + items: | |
| 35 | + - const: core | |
| 36 | + - const: iface | |
| 37 | + - const: bus | |
| 38 | + | |
| 39 | + iommus: | |
| 40 | + maxItems: 2 | |
| 41 | + | |
| 42 | + memory-region: | |
| 43 | + maxItems: 1 | |
| 44 | + | |
| 45 | + video-core0: | |
| 46 | + type: object | |
| 47 | + | |
| 48 | + properties: | |
| 49 | + compatible: | |
| 50 | + const: venus-decoder | |
| 51 | + | |
| 52 | + clocks: | |
| 53 | + maxItems: 2 | |
| 54 | + | |
| 55 | + clock-names: | |
| 56 | + items: | |
| 57 | + - const: core | |
| 58 | + - const: bus | |
| 59 | + | |
| 60 | + power-domains: | |
| 61 | + maxItems: 1 | |
| 62 | + | |
| 63 | + required: | |
| 64 | + - compatible | |
| 65 | + - clocks | |
| 66 | + - clock-names | |
| 67 | + - power-domains | |
| 68 | + | |
| 69 | + additionalProperties: false | |
| 70 | + | |
| 71 | + video-core1: | |
| 72 | + type: object | |
| 73 | + | |
| 74 | + properties: | |
| 75 | + compatible: | |
| 76 | + const: venus-encoder | |
| 77 | + | |
| 78 | + clocks: | |
| 79 | + maxItems: 2 | |
| 80 | + | |
| 81 | + clock-names: | |
| 82 | + items: | |
| 83 | + - const: core | |
| 84 | + - const: bus | |
| 85 | + | |
| 86 | + power-domains: | |
| 87 | + maxItems: 1 | |
| 88 | + | |
| 89 | + required: | |
| 90 | + - compatible | |
| 91 | + - clocks | |
| 92 | + - clock-names | |
| 93 | + - power-domains | |
| 94 | + | |
| 95 | + additionalProperties: false | |
| 96 | + | |
| 97 | + video-firmware: | |
| 98 | + type: object | |
| 99 | + | |
| 100 | + description: | | |
| 101 | + Firmware subnode is needed when the platform does not | |
| 102 | + have TrustZone. | |
| 103 | + | |
| 104 | + properties: | |
| 105 | + iommus: | |
| 106 | + maxItems: 1 | |
| 107 | + | |
| 108 | + required: | |
| 109 | + - iommus | |
| 110 | + | |
| 111 | +required: | |
| 112 | + - compatible | |
| 113 | + - reg | |
| 114 | + - interrupts | |
| 115 | + - power-domains | |
| 116 | + - clocks | |
| 117 | + - clock-names | |
| 118 | + - iommus | |
| 119 | + - memory-region | |
| 120 | + - video-core0 | |
| 121 | + - video-core1 | |
| 122 | + | |
| 123 | +examples: | |
| 124 | + - | | |
| 125 | + #include <dt-bindings/interrupt-controller/arm-gic.h> | |
| 126 | + #include <dt-bindings/clock/qcom,videocc-sdm845.h> | |
| 127 | + | |
| 128 | + video-codec@aa00000 { | |
| 129 | + compatible = "qcom,sdm845-venus"; | |
| 130 | + reg = <0 0x0aa00000 0 0xff000>; | |
| 131 | + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; | |
| 132 | + clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>, | |
| 133 | + <&videocc VIDEO_CC_VENUS_AHB_CLK>, | |
| 134 | + <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>; | |
| 135 | + clock-names = "core", "iface", "bus"; | |
| 136 | + power-domains = <&videocc VENUS_GDSC>; | |
| 137 | + iommus = <&apps_smmu 0x10a0 0x8>, | |
| 138 | + <&apps_smmu 0x10b0 0x0>; | |
| 139 | + memory-region = <&venus_mem>; | |
| 140 | + | |
| 141 | + video-core0 { | |
| 142 | + compatible = "venus-decoder"; | |
| 143 | + clocks = <&videocc VIDEO_CC_VCODEC0_CORE_CLK>, | |
| 144 | + <&videocc VIDEO_CC_VCODEC0_AXI_CLK>; | |
| 145 | + clock-names = "core", "bus"; | |
| 146 | + power-domains = <&videocc VCODEC0_GDSC>; | |
| 147 | + }; | |
| 148 | + | |
| 149 | + video-core1 { | |
| 150 | + compatible = "venus-encoder"; | |
| 151 | + clocks = <&videocc VIDEO_CC_VCODEC1_CORE_CLK>, | |
| 152 | + <&videocc VIDEO_CC_VCODEC1_AXI_CLK>; | |
| 153 | + clock-names = "core", "bus"; | |
| 154 | + power-domains = <&videocc VCODEC1_GDSC>; | |
| 155 | + }; | |
| 156 | + }; | |
| @@ -1,120 +0,0 @@ | ||
| 1 | −* Qualcomm Venus video encoder/decoder accelerators | |
| 2 | − | |
| 3 | −- compatible: | |
| 4 | − Usage: required | |
| 5 | − Value type: <stringlist> | |
| 6 | − Definition: Value should contain one of: | |
| 7 | − - "qcom,msm8916-venus" | |
| 8 | − - "qcom,msm8996-venus" | |
| 9 | − - "qcom,sdm845-venus" | |
| 10 | −- reg: | |
| 11 | − Usage: required | |
| 12 | − Value type: <prop-encoded-array> | |
| 13 | − Definition: Register base address and length of the register map. | |
| 14 | −- interrupts: | |
| 15 | − Usage: required | |
| 16 | − Value type: <prop-encoded-array> | |
| 17 | − Definition: Should contain interrupt line number. | |
| 18 | −- clocks: | |
| 19 | − Usage: required | |
| 20 | − Value type: <prop-encoded-array> | |
| 21 | − Definition: A List of phandle and clock specifier pairs as listed | |
| 22 | − in clock-names property. | |
| 23 | −- clock-names: | |
| 24 | − Usage: required for msm8916 | |
| 25 | − Value type: <stringlist> | |
| 26 | − Definition: Should contain the following entries: | |
| 27 | − - "core" Core video accelerator clock | |
| 28 | − - "iface" Video accelerator AHB clock | |
| 29 | − - "bus" Video accelerator AXI clock | |
| 30 | −- clock-names: | |
| 31 | − Usage: required for msm8996 | |
| 32 | − Value type: <stringlist> | |
| 33 | − Definition: Should contain the following entries: | |
| 34 | − - "core" Core video accelerator clock | |
| 35 | − - "iface" Video accelerator AHB clock | |
| 36 | − - "bus" Video accelerator AXI clock | |
| 37 | − - "mbus" Video MAXI clock | |
| 38 | −- power-domains: | |
| 39 | − Usage: required | |
| 40 | − Value type: <prop-encoded-array> | |
| 41 | − Definition: A phandle and power domain specifier pairs to the | |
| 42 | − power domain which is responsible for collapsing | |
| 43 | − and restoring power to the peripheral. | |
| 44 | −- iommus: | |
| 45 | − Usage: required | |
| 46 | − Value type: <prop-encoded-array> | |
| 47 | − Definition: A list of phandle and IOMMU specifier pairs. | |
| 48 | −- memory-region: | |
| 49 | − Usage: required | |
| 50 | − Value type: <phandle> | |
| 51 | − Definition: reference to the reserved-memory for the firmware | |
| 52 | − memory region. | |
| 53 | − | |
| 54 | −* Subnodes | |
| 55 | −The Venus video-codec node must contain two subnodes representing | |
| 56 | −video-decoder and video-encoder, and one optional firmware subnode. | |
| 57 | −Firmware subnode is needed when the platform does not have TrustZone. | |
| 58 | − | |
| 59 | −Every of video-encoder or video-decoder subnode should have: | |
| 60 | − | |
| 61 | −- compatible: | |
| 62 | − Usage: required | |
| 63 | − Value type: <stringlist> | |
| 64 | − Definition: Value should contain "venus-decoder" or "venus-encoder" | |
| 65 | −- clocks: | |
| 66 | − Usage: required for msm8996 | |
| 67 | − Value type: <prop-encoded-array> | |
| 68 | − Definition: A List of phandle and clock specifier pairs as listed | |
| 69 | − in clock-names property. | |
| 70 | −- clock-names: | |
| 71 | − Usage: required for msm8996 | |
| 72 | − Value type: <stringlist> | |
| 73 | − Definition: Should contain the following entries: | |
| 74 | − - "core" Subcore video accelerator clock | |
| 75 | − | |
| 76 | −- power-domains: | |
| 77 | − Usage: required for msm8996 | |
| 78 | − Value type: <prop-encoded-array> | |
| 79 | − Definition: A phandle and power domain specifier pairs to the | |
| 80 | − power domain which is responsible for collapsing | |
| 81 | − and restoring power to the subcore. | |
| 82 | − | |
| 83 | −The firmware subnode must have: | |
| 84 | − | |
| 85 | −- iommus: | |
| 86 | − Usage: required | |
| 87 | − Value type: <prop-encoded-array> | |
| 88 | − Definition: A list of phandle and IOMMU specifier pairs. | |
| 89 | − | |
| 90 | −* An Example | |
| 91 | − video-codec@1d00000 { | |
| 92 | − compatible = "qcom,msm8916-venus"; | |
| 93 | − reg = <0x01d00000 0xff000>; | |
| 94 | − interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>; | |
| 95 | − clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>, | |
| 96 | − <&gcc GCC_VENUS0_AHB_CLK>, | |
| 97 | − <&gcc GCC_VENUS0_AXI_CLK>; | |
| 98 | − clock-names = "core", "iface", "bus"; | |
| 99 | − power-domains = <&gcc VENUS_GDSC>; | |
| 100 | − iommus = <&apps_iommu 5>; | |
| 101 | − memory-region = <&venus_mem>; | |
| 102 | − | |
| 103 | − video-decoder { | |
| 104 | − compatible = "venus-decoder"; | |
| 105 | − clocks = <&mmcc VIDEO_SUBCORE0_CLK>; | |
| 106 | − clock-names = "core"; | |
| 107 | − power-domains = <&mmcc VENUS_CORE0_GDSC>; | |
| 108 | − }; | |
| 109 | − | |
| 110 | − video-encoder { | |
| 111 | − compatible = "venus-encoder"; | |
| 112 | − clocks = <&mmcc VIDEO_SUBCORE1_CLK>; | |
| 113 | − clock-names = "core"; | |
| 114 | − power-domains = <&mmcc VENUS_CORE1_GDSC>; | |
| 115 | − }; | |
| 116 | − | |
| 117 | − video-firmware { | |
| 118 | − iommus = <&apps_iommu 0x10b2 0x0>; | |
| 119 | − }; | |
| 120 | − }; | |
| @@ -143,6 +143,7 @@ properties: · 142 unmodified lines | ||
| 143 | 143 | - rc-videomate-k100 |
| 144 | 144 | - rc-videomate-s350 |
| 145 | 145 | - rc-videomate-tv-pvr |
| 146 | + - rc-videostrong-kii-pro | |
| 146 | 147 | - rc-wetek-hub |
| 147 | 148 | - rc-wetek-play2 |
| 148 | 149 | - rc-winfast |
| @@ -59,6 +59,8 @@ required: · 58 unmodified lines | ||
| 59 | 59 | - interrupts |
| 60 | 60 | - port |
| 61 | 61 | |
| 62 | +additionalProperties: false | |
| 63 | + | |
| 62 | 64 | examples: |
| 63 | 65 | - | |
| 64 | 66 | #include <dt-bindings/interrupt-controller/arm-gic.h> |
| @@ -1,217 +0,0 @@ | ||
| 1 | −Renesas R-Car Video Input driver (rcar_vin) | |
| 2 | −------------------------------------------- | |
| 3 | − | |
| 4 | −The rcar_vin device provides video input capabilities for the Renesas R-Car | |
| 5 | −family of devices. | |
| 6 | − | |
| 7 | −Each VIN instance has a single parallel input that supports RGB and YUV video, | |
| 8 | −with both external synchronization and BT.656 synchronization for the latter. | |
| 9 | −Depending on the instance the VIN input is connected to external SoC pins, or | |
| 10 | −on Gen3 and RZ/G2 platforms to a CSI-2 receiver. | |
| 11 | − | |
| 12 | − - compatible: Must be one or more of the following | |
| 13 | − - "renesas,vin-r8a7743" for the R8A7743 device | |
| 14 | − - "renesas,vin-r8a7744" for the R8A7744 device | |
| 15 | − - "renesas,vin-r8a7745" for the R8A7745 device | |
| 16 | − - "renesas,vin-r8a77470" for the R8A77470 device | |
| 17 | − - "renesas,vin-r8a774a1" for the R8A774A1 device | |
| 18 | − - "renesas,vin-r8a774b1" for the R8A774B1 device | |
| 19 | − - "renesas,vin-r8a774c0" for the R8A774C0 device | |
| 20 | − - "renesas,vin-r8a7778" for the R8A7778 device | |
| 21 | − - "renesas,vin-r8a7779" for the R8A7779 device | |
| 22 | − - "renesas,vin-r8a7790" for the R8A7790 device | |
| 23 | − - "renesas,vin-r8a7791" for the R8A7791 device | |
| 24 | − - "renesas,vin-r8a7792" for the R8A7792 device | |
| 25 | − - "renesas,vin-r8a7793" for the R8A7793 device | |
| 26 | − - "renesas,vin-r8a7794" for the R8A7794 device | |
| 27 | − - "renesas,vin-r8a7795" for the R8A7795 device | |
| 28 | − - "renesas,vin-r8a7796" for the R8A7796 device | |
| 29 | − - "renesas,vin-r8a77965" for the R8A77965 device | |
| 30 | − - "renesas,vin-r8a77970" for the R8A77970 device | |
| 31 | − - "renesas,vin-r8a77980" for the R8A77980 device | |
| 32 | − - "renesas,vin-r8a77990" for the R8A77990 device | |
| 33 | − - "renesas,vin-r8a77995" for the R8A77995 device | |
| 34 | − - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible | |
| 35 | − device. | |
| 36 | − | |
| 37 | − When compatible with the generic version nodes must list the | |
| 38 | − SoC-specific version corresponding to the platform first | |
| 39 | − followed by the generic version. | |
| 40 | − | |
| 41 | − - reg: the register base and size for the device registers | |
| 42 | − - interrupts: the interrupt for the device | |
| 43 | − - clocks: Reference to the parent clock | |
| 44 | − | |
| 45 | −The per-board settings for Gen2 and RZ/G1 platforms: | |
| 46 | − | |
| 47 | −- port - sub-node describing a single endpoint connected to the VIN | |
| 48 | − from external SoC pins as described in video-interfaces.txt[1]. | |
| 49 | − Only the first one will be considered as each vin interface has one | |
| 50 | − input port. | |
| 51 | − | |
| 52 | − - Optional properties for endpoint nodes: | |
| 53 | − - hsync-active: see [1] for description. Default is active high. | |
| 54 | − - vsync-active: see [1] for description. Default is active high. | |
| 55 | − If both HSYNC and VSYNC polarities are not specified, embedded | |
| 56 | − synchronization is selected. | |
| 57 | − - field-active-even: see [1] for description. Default is active high. | |
| 58 | − - bus-width: see [1] for description. The selected bus width depends on | |
| 59 | − the SoC type and selected input image format. | |
| 60 | − Valid values are: 8, 10, 12, 16, 24 and 32. | |
| 61 | − - data-shift: see [1] for description. Valid values are 0 and 8. | |
| 62 | − - data-enable-active: polarity of CLKENB signal, see [1] for | |
| 63 | − description. Default is active high. | |
| 64 | − | |
| 65 | −The per-board settings for Gen3 and RZ/G2 platforms: | |
| 66 | − | |
| 67 | −Gen3 and RZ/G2 platforms can support both a single connected parallel input | |
| 68 | −source from external SoC pins (port@0) and/or multiple parallel input sources | |
| 69 | −from local SoC CSI-2 receivers (port@1) depending on SoC. | |
| 70 | − | |
| 71 | −- renesas,id - ID number of the VIN, VINx in the documentation. | |
| 72 | −- ports | |
| 73 | − - port@0 - sub-node describing a single endpoint connected to the VIN | |
| 74 | − from external SoC pins as described in video-interfaces.txt[1]. | |
| 75 | − Describing more than one endpoint in port@0 is invalid. Only VIN | |
| 76 | − instances that are connected to external pins should have port@0. | |
| 77 | − | |
| 78 | − Endpoint nodes of port@0 support the optional properties listed in | |
| 79 | − the Gen2 per-board settings description. | |
| 80 | − | |
| 81 | − - port@1 - sub-nodes describing one or more endpoints connected to | |
| 82 | − the VIN from local SoC CSI-2 receivers. The endpoint numbers must | |
| 83 | − use the following schema. | |
| 84 | − | |
| 85 | − - endpoint@0 - sub-node describing the endpoint connected to CSI20 | |
| 86 | − - endpoint@1 - sub-node describing the endpoint connected to CSI21 | |
| 87 | − - endpoint@2 - sub-node describing the endpoint connected to CSI40 | |
| 88 | − - endpoint@3 - sub-node describing the endpoint connected to CSI41 | |
| 89 | − | |
| 90 | − Endpoint nodes of port@1 do not support any optional endpoint property. | |
| 91 | − | |
| 92 | −Device node example for Gen2 platforms | |
| 93 | −-------------------------------------- | |
| 94 | − | |
| 95 | − aliases { | |
| 96 | − vin0 = &vin0; | |
| 97 | − }; | |
| 98 | − | |
| 99 | − vin0: vin@e6ef0000 { | |
| 100 | − compatible = "renesas,vin-r8a7790", "renesas,rcar-gen2-vin"; | |
| 101 | − clocks = <&mstp8_clks R8A7790_CLK_VIN0>; | |
| 102 | − reg = <0 0xe6ef0000 0 0x1000>; | |
| 103 | − interrupts = <0 188 IRQ_TYPE_LEVEL_HIGH>; | |
| 104 | − status = "disabled"; | |
| 105 | − }; | |
| 106 | − | |
| 107 | −Board setup example for Gen2 platforms (vin1 composite video input) | |
| 108 | −------------------------------------------------------------------- | |
| 109 | − | |
| 110 | −&i2c2 { | |
| 111 | − status = "okay"; | |
| 112 | − pinctrl-0 = <&i2c2_pins>; | |
| 113 | − pinctrl-names = "default"; | |
| 114 | − | |
| 115 | − adv7180@20 { | |
| 116 | − compatible = "adi,adv7180"; | |
| 117 | − reg = <0x20>; | |
| 118 | − remote = <&vin1>; | |
| 119 | − | |
| 120 | − port { | |
| 121 | − adv7180: endpoint { | |
| 122 | − bus-width = <8>; | |
| 123 | − remote-endpoint = <&vin1ep0>; | |
| 124 | − }; | |
| 125 | − }; | |
| 126 | − }; | |
| 127 | −}; | |
| 128 | − | |
| 129 | −/* composite video input */ | |
| 130 | −&vin1 { | |
| 131 | − pinctrl-0 = <&vin1_pins>; | |
| 132 | − pinctrl-names = "default"; | |
| 133 | − | |
| 134 | − status = "okay"; | |
| 135 | − | |
| 136 | − port { | |
| 137 | − vin1ep0: endpoint { | |
| 138 | − remote-endpoint = <&adv7180>; | |
| 139 | − bus-width = <8>; | |
| 140 | − }; | |
| 141 | − }; | |
| 142 | −}; | |
| 143 | − | |
| 144 | −Device node example for Gen3 platforms | |
| 145 | −-------------------------------------- | |
| 146 | − | |
| 147 | − vin0: video@e6ef0000 { | |
| 148 | − compatible = "renesas,vin-r8a7795"; | |
| 149 | − reg = <0 0xe6ef0000 0 0x1000>; | |
| 150 | − interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>; | |
| 151 | − clocks = <&cpg CPG_MOD 811>; | |
| 152 | − power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; | |
| 153 | − resets = <&cpg 811>; | |
| 154 | − renesas,id = <0>; | |
| 155 | − | |
| 156 | − ports { | |
| 157 | − #address-cells = <1>; | |
| 158 | − #size-cells = <0>; | |
| 159 | − | |
| 160 | − port@1 { | |
| 161 | − #address-cells = <1>; | |
| 162 | − #size-cells = <0>; | |
| 163 | − | |
| 164 | − reg = <1>; | |
| 165 | − | |
| 166 | − vin0csi20: endpoint@0 { | |
| 167 | − reg = <0>; | |
| 168 | − remote-endpoint= <&csi20vin0>; | |
| 169 | − }; | |
| 170 | − vin0csi21: endpoint@1 { | |
| 171 | − reg = <1>; | |
| 172 | − remote-endpoint= <&csi21vin0>; | |
| 173 | − }; | |
| 174 | − vin0csi40: endpoint@2 { | |
| 175 | − reg = <2>; | |
| 176 | − remote-endpoint= <&csi40vin0>; | |
| 177 | − }; | |
| 178 | − }; | |
| 179 | − }; | |
| 180 | − }; | |
| 181 | − | |
| 182 | − csi20: csi2@fea80000 { | |
| 183 | − compatible = "renesas,r8a7795-csi2"; | |
| 184 | − reg = <0 0xfea80000 0 0x10000>; | |
| 185 | − interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>; | |
| 186 | − clocks = <&cpg CPG_MOD 714>; | |
| 187 | − power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; | |
| 188 | − resets = <&cpg 714>; | |
| 189 | − | |
| 190 | − ports { | |
| 191 | − #address-cells = <1>; | |
| 192 | − #size-cells = <0>; | |
| 193 | − | |
| 194 | − port@0 { | |
| 195 | − reg = <0>; | |
| 196 | − csi20_in: endpoint { | |
| 197 | − clock-lanes = <0>; | |
| 198 | − data-lanes = <1>; | |
| 199 | − remote-endpoint = <&adv7482_txb>; | |
| 200 | − }; | |
| 201 | − }; | |
| 202 | − | |
| 203 | − port@1 { | |
| 204 | − #address-cells = <1>; | |
| 205 | − #size-cells = <0>; | |
| 206 | − | |
| 207 | − reg = <1>; | |
| 208 | − | |
| 209 | − csi20vin0: endpoint@0 { | |
| 210 | − reg = <0>; | |
| 211 | − remote-endpoint = <&vin0csi20>; | |
| 212 | − }; | |
| 213 | − }; | |
| 214 | − }; | |
| 215 | − }; | |
| 216 | − | |
| 217 | −[1] video-interfaces.txt common video media interface | |
| @@ -0,0 +1,402 @@ | ||
| 1 | +# SPDX-License-Identifier: GPL-2.0-only | |
| 2 | +# Copyright (C) 2020 Renesas Electronics Corp. | |
| 3 | +%YAML 1.2 | |
| 4 | +--- | |
| 5 | +$id: http://devicetree.org/schemas/media/renesas,vin.yaml# | |
| 6 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 7 | + | |
| 8 | +title: Renesas R-Car Video Input (VIN) | |
| 9 | + | |
| 10 | +maintainers: | |
| 11 | + - Niklas Söderlund <niklas.soderlund@ragnatech.se> | |
| 12 | + | |
| 13 | +description: | |
| 14 | + The R-Car Video Input (VIN) device provides video input capabilities for the | |
| 15 | + Renesas R-Car family of devices. | |
| 16 | + | |
| 17 | + Each VIN instance has a single parallel input that supports RGB and YUV video, | |
| 18 | + with both external synchronization and BT.656 synchronization for the latter. | |
| 19 | + Depending on the instance the VIN input is connected to external SoC pins, or | |
| 20 | + on Gen3 and RZ/G2 platforms to a CSI-2 receiver. | |
| 21 | + | |
| 22 | +properties: | |
| 23 | + compatible: | |
| 24 | + oneOf: | |
| 25 | + - items: | |
| 26 | + - enum: | |
| 27 | + - renesas,vin-r8a7743 # RZ/G1M | |
| 28 | + - renesas,vin-r8a7744 # RZ/G1N | |
| 29 | + - renesas,vin-r8a7745 # RZ/G1E | |
| 30 | + - renesas,vin-r8a77470 # RZ/G1C | |
| 31 | + - renesas,vin-r8a7790 # R-Car H2 | |
| 32 | + - renesas,vin-r8a7791 # R-Car M2-W | |
| 33 | + - renesas,vin-r8a7792 # R-Car V2H | |
| 34 | + - renesas,vin-r8a7793 # R-Car M2-N | |
| 35 | + - renesas,vin-r8a7794 # R-Car E2 | |
| 36 | + - const: renesas,rcar-gen2-vin # Generic R-Car Gen2 or RZ/G1 | |
| 37 | + | |
| 38 | + - items: | |
| 39 | + - enum: | |
| 40 | + - renesas,vin-r8a774a1 # RZ/G2M | |
| 41 | + - renesas,vin-r8a774b1 # RZ/G2N | |
| 42 | + - renesas,vin-r8a774c0 # RZ/G2E | |
| 43 | + - renesas,vin-r8a7778 # R-Car M1 | |
| 44 | + - renesas,vin-r8a7779 # R-Car H1 | |
| 45 | + - renesas,vin-r8a7795 # R-Car H3 | |
| 46 | + - renesas,vin-r8a7796 # R-Car M3-W | |
| 47 | + - renesas,vin-r8a77965 # R-Car M3-N | |
| 48 | + - renesas,vin-r8a77970 # R-Car V3M | |
| 49 | + - renesas,vin-r8a77980 # R-Car V3H | |
| 50 | + - renesas,vin-r8a77990 # R-Car E3 | |
| 51 | + - renesas,vin-r8a77995 # R-Car D3 | |
| 52 | + | |
| 53 | + reg: | |
| 54 | + maxItems: 1 | |
| 55 | + | |
| 56 | + interrupts: | |
| 57 | + maxItems: 1 | |
| 58 | + | |
| 59 | + clocks: | |
| 60 | + maxItems: 1 | |
| 61 | + | |
| 62 | + power-domains: | |
| 63 | + maxItems: 1 | |
| 64 | + | |
| 65 | + resets: | |
| 66 | + maxItems: 1 | |
| 67 | + | |
| 68 | + #The per-board settings for Gen2 and RZ/G1 platforms: | |
| 69 | + port: | |
| 70 | + type: object | |
| 71 | + description: | |
| 72 | + A node containing a parallel input with a single endpoint definitions as | |
| 73 | + documented in | |
| 74 | + Documentation/devicetree/bindings/media/video-interfaces.txt | |
| 75 | + | |
| 76 | + properties: | |
| 77 | + endpoint: | |
| 78 | + type: object | |
| 79 | + | |
| 80 | + properties: | |
| 81 | + hsync-active: | |
| 82 | + description: | |
| 83 | + If both HSYNC and VSYNC polarities are not specified, embedded | |
| 84 | + synchronization is selected. | |
| 85 | + default: 1 | |
| 86 | + | |
| 87 | + vsync-active: | |
| 88 | + description: | |
| 89 | + If both HSYNC and VSYNC polarities are not specified, embedded | |
| 90 | + synchronization is selected. | |
| 91 | + default: 1 | |
| 92 | + | |
| 93 | + field-active-even: true | |
| 94 | + | |
| 95 | + bus-width: true | |
| 96 | + | |
| 97 | + data-shift: true | |
| 98 | + | |
| 99 | + data-enable-active: | |
| 100 | + description: Polarity of CLKENB signal | |
| 101 | + default: 1 | |
| 102 | + | |
| 103 | + pclk-sample: true | |
| 104 | + | |
| 105 | + data-active: true | |
| 106 | + | |
| 107 | + remote-endpoint: true | |
| 108 | + | |
| 109 | + required: | |
| 110 | + - remote-endpoint | |
| 111 | + | |
| 112 | + additionalProperties: false | |
| 113 | + | |
| 114 | + additionalProperties: false | |
| 115 | + | |
| 116 | + #The per-board settings for Gen3 and RZ/G2 platforms: | |
| 117 | + renesas,id: | |
| 118 | + description: VIN channel number | |
| 119 | + allOf: | |
| 120 | + - $ref: /schemas/types.yaml#/definitions/uint32 | |
| 121 | + - minimum: 0 | |
| 122 | + - maximum: 15 | |
| 123 | + | |
| 124 | + ports: | |
| 125 | + type: object | |
| 126 | + description: | |
| 127 | + A node containing input nodes with endpoint definitions as documented in | |
| 128 | + Documentation/devicetree/bindings/media/video-interfaces.txt | |
| 129 | + | |
| 130 | + properties: | |
| 131 | + port@0: | |
| 132 | + type: object | |
| 133 | + description: | |
| 134 | + Input port node, single endpoint describing a parallel input source. | |
| 135 | + | |
| 136 | + properties: | |
| 137 | + reg: | |
| 138 | + const: 0 | |
| 139 | + | |
| 140 | + endpoint: | |
| 141 | + type: object | |
| 142 | + | |
| 143 | + properties: | |
| 144 | + hsync-active: | |
| 145 | + description: | |
| 146 | + If both HSYNC and VSYNC polarities are not specified, embedded | |
| 147 | + synchronization is selected. | |
| 148 | + default: 1 | |
| 149 | + | |
| 150 | + vsync-active: | |
| 151 | + description: | |
| 152 | + If both HSYNC and VSYNC polarities are not specified, embedded | |
| 153 | + synchronization is selected. | |
| 154 | + default: 1 | |
| 155 | + | |
| 156 | + field-active-even: true | |
| 157 | + | |
| 158 | + bus-width: true | |
| 159 | + | |
| 160 | + data-shift: true | |
| 161 | + | |
| 162 | + data-enable-active: | |
| 163 | + description: Polarity of CLKENB signal | |
| 164 | + default: 1 | |
| 165 | + | |
| 166 | + pclk-sample: true | |
| 167 | + | |
| 168 | + data-active: true | |
| 169 | + | |
| 170 | + remote-endpoint: true | |
| 171 | + | |
| 172 | + required: | |
| 173 | + - remote-endpoint | |
| 174 | + | |
| 175 | + additionalProperties: false | |
| 176 | + | |
| 177 | + required: | |
| 178 | + - endpoint | |
| 179 | + | |
| 180 | + additionalProperties: false | |
| 181 | + | |
| 182 | + port@1: | |
| 183 | + type: object | |
| 184 | + description: | |
| 185 | + Input port node, multiple endpoints describing all the R-Car CSI-2 | |
| 186 | + modules connected the VIN. | |
| 187 | + | |
| 188 | + properties: | |
| 189 | + '#address-cells': | |
| 190 | + const: 1 | |
| 191 | + | |
| 192 | + '#size-cells': | |
| 193 | + const: 0 | |
| 194 | + | |
| 195 | + reg: | |
| 196 | + const: 1 | |
| 197 | + | |
| 198 | + endpoint@0: | |
| 199 | + type: object | |
| 200 | + description: Endpoint connected to CSI20. | |
| 201 | + | |
| 202 | + properties: | |
| 203 | + reg: | |
| 204 | + const: 0 | |
| 205 | + | |
| 206 | + remote-endpoint: true | |
| 207 | + | |
| 208 | + required: | |
| 209 | + - reg | |
| 210 | + - remote-endpoint | |
| 211 | + | |
| 212 | + additionalProperties: false | |
| 213 | + | |
| 214 | + endpoint@1: | |
| 215 | + type: object | |
| 216 | + description: Endpoint connected to CSI21. | |
| 217 | + | |
| 218 | + properties: | |
| 219 | + reg: | |
| 220 | + const: 1 | |
| 221 | + | |
| 222 | + remote-endpoint: true | |
| 223 | + | |
| 224 | + required: | |
| 225 | + - reg | |
| 226 | + - remote-endpoint | |
| 227 | + | |
| 228 | + additionalProperties: false | |
| 229 | + | |
| 230 | + endpoint@2: | |
| 231 | + type: object | |
| 232 | + description: Endpoint connected to CSI40. | |
| 233 | + | |
| 234 | + properties: | |
| 235 | + reg: | |
| 236 | + const: 2 | |
| 237 | + | |
| 238 | + remote-endpoint: true | |
| 239 | + | |
| 240 | + required: | |
| 241 | + - reg | |
| 242 | + - remote-endpoint | |
| 243 | + | |
| 244 | + additionalProperties: false | |
| 245 | + | |
| 246 | + endpoint@3: | |
| 247 | + type: object | |
| 248 | + description: Endpoint connected to CSI41. | |
| 249 | + | |
| 250 | + properties: | |
| 251 | + reg: | |
| 252 | + const: 3 | |
| 253 | + | |
| 254 | + remote-endpoint: true | |
| 255 | + | |
| 256 | + required: | |
| 257 | + - reg | |
| 258 | + - remote-endpoint | |
| 259 | + | |
| 260 | + additionalProperties: false | |
| 261 | + | |
| 262 | + anyOf: | |
| 263 | + - required: | |
| 264 | + - endpoint@0 | |
| 265 | + - required: | |
| 266 | + - endpoint@1 | |
| 267 | + - required: | |
| 268 | + - endpoint@2 | |
| 269 | + - required: | |
| 270 | + - endpoint@3 | |
| 271 | + | |
| 272 | + additionalProperties: false | |
| 273 | + | |
| 274 | +required: | |
| 275 | + - compatible | |
| 276 | + - reg | |
| 277 | + - interrupts | |
| 278 | + - clocks | |
| 279 | + - power-domains | |
| 280 | + - resets | |
| 281 | + | |
| 282 | +if: | |
| 283 | + properties: | |
| 284 | + compatible: | |
| 285 | + contains: | |
| 286 | + enum: | |
| 287 | + - renesas,vin-r8a7778 | |
| 288 | + - renesas,vin-r8a7779 | |
| 289 | + - renesas,rcar-gen2-vin | |
| 290 | +then: | |
| 291 | + required: | |
| 292 | + - port | |
| 293 | +else: | |
| 294 | + required: | |
| 295 | + - renesas,id | |
| 296 | + - ports | |
| 297 | + | |
| 298 | +additionalProperties: false | |
| 299 | + | |
| 300 | +examples: | |
| 301 | + # Device node example for Gen2 platform | |
| 302 | + - | | |
| 303 | + #include <dt-bindings/clock/r8a7790-cpg-mssr.h> | |
| 304 | + #include <dt-bindings/interrupt-controller/arm-gic.h> | |
| 305 | + #include <dt-bindings/power/r8a7790-sysc.h> | |
| 306 | + | |
| 307 | + vin1: vin@e6ef1000 { | |
| 308 | + compatible = "renesas,vin-r8a7790", | |
| 309 | + "renesas,rcar-gen2-vin"; | |
| 310 | + reg = <0 0xe6ef1000 0 0x1000>; | |
| 311 | + interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>; | |
| 312 | + clocks = <&cpg CPG_MOD 810>; | |
| 313 | + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; | |
| 314 | + resets = <&cpg 810>; | |
| 315 | + | |
| 316 | + port { | |
| 317 | + vin1ep0: endpoint { | |
| 318 | + remote-endpoint = <&adv7180>; | |
| 319 | + bus-width = <8>; | |
| 320 | + }; | |
| 321 | + }; | |
| 322 | + }; | |
| 323 | + | |
| 324 | + # Device node example for Gen3 platform with only CSI-2 | |
| 325 | + - | | |
| 326 | + #include <dt-bindings/clock/r8a7795-cpg-mssr.h> | |
| 327 | + #include <dt-bindings/interrupt-controller/arm-gic.h> | |
| 328 | + #include <dt-bindings/power/r8a7795-sysc.h> | |
| 329 | + | |
| 330 | + vin0: video@e6ef0000 { | |
| 331 | + compatible = "renesas,vin-r8a7795"; | |
| 332 | + reg = <0 0xe6ef0000 0 0x1000>; | |
| 333 | + interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>; | |
| 334 | + clocks = <&cpg CPG_MOD 811>; | |
| 335 | + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; | |
| 336 | + resets = <&cpg 811>; | |
| 337 | + renesas,id = <0>; | |
| 338 | + | |
| 339 | + ports { | |
| 340 | + #address-cells = <1>; | |
| 341 | + #size-cells = <0>; | |
| 342 | + | |
| 343 | + port@1 { | |
| 344 | + #address-cells = <1>; | |
| 345 | + #size-cells = <0>; | |
| 346 | + | |
| 347 | + reg = <1>; | |
| 348 | + | |
| 349 | + vin0csi20: endpoint@0 { | |
| 350 | + reg = <0>; | |
| 351 | + remote-endpoint= <&csi20vin0>; | |
| 352 | + }; | |
| 353 | + vin0csi40: endpoint@2 { | |
| 354 | + reg = <2>; | |
| 355 | + remote-endpoint= <&csi40vin0>; | |
| 356 | + }; | |
| 357 | + }; | |
| 358 | + }; | |
| 359 | + }; | |
| 360 | + | |
| 361 | + # Device node example for Gen3 platform with CSI-2 and parallel | |
| 362 | + - | | |
| 363 | + #include <dt-bindings/clock/r8a77970-cpg-mssr.h> | |
| 364 | + #include <dt-bindings/interrupt-controller/arm-gic.h> | |
| 365 | + #include <dt-bindings/power/r8a77970-sysc.h> | |
| 366 | + | |
| 367 | + vin2: video@e6ef2000 { | |
| 368 | + compatible = "renesas,vin-r8a77970"; | |
| 369 | + reg = <0 0xe6ef2000 0 0x1000>; | |
| 370 | + interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>; | |
| 371 | + clocks = <&cpg CPG_MOD 809>; | |
| 372 | + power-domains = <&sysc R8A77970_PD_ALWAYS_ON>; | |
| 373 | + resets = <&cpg 809>; | |
| 374 | + renesas,id = <2>; | |
| 375 | + | |
| 376 | + ports { | |
| 377 | + #address-cells = <1>; | |
| 378 | + #size-cells = <0>; | |
| 379 | + | |
| 380 | + port@0 { | |
| 381 | + reg = <0>; | |
| 382 | + | |
| 383 | + vin2_in: endpoint { | |
| 384 | + remote-endpoint = <&adv7612_out>; | |
| 385 | + hsync-active = <0>; | |
| 386 | + vsync-active = <0>; | |
| 387 | + }; | |
| 388 | + }; | |
| 389 | + | |
| 390 | + port@1 { | |
| 391 | + #address-cells = <1>; | |
| 392 | + #size-cells = <0>; | |
| 393 | + | |
| 394 | + reg = <1>; | |
| 395 | + | |
| 396 | + vin2csi40: endpoint@2 { | |
| 397 | + reg = <2>; | |
| 398 | + remote-endpoint = <&csi40vin2>; | |
| 399 | + }; | |
| 400 | + }; | |
| 401 | + }; | |
| 402 | + }; | |
| @@ -6,8 +6,9 @@ BitBLT, alpha blending and image blur/sharpness. · 5 unmodified lines | ||
| 6 | 6 | |
| 7 | 7 | Required properties: |
| 8 | 8 | - compatible: value should be one of the following |
| 9 | − "rockchip,rk3288-rga"; | |
| 10 | − "rockchip,rk3399-rga"; | |
| 9 | + "rockchip,rk3228-rga", "rockchip,rk3288-rga": for Rockchip RK3228 | |
| 10 | + "rockchip,rk3288-rga": for Rockchip RK3288 | |
| 11 | + "rockchip,rk3399-rga": for Rockchip RK3399 | |
| 11 | 12 | |
| 12 | 13 | - interrupts: RGA interrupt specifier. |
| 13 | 14 | |
| @@ -0,0 +1,179 @@ | ||
| 1 | +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) | |
| 2 | +%YAML 1.2 | |
| 3 | +--- | |
| 4 | +$id: http://devicetree.org/schemas/mfd/iqs62x.yaml# | |
| 5 | +$schema: http://devicetree.org/meta-schemas/core.yaml# | |
| 6 | + | |
| 7 | +title: Azoteq IQS620A/621/622/624/625 Multi-Function Sensors | |
| 8 | + | |
| 9 | +maintainers: | |
| 10 | + - Jeff LaBundy <jeff@labundy.com> | |
| 11 | + | |
| 12 | +description: | | |
| 13 | + The Azoteq IQS620A, IQS621, IQS622, IQS624 and IQS625 multi-function sensors | |
| 14 | + integrate multiple sensing technologies in a single package. | |
| 15 | + | |
| 16 | + Link to datasheets: https://www.azoteq.com/ | |
| 17 | + | |
| 18 | +properties: | |
| 19 | + compatible: | |
| 20 | + enum: | |
| 21 | + - azoteq,iqs620a | |
| 22 | + - azoteq,iqs621 | |
| 23 | + - azoteq,iqs622 | |
| 24 | + - azoteq,iqs624 | |
| 25 | + - azoteq,iqs625 | |
| 26 | + | |
| 27 | + reg: | |
| 28 | + maxItems: 1 | |
| 29 | + | |
| 30 | + interrupts: | |
| 31 | + maxItems: 1 | |
148 more 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 19 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 237 lines aren’t shown here.
This diff is large: its 223 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 340 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 144 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 34 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 100 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 17 lines aren’t shown here.
This diff is large: its 149 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 145 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 19 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 117 lines aren’t shown here.
This diff is large: its 14 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 9 lines aren’t shown here.
This diff is large: its 199 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 60 lines aren’t shown here.
This diff is large: its 226 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 173 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 36 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 144 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 156 lines aren’t shown here.
This diff is large: its 186 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 84 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 54 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 8 lines aren’t shown here.
This diff is large: its 24 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 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 37 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 154 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 36 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 74 lines aren’t shown here.
This diff is large: its 9 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 46 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 41 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 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 28 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 163 lines aren’t shown here.
This diff is large: its 104 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 325 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 64 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 62 lines aren’t shown here.
This diff is large: its 38 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 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 20 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 136 lines aren’t shown here.
This diff is large: its 151 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 173 lines aren’t shown here.
This diff is large: its 108 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 132 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 47 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 48 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 9 lines aren’t shown here.
This diff is large: its 114 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 114 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 70 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 93 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 112 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 9 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 81 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 18 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 108 lines aren’t shown here.
This diff is large: its 48 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 16 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 140 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 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 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 35 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 77 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 9 lines aren’t shown here.
This diff is large: its 191 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 136 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 22 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 12 lines aren’t shown here.
This diff is large: its 107 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 18 lines aren’t shown here.
This diff is large: its 22 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.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 206 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 153 lines aren’t shown here.
This diff is large: its 219 lines aren’t shown here.
This diff is large: its 150 lines aren’t shown here.
This diff is large: its 137 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 197 lines aren’t shown here.
This diff is large: its 55 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 293 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 502 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 11 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 318 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 257 lines aren’t shown here.
This diff is large: its 174 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 212 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 144 lines aren’t shown here.
This diff is large: its 269 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 113 lines aren’t shown here.
This diff is large: its 107 lines aren’t shown here.
This diff is large: its 410 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 2225 lines aren’t shown here.
This diff is large: its 129 lines aren’t shown here.
This diff is large: its 116 lines aren’t shown here.
This diff is large: its 219 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 504 lines aren’t shown here.
This diff is large: its 280 lines aren’t shown here.
This diff is large: its 124 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 215 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 576 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 409 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 179 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 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 51 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 88 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 18 lines aren’t shown here.
This diff is large: its 488 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 348 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 199 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 7 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 44 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 79 lines aren’t shown here.
This diff is large: its 139 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 44 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 119 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 219 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 131 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
File renamed without changes.
File renamed without changes.
File renamed without changes.
This diff is large: its 177 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 94 lines aren’t shown here.
This diff is large: its 189 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 49 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 13 lines aren’t shown here.
This diff is large: its 544 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 21 lines aren’t shown here.
This diff is large: its 160 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 127 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 62 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 164 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 174 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 40 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 9 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 278 lines aren’t shown here.
This diff is large: its 177 lines aren’t shown here.
This diff is large: its 164 lines aren’t shown here.
This diff is large: its 165 lines aren’t shown here.
This diff is large: its 129 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 214 lines aren’t shown here.
This diff is large: its 147 lines aren’t shown here.
This diff is large: its 594 lines aren’t shown here.
This diff is large: its 498 lines aren’t shown here.
This diff is large: its 459 lines aren’t shown here.
This diff is large: its 395 lines aren’t shown here.
This diff is large: its 908 lines aren’t shown here.
This diff is large: its 575 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 130 lines aren’t shown here.
This diff is large: its 93 lines aren’t shown here.
This diff is large: its 84 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 144 lines aren’t shown here.
This diff is large: its 135 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 518 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 2751 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 49 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 129 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 472 lines aren’t shown here.
This diff is large: its 421 lines aren’t shown here.
This diff is large: its 1314 lines aren’t shown here.
This diff is large: its 1281 lines aren’t shown here.
This diff is large: its 8 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 23 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 554 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 1613 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 196 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 20 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 130 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 223 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 264 lines aren’t shown here.
This diff is large: its 162 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 28 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 15 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 62 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 206 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 25 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 117 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 15732 lines aren’t shown here.
This diff is large: its 230 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 46 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 19 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 16 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 38 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 8 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 13 lines aren’t shown here.
This diff is large: its 109 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 21 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 27 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 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 29 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 35 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 27 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 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 16 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 18 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 33 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 18 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 302 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 160 lines aren’t shown here.
This diff is large: its 232 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 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 9 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 9 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 76 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is 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 88 lines aren’t shown here.
This diff is large: its 38 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 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 293 lines aren’t shown here.
This diff is large: its 218 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 254 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 27 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 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 16 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 64 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 66 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 14 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 31 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 24 lines aren’t shown here.
This diff is large: its 55 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 21 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 19 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 47 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 27 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 47 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 24 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 27 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 52 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 46 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 618 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 9 lines aren’t shown here.
This diff is large: its 107 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 667 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 48 lines aren’t shown here.
This diff is large: its 54 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 53 lines aren’t shown here.
This diff is large: its 62 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 170 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 277 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 21 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 46 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 165 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 8 lines aren’t shown here.
This diff is large: its 342 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 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 30 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 298 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 261 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 30 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 298 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 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 10 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 13 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 133 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 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 51 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 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 69 lines aren’t shown here.
This diff is large: its 105 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 15 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 87 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 14 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 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 582 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 118 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 266 lines aren’t shown here.
This diff is large: its 369 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 258 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 156 lines aren’t shown here.
This diff is large: its 39 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 40 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 22 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 17 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 22 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 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 213 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 45 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 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 18 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 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 47 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 8 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 123 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 6 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 23 lines aren’t shown here.
This diff is large: its 135 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 8 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 240 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 373 lines aren’t shown here.
This diff is large: its 457 lines aren’t shown here.
This diff is large: its 128 lines aren’t shown here.
This diff is large: its 436 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 11 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 45 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 76 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 49 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 315 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 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 13 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 1456 lines aren’t shown here.
This diff is large: its 131 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 167 lines aren’t shown here.
This diff is large: its 388 lines aren’t shown here.
This diff is large: its 176 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 122 lines aren’t shown here.
This diff is large: its 296 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 243 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 158 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 87 lines aren’t shown here.
This diff is large: its 87 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 3 lines aren’t shown here.
This diff is large: its 8 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 11 lines aren’t shown here.
This diff is large: its 305 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 9 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 25 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 45 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 30 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 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 33 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 35 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 3 lines aren’t shown here.
This diff is large: its 30 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 9 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 36 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 160 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 155 lines aren’t shown here.
This diff is large: its 606 lines aren’t shown here.
This diff is large: its 309 lines aren’t shown here.
This diff is large: its 272 lines aren’t shown here.
This diff is large: its 268 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 221 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 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 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 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 32 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 53 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 8 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 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 23 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 90 lines aren’t shown here.
This diff is large: its 213 lines aren’t shown here.
This diff is large: its 133 lines aren’t shown here.
This diff is large: its 51 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 128 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 23 lines aren’t shown here.
This diff is large: its 198 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 122 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 127 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 283 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 380 lines aren’t shown here.
This diff is large: its 461 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 95 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 19 lines aren’t shown here.
This diff is large: its 179 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 9 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 9 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 10 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 63 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 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 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 20 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 118 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 188 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 321 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 32 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 51 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 175 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 167 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 203 lines aren’t shown here.
This diff is large: its 271 lines aren’t shown here.
This diff is large: its 932 lines aren’t shown here.
This diff is large: its 655 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 239 lines aren’t shown here.
This diff is large: its 132 lines aren’t shown here.
This diff is large: its 67 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 16 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 19 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 10 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 5 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 17 lines aren’t shown here.
This diff is large: its 116 lines aren’t shown here.
This diff is large: its 664 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 458 lines aren’t shown here.
This diff is large: its 222 lines aren’t shown here.
This diff is large: its 22 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 26 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 306 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 95 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 54 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 14 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 444 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 70 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 74 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 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 12 lines aren’t shown here.
This diff is large: its 122 lines aren’t shown here.
This diff is large: its 859 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 352 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 797 lines aren’t shown here.
This diff is large: its 140 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 445 lines aren’t shown here.
This diff is large: its 24 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 18 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 21 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 117 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 20 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 91 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 8 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 17 lines aren’t shown here.
This diff is large: its 312 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 74 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 1097 lines aren’t shown here.
This diff is 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 53 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 69 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 139 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 87 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 61 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 446 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 174 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 15 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 44 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 28 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 30 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 25 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 211 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 19 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 10 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 32 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 22 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 87 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 33 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 25 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 9 lines aren’t shown here.
This diff is large: its 53 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 16 lines aren’t shown here.
This diff is large: its 3 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 37 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 32 lines aren’t shown here.
This diff is large: its 287 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 114 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 156 lines aren’t shown here.
This diff is large: its 346 lines aren’t shown here.
This diff is large: its 283 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 28 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 523 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 69 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 16 lines aren’t shown here.
This diff is large: its 358 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 192 lines aren’t shown here.
This diff is large: its 3 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 4 lines aren’t shown here.
This diff is large: its 19 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 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 62 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 96 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 137 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 9 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 20 lines aren’t shown here.
This diff is large: its 431 lines aren’t shown here.
This diff is large: its 164 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 12 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 44 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 81 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 73 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 49 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 25 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 68 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 34 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 42 lines aren’t shown here.
This diff is large: its 69 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 50 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 500 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 399 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 110 lines aren’t shown here.
This diff is large: its 96 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 60 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 16 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 32 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 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 18 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 16 lines aren’t shown here.
This diff is large: its 12 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 4 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 31 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 32 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 19 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 68 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 34 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 34 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 34 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 34 lines aren’t shown here.
This diff is large: its 14 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 65 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 130 lines aren’t shown here.
This diff is large: its 73 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 16 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 303 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 12 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 2 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 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 15 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 19 lines aren’t shown here.
This diff is large: its 2 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 11 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 11 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 24 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 15 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 22 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 11 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 20 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 13 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 3 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 16 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 21 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 25 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 30 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 4 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 144 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 65 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 27 lines aren’t shown here.
This diff is large: its 3 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 30 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 10 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 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 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 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 335 lines aren’t shown here.
This diff is 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 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 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 8 lines aren’t shown here.
This diff is large: its 96 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 16 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 21 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 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 179 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 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 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 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 17 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 17 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 69 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 66 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 25 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 21 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 36 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 37 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 163 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 75 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 70 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 35 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 25 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 48 lines aren’t shown here.
This diff is large: its 36 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 50 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 24 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 11 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 23 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 10 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 3 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 17 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 46 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 5 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 10 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 216 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 56 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 7 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 34 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 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 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 36 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 13 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 45 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 19 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 12 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 12 lines aren’t shown here.
This diff is large: its 20 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 20 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 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 16 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 26 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 12 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 25 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 32 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 4 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 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 181 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 1042 lines aren’t shown here.
This diff is large: its 319 lines aren’t shown here.
This diff is large: its 2928 lines aren’t shown here.
This diff is large: its 182 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 317 lines aren’t shown here.
This diff is large: its 105 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 10 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 24 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 193 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 3469 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 493 lines aren’t shown here.
This diff is large: its 129 lines aren’t shown here.
This diff is large: its 185 lines aren’t shown here.
This diff is large: its 266 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 852 lines aren’t shown here.
This diff is large: its 905 lines aren’t shown here.
This diff is large: its 152 lines aren’t shown here.
This diff is large: its 482 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 13 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 171 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 147 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 378 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 527 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 41 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 4 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 10 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 54 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 184 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 185 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 68 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 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 109 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 12 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 77 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 33 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 67 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 32 lines aren’t shown here.
This diff is large: its 61 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 47 lines aren’t shown here.
This diff is large: its 156 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 372 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 197 lines aren’t shown here.
This diff is large: its 175 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 302 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 31 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 4 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 45 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 102 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 18 lines aren’t shown here.
This diff is large: its 73 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 7 lines aren’t shown here.
This diff is large: its 134 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 18 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 9 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 184 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 58 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 36 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 124 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 76 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 9 lines aren’t shown here.
This diff is large: its 17 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 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 10 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 104 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 228 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 24 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 116 lines aren’t shown here.
This diff is large: its 44 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 220 lines aren’t shown here.
This diff is large: its 121 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 591 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 113 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 63 lines aren’t shown here.
This diff is large: its 371 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 69 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 17 lines aren’t shown here.
This diff is large: its 30 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 188 lines aren’t shown here.
This diff is large: its 318 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 515 lines aren’t shown here.
This diff is large: its 1311 lines aren’t shown here.
This diff is large: its 670 lines aren’t shown here.
This diff is large: its 167 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 5 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 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 22 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 7 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 252 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 73 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 316 lines aren’t shown here.
This diff is large: its 3 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 9 lines aren’t shown here.
This diff is large: its 163 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 135 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 146 lines aren’t shown here.
This diff is large: its 85 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 62 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 241 lines aren’t shown here.
This diff is large: its 277 lines aren’t shown here.
This diff is large: its 104 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 415 lines aren’t shown here.
This diff is large: its 3 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 20 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 182 lines aren’t shown here.
This diff is large: its 666 lines aren’t shown here.
This diff is large: its 1030 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 304 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 190 lines aren’t shown here.
This diff is large: its 147 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 137 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 578 lines aren’t shown here.
This diff is large: its 175 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 352 lines aren’t shown here.
This diff is large: its 62 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 5 lines aren’t shown here.
This diff is large: its 4 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 5 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 23 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 18 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 3 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 3 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 20 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 10 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 17 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 3 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 8 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 7 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 3 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 32 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 63 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 27 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 305 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 24 lines aren’t shown here.
This diff is large: its 85 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 25 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 630 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 52 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 5 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 10 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 25 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 91 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 5 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 20 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 160 lines aren’t shown here.
This diff is large: its 342 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 193 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 188 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 191 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 3667 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 41 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 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 33 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 32 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 38 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 36 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 844 lines aren’t shown here.
This diff is large: its 768 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 19 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 106 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 68 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 74 lines aren’t shown here.
This diff is large: its 106 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 170 lines aren’t shown here.
This diff is large: its 564 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 407 lines aren’t shown here.
This diff is large: its 6 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 18 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 141 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 140 lines aren’t shown here.
This diff is large: its 60 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 282 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 22 lines aren’t shown here.
This diff is large: its 33 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 21 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 147 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 32 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 13 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 366 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 446 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 120 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 11 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 29 lines aren’t shown here.
This diff is large: its 25 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 5 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 10 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 11 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 50 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 54 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 238 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 121 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 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 292 lines aren’t shown here.
This diff is large: its 148 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 37 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 60 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 12 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 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 26 lines aren’t shown here.
This diff is large: its 590 lines aren’t shown here.
This diff is large: its 333 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 208 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 46 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 211 lines aren’t shown here.
This diff is large: its 9 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 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 1238 lines aren’t shown here.
This diff is large: its 218 lines aren’t shown here.
This diff is large: its 111 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 18 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 314 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 562 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 1028 lines aren’t shown here.
This diff is large: its 824 lines aren’t shown here.
File renamed without changes.
This diff is large: its 1188 lines aren’t shown here.
This diff is large: its 6783 lines aren’t shown here.
This diff is large: its 492 lines aren’t shown here.
This diff is large: its 163 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 467 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 123 lines aren’t shown here.
This diff is large: its 1226 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 2385 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 124 lines aren’t shown here.
This diff is large: its 156 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 47 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 103 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 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 329 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 493 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 48 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 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 3 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 30 lines aren’t shown here.
This diff is large: its 20 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 27 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is 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 71 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 4 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 37 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 17 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 153 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 662 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 186 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 515 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 157 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 178 lines aren’t shown here.
This diff is large: its 365 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 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 3 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 199 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 4 lines aren’t shown here.
This diff is large: its 401 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 8 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 30 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 304 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 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 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 7 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 6 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 75 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 160 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 71 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 112 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 96 lines aren’t shown here.
This diff is large: its 66 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 18 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 43 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 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 9 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 97 lines aren’t shown here.
This diff is large: its 19 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 21 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 20 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 66 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 22 lines aren’t shown here.
This diff is large: its 487 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 47 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 59 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 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 141 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 318 lines aren’t shown here.
This diff is large: its 470 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 118 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 1625 lines aren’t shown here.
This diff is large: its 338 lines aren’t shown here.
This diff is large: its 193 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 1484 lines aren’t shown here.
This diff is large: its 748 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 54 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 69 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 128 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 220 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 147 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 15 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 281 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 87 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 17 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 40 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 2521 lines aren’t shown here.
This diff is large: its 136 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 222 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 387 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 46 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 122 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 24 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 70 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 172 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 393 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 68 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 508 lines aren’t shown here.
This diff is large: its 1294 lines aren’t shown here.
This diff is large: its 688 lines aren’t shown here.
This diff is large: its 1530 lines aren’t shown here.
This diff is large: its 970 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 902 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.