diff --git a/.clang-format b/.clang-format index 2ffd69afc1a8..196ca317bd1f 100644 --- a/.clang-format +++ b/.clang-format @@ -107,10 +107,13 @@ ForEachMacros: - 'css_for_each_descendant_post' - 'css_for_each_descendant_pre' - 'device_for_each_child_node' + - 'dma_fence_chain_for_each' - 'drm_atomic_crtc_for_each_plane' - 'drm_atomic_crtc_state_for_each_plane' - 'drm_atomic_crtc_state_for_each_plane_state' - 'drm_atomic_for_each_plane_damage' + - 'drm_client_for_each_connector_iter' + - 'drm_client_for_each_modeset' - 'drm_connector_for_each_possible_encoder' - 'drm_for_each_connector_iter' - 'drm_for_each_crtc' @@ -126,6 +129,7 @@ ForEachMacros: - 'drm_mm_for_each_node_in_range' - 'drm_mm_for_each_node_safe' - 'flow_action_for_each' + - 'for_each_active_dev_scope' - 'for_each_active_drhd_unit' - 'for_each_active_iommu' - 'for_each_available_child_of_node' @@ -153,6 +157,8 @@ ForEachMacros: - 'for_each_cpu_not' - 'for_each_cpu_wrap' - 'for_each_dev_addr' + - 'for_each_dev_scope' + - 'for_each_displayid_db' - 'for_each_dma_cap_mask' - 'for_each_dpcm_be' - 'for_each_dpcm_be_rollback' @@ -169,6 +175,8 @@ ForEachMacros: - 'for_each_evictable_lru' - 'for_each_fib6_node_rt_rcu' - 'for_each_fib6_walker_rt' + - 'for_each_free_mem_pfn_range_in_zone' + - 'for_each_free_mem_pfn_range_in_zone_from' - 'for_each_free_mem_range' - 'for_each_free_mem_range_reverse' - 'for_each_func_rsrc' @@ -178,6 +186,7 @@ ForEachMacros: - 'for_each_ip_tunnel_rcu' - 'for_each_irq_nr' - 'for_each_link_codecs' + - 'for_each_link_platforms' - 'for_each_lru' - 'for_each_matching_node' - 'for_each_matching_node_and_match' @@ -302,7 +311,10 @@ ForEachMacros: - 'ide_port_for_each_present_dev' - 'idr_for_each_entry' - 'idr_for_each_entry_continue' + - 'idr_for_each_entry_continue_ul' - 'idr_for_each_entry_ul' + - 'in_dev_for_each_ifa_rcu' + - 'in_dev_for_each_ifa_rtnl' - 'inet_bind_bucket_for_each' - 'inet_lhash2_for_each_icsk_rcu' - 'key_for_each' @@ -343,8 +355,6 @@ ForEachMacros: - 'media_device_for_each_intf' - 'media_device_for_each_link' - 'media_device_for_each_pad' - - 'mp_bvec_for_each_page' - - 'mp_bvec_for_each_segment' - 'nanddev_io_for_each_page' - 'netdev_for_each_lower_dev' - 'netdev_for_each_lower_private' @@ -381,18 +391,19 @@ ForEachMacros: - 'radix_tree_for_each_slot' - 'radix_tree_for_each_tagged' - 'rbtree_postorder_for_each_entry_safe' + - 'rdma_for_each_block' - 'rdma_for_each_port' - 'resource_list_for_each_entry' - 'resource_list_for_each_entry_safe' - 'rhl_for_each_entry_rcu' - 'rhl_for_each_rcu' - 'rht_for_each' - - 'rht_for_each_from' - 'rht_for_each_entry' - 'rht_for_each_entry_from' - 'rht_for_each_entry_rcu' - 'rht_for_each_entry_rcu_from' - 'rht_for_each_entry_safe' + - 'rht_for_each_from' - 'rht_for_each_rcu' - 'rht_for_each_rcu_from' - '__rq_for_each_bio' diff --git a/.gitignore b/.gitignore index 2030c7a4d2f8..70580bdd352c 100644 --- a/.gitignore +++ b/.gitignore @@ -32,9 +32,9 @@ *.lzo *.mod *.mod.c +*.ns_deps *.o *.o.* -*.order *.patch *.s *.so @@ -46,6 +46,7 @@ *.xz Module.symvers modules.builtin +modules.order # # Top-level generic files diff --git a/.mailmap b/.mailmap index acba1a6163f1..edcac87e76c8 100644 --- a/.mailmap +++ b/.mailmap @@ -47,6 +47,8 @@ Boris Brezillon Boris Brezillon Brian Avery Brian King +Chao Yu +Chao Yu Christoph Hellwig Christophe Ricard Corey Minyard @@ -63,7 +65,11 @@ Dengcheng Zhu Dengcheng Zhu Dengcheng Zhu Dengcheng Zhu + Dmitry Eremin-Solenikov +Dmitry Safonov <0x7f454c46@gmail.com> +Dmitry Safonov <0x7f454c46@gmail.com> +Dmitry Safonov <0x7f454c46@gmail.com> Domen Puncer Douglas Gilbert Ed L. Cashin @@ -77,6 +83,8 @@ Frank Rowand Frank Rowand Frank Rowand Frank Zago +Gao Xiang +Gao Xiang Greg Kroah-Hartman Greg Kroah-Hartman Greg Kroah-Hartman @@ -87,6 +95,9 @@ Henrik Kretzschmar Henrik Rydberg Herbert Xu Jacob Shin +Jaegeuk Kim +Jaegeuk Kim +Jaegeuk Kim James Bottomley James Bottomley James E Wilson @@ -160,6 +171,8 @@ Matt Ranostay Matthew Ranostay Matt Ranostay Matt Redfearn +Maxime Ripard +Maxime Ripard Mayuresh Janorkar Michael Buesch Michel Dänzer @@ -173,8 +186,14 @@ Morten Welinder Morten Welinder Mythri P K Nguyen Anh Quynh +Nicolas Ferre Nicolas Pitre Nicolas Pitre +Oleksij Rempel +Oleksij Rempel +Oleksij Rempel +Oleksij Rempel +Oleksij Rempel Paolo 'Blaisorblade' Giarrusso Patrick Mochel Paul Burton @@ -185,11 +204,7 @@ Pratyush Anand Praveen BP Punit Agrawal Qais Yousef -Oleksij Rempel -Oleksij Rempel -Oleksij Rempel -Oleksij Rempel -Oleksij Rempel +Quentin Perret Rajesh Shah Ralf Baechle Ralf Wildenhues @@ -224,6 +239,7 @@ Sumit Semwal Tejun Heo Thomas Graf Thomas Pedersen +Todor Tomov Tony Luck TripleX Chung TripleX Chung diff --git a/CREDITS b/CREDITS index a7387605fbdc..8b67a85844b5 100644 --- a/CREDITS +++ b/CREDITS @@ -751,7 +751,7 @@ S: Santa Cruz, California S: USA N: Luis Correia -E: lfcorreia@users.sf.net +E: luisfcorreia@gmail.com D: Ralink rt2x00 WLAN driver S: Belas, Portugal diff --git a/Documentation/ABI/stable/sysfs-bus-w1 b/Documentation/ABI/stable/sysfs-bus-w1 index 140d85b4ae92..992dfb183ed0 100644 --- a/Documentation/ABI/stable/sysfs-bus-w1 +++ b/Documentation/ABI/stable/sysfs-bus-w1 @@ -6,6 +6,6 @@ Description: Bus scanning interval, microseconds component. control systems are attached/generate presence for as short as 100 ms - hence the tens-to-hundreds milliseconds scan intervals are required. - see Documentation/w1/w1.generic for detailed information. + see Documentation/w1/w1-generic.rst for detailed information. Users: any user space application which wants to know bus scanning interval diff --git a/Documentation/ABI/stable/sysfs-driver-w1_ds28e04 b/Documentation/ABI/stable/sysfs-driver-w1_ds28e04 index 26579ee868c9..3e1c1fa8d54d 100644 --- a/Documentation/ABI/stable/sysfs-driver-w1_ds28e04 +++ b/Documentation/ABI/stable/sysfs-driver-w1_ds28e04 @@ -2,7 +2,7 @@ What: /sys/bus/w1/devices/.../pio Date: May 2012 Contact: Markus Franke Description: read/write the contents of the two PIO's of the DS28E04-100 - see Documentation/w1/slaves/w1_ds28e04 for detailed information + see Documentation/w1/slaves/w1_ds28e04.rst for detailed information Users: any user space application which wants to communicate with DS28E04-100 @@ -11,5 +11,5 @@ What: /sys/bus/w1/devices/.../eeprom Date: May 2012 Contact: Markus Franke Description: read/write the contents of the EEPROM memory of the DS28E04-100 - see Documentation/w1/slaves/w1_ds28e04 for detailed information + see Documentation/w1/slaves/w1_ds28e04.rst for detailed information Users: any user space application which wants to communicate with DS28E04-100 diff --git a/Documentation/ABI/stable/sysfs-driver-w1_ds28ea00 b/Documentation/ABI/stable/sysfs-driver-w1_ds28ea00 index e928def14f28..534e63731a49 100644 --- a/Documentation/ABI/stable/sysfs-driver-w1_ds28ea00 +++ b/Documentation/ABI/stable/sysfs-driver-w1_ds28ea00 @@ -2,5 +2,5 @@ What: /sys/bus/w1/devices/.../w1_seq Date: Apr 2015 Contact: Matt Campbell Description: Support for the DS28EA00 chain sequence function - see Documentation/w1/slaves/w1_therm for detailed information + see Documentation/w1/slaves/w1_therm.rst for detailed information Users: any user space application which wants to communicate with DS28EA00 diff --git a/Documentation/ABI/testing/debugfs-hisi-zip b/Documentation/ABI/testing/debugfs-hisi-zip new file mode 100644 index 000000000000..a7c63e6c4bc3 --- /dev/null +++ b/Documentation/ABI/testing/debugfs-hisi-zip @@ -0,0 +1,50 @@ +What: /sys/kernel/debug/hisi_zip//comp_core[01]/regs +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: Dump of compression cores related debug registers. + Only available for PF. + +What: /sys/kernel/debug/hisi_zip//decomp_core[0-5]/regs +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: Dump of decompression cores related debug registers. + Only available for PF. + +What: /sys/kernel/debug/hisi_zip//clear_enable +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: Compression/decompression core debug registers read clear + control. 1 means enable register read clear, otherwise 0. + Writing to this file has no functional effect, only enable or + disable counters clear after reading of these registers. + Only available for PF. + +What: /sys/kernel/debug/hisi_zip//current_qm +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: One ZIP controller has one PF and multiple VFs, each function + has a QM. Select the QM which below qm refers to. + Only available for PF. + +What: /sys/kernel/debug/hisi_zip//qm/qm_regs +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: Dump of QM related debug registers. + Available for PF and VF in host. VF in guest currently only + has one debug register. + +What: /sys/kernel/debug/hisi_zip//qm/current_q +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: One QM may contain multiple queues. Select specific queue to + show its debug registers in above qm_regs. + Only available for PF. + +What: /sys/kernel/debug/hisi_zip//qm/clear_enable +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: QM debug registers(qm_regs) read clear control. 1 means enable + register read clear, otherwise 0. + Writing to this file has no functional effect, only enable or + disable counters clear after reading of these registers. + Only available for PF. diff --git a/Documentation/ABI/testing/debugfs-moxtet b/Documentation/ABI/testing/debugfs-moxtet new file mode 100644 index 000000000000..67b1717794d8 --- /dev/null +++ b/Documentation/ABI/testing/debugfs-moxtet @@ -0,0 +1,23 @@ +What: /sys/kernel/debug/moxtet/input +Date: March 2019 +KernelVersion: 5.3 +Contact: Marek Behún +Description: (R) Read input from the shift registers, in hexadecimal. + Returns N+1 bytes, where N is the number of Moxtet connected + modules. The first byte is from the CPU board itself. + Example: 101214 + 10: CPU board with SD card + 12: 2 = PCIe module, 1 = IRQ not active + 14: 4 = Peridot module, 1 = IRQ not active + +What: /sys/kernel/debug/moxtet/output +Date: March 2019 +KernelVersion: 5.3 +Contact: Marek Behún +Description: (RW) Read last written value to the shift registers, in + hexadecimal, or write values to the shift registers, also + in hexadecimal. + Example: 0102 + 01: 01 was last written, or is to be written, to the + first module's shift register + 02: the same for second module diff --git a/Documentation/ABI/testing/dev-kmsg b/Documentation/ABI/testing/dev-kmsg index fff817efa508..f307506eb54c 100644 --- a/Documentation/ABI/testing/dev-kmsg +++ b/Documentation/ABI/testing/dev-kmsg @@ -12,7 +12,7 @@ Description: The /dev/kmsg character device node provides userspace access The logged line can be prefixed with a syslog prefix, which carries the syslog priority and facility. The single decimal prefix number is composed of the 3 lowest bits being the syslog - priority and the higher bits the syslog facility number. + priority and the next 8 bits the syslog facility number. If no prefix is given, the priority number is the default kernel log priority and the facility number is set to LOG_USER (1). It @@ -90,13 +90,12 @@ Description: The /dev/kmsg character device node provides userspace access +sound:card0 - subsystem:devname The flags field carries '-' by default. A 'c' indicates a - fragment of a line. All following fragments are flagged with - '+'. Note, that these hints about continuation lines are not - necessarily correct, and the stream could be interleaved with - unrelated messages, but merging the lines in the output - usually produces better human readable results. A similar - logic is used internally when messages are printed to the - console, /proc/kmsg or the syslog() syscall. + fragment of a line. Note, that these hints about continuation + lines are not necessarily correct, and the stream could be + interleaved with unrelated messages, but merging the lines in + the output usually produces better human readable results. A + similar logic is used internally when messages are printed to + the console, /proc/kmsg or the syslog() syscall. By default, kernel tries to avoid fragments by concatenating when it can and fragments are rare; however, when extended diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy index fc376a323908..29ebe9afdac4 100644 --- a/Documentation/ABI/testing/ima_policy +++ b/Documentation/ABI/testing/ima_policy @@ -37,7 +37,7 @@ Description: euid:= decimal value fowner:= decimal value lsm: are LSM specific - option: appraise_type:= [imasig] + option: appraise_type:= [imasig] [imasig|modsig] template:= name of a defined IMA template type (eg, ima-ng). Only valid when action is "measure". pcr:= decimal value @@ -105,3 +105,7 @@ Description: measure func=KEXEC_KERNEL_CHECK pcr=4 measure func=KEXEC_INITRAMFS_CHECK pcr=5 + + Example of appraise rule allowing modsig appended signatures: + + appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig diff --git a/Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 b/Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 index da9822309f07..0e66ae9b0071 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 +++ b/Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 @@ -13,4 +13,4 @@ Description: error on writing If DFSDM input is SPI Slave: Reading returns value previously set. - Writing value before starting conversions. \ No newline at end of file + Writing value before starting conversions. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 index 161c147d3c40..b7259234ad70 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 +++ b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 @@ -91,29 +91,6 @@ Description: When counting down the counter start from preset value and fire event when reach 0. -What: /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available -KernelVersion: 4.12 -Contact: benjamin.gaignard@st.com -Description: - Reading returns the list possible quadrature modes. - -What: /sys/bus/iio/devices/iio:deviceX/in_count0_quadrature_mode -KernelVersion: 4.12 -Contact: benjamin.gaignard@st.com -Description: - Configure the device counter quadrature modes: - channel_A: - Encoder A input servers as the count input and B as - the UP/DOWN direction control input. - - channel_B: - Encoder B input serves as the count input and A as - the UP/DOWN direction control input. - - quadrature: - Encoder A and B inputs are mixed to get direction - and count with a scale of 0.25. - What: /sys/bus/iio/devices/iio:deviceX/in_count_enable_mode_available KernelVersion: 4.12 Contact: benjamin.gaignard@st.com diff --git a/Documentation/ABI/testing/sysfs-bus-intel_th-devices-msc b/Documentation/ABI/testing/sysfs-bus-intel_th-devices-msc index f54ae244f3f1..456cb62b384c 100644 --- a/Documentation/ABI/testing/sysfs-bus-intel_th-devices-msc +++ b/Documentation/ABI/testing/sysfs-bus-intel_th-devices-msc @@ -12,7 +12,8 @@ Description: (RW) Configure MSC operating mode: - "single", for contiguous buffer mode (high-order alloc); - "multi", for multiblock mode; - "ExI", for DCI handler mode; - - "debug", for debug mode. + - "debug", for debug mode; + - any of the currently loaded buffer sinks. If operating mode changes, existing buffer is deallocated, provided there are no active users and tracing is not enabled, otherwise the write will fail. diff --git a/Documentation/ABI/testing/sysfs-bus-moxtet-devices b/Documentation/ABI/testing/sysfs-bus-moxtet-devices new file mode 100644 index 000000000000..355958527fa3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-moxtet-devices @@ -0,0 +1,17 @@ +What: /sys/bus/moxtet/devices/moxtet-./module_description +Date: March 2019 +KernelVersion: 5.3 +Contact: Marek Behún +Description: (R) Moxtet module description. Format: string + +What: /sys/bus/moxtet/devices/moxtet-./module_id +Date: March 2019 +KernelVersion: 5.3 +Contact: Marek Behún +Description: (R) Moxtet module ID. Format: %x + +What: /sys/bus/moxtet/devices/moxtet-./module_name +Date: March 2019 +KernelVersion: 5.3 +Contact: Marek Behún +Description: (R) Moxtet module name. Format: string diff --git a/Documentation/ABI/testing/sysfs-class-backlight b/Documentation/ABI/testing/sysfs-class-backlight new file mode 100644 index 000000000000..3ab175a3f5cb --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-backlight @@ -0,0 +1,26 @@ +What: /sys/class/backlight//scale +Date: July 2019 +KernelVersion: 5.4 +Contact: Daniel Thompson +Description: + Description of the scale of the brightness curve. + + The human eye senses brightness approximately logarithmically, + hence linear changes in brightness are perceived as being + non-linear. To achieve a linear perception of brightness changes + controls like sliders need to apply a logarithmic mapping for + backlights with a linear brightness curve. + + Possible values of the attribute are: + + unknown + The scale of the brightness curve is unknown. + + linear + The brightness changes linearly with each step. Brightness + controls should apply a logarithmic mapping for a linear + perception. + + non-linear + The brightness changes non-linearly with each step. Brightness + controls should use a linear mapping for a linear perception. diff --git a/Documentation/ABI/testing/sysfs-class-mic.txt b/Documentation/ABI/testing/sysfs-class-mic similarity index 100% rename from Documentation/ABI/testing/sysfs-class-mic.txt rename to Documentation/ABI/testing/sysfs-class-mic diff --git a/Documentation/ABI/testing/sysfs-class-remoteproc b/Documentation/ABI/testing/sysfs-class-remoteproc index c3afe9fab646..36094fbeb974 100644 --- a/Documentation/ABI/testing/sysfs-class-remoteproc +++ b/Documentation/ABI/testing/sysfs-class-remoteproc @@ -48,3 +48,13 @@ Description: Remote processor state Writing "stop" will attempt to halt the remote processor and return it to the "offline" state. + +What: /sys/class/remoteproc/.../name +Date: August 2019 +KernelVersion: 5.4 +Contact: Suman Anna +Description: Remote processor name + + Reports the name of the remote processor. This can be used by + userspace in exactly identifying a remote processor and ease + up the usage in modifying the 'firmware' or 'state' files. diff --git a/Documentation/ABI/testing/sysfs-class-wakeup b/Documentation/ABI/testing/sysfs-class-wakeup new file mode 100644 index 000000000000..754aab8b6dcd --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-wakeup @@ -0,0 +1,76 @@ +What: /sys/class/wakeup/ +Date: June 2019 +Contact: Tri Vo +Description: + The /sys/class/wakeup/ directory contains pointers to all + wakeup sources in the kernel at that moment in time. + +What: /sys/class/wakeup/.../name +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the name of the wakeup source. + +What: /sys/class/wakeup/.../active_count +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the number of times the wakeup source was + activated. + +What: /sys/class/wakeup/.../event_count +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the number of signaled wakeup events + associated with the wakeup source. + +What: /sys/class/wakeup/.../wakeup_count +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the number of times the wakeup source might + abort suspend. + +What: /sys/class/wakeup/.../expire_count +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the number of times the wakeup source's + timeout has expired. + +What: /sys/class/wakeup/.../active_time_ms +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the amount of time the wakeup source has + been continuously active, in milliseconds. If the wakeup + source is not active, this file contains '0'. + +What: /sys/class/wakeup/.../total_time_ms +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the total amount of time this wakeup source + has been active, in milliseconds. + +What: /sys/class/wakeup/.../max_time_ms +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the maximum amount of time this wakeup + source has been continuously active, in milliseconds. + +What: /sys/class/wakeup/.../last_change_ms +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the monotonic clock time when the wakeup + source was touched last time, in milliseconds. + +What: /sys/class/wakeup/.../prevent_suspend_time_ms +Date: June 2019 +Contact: Tri Vo +Description: + The file contains the total amount of time this wakeup source + has been preventing autosleep, in milliseconds. diff --git a/Documentation/ABI/testing/sysfs-class-watchdog b/Documentation/ABI/testing/sysfs-class-watchdog index 6317ade5ad19..675f9b537661 100644 --- a/Documentation/ABI/testing/sysfs-class-watchdog +++ b/Documentation/ABI/testing/sysfs-class-watchdog @@ -72,3 +72,37 @@ Description: It is a read/write file. When read, the currently assigned pretimeout governor is returned. When written, it sets the pretimeout governor. + +What: /sys/class/watchdog/watchdog1/access_cs0 +Date: August 2019 +Contact: Ivan Mikhaylov , + Alexander Amelkin +Description: + It is a read/write file. This attribute exists only if the + system has booted from the alternate flash chip due to + expiration of a watchdog timer of AST2400/AST2500 when + alternate boot function was enabled with 'aspeed,alt-boot' + devicetree option for that watchdog or with an appropriate + h/w strapping (for WDT2 only). + + At alternate flash the 'access_cs0' sysfs node provides: + ast2400: a way to get access to the primary SPI flash + chip at CS0 after booting from the alternate + chip at CS1. + ast2500: a way to restore the normal address mapping + from (CS0->CS1, CS1->CS0) to (CS0->CS0, + CS1->CS1). + + Clearing the boot code selection and timeout counter also + resets to the initial state the chip select line mapping. When + the SoC is in normal mapping state (i.e. booted from CS0), + clearing those bits does nothing for both versions of the SoC. + For alternate boot mode (booted from CS1 due to wdt2 + expiration) the behavior differs as described above. + + This option can be used with wdt2 (watchdog1) only. + + When read, the current status of the boot code selection is + shown. When written with any non-zero value, it clears + the boot code selection and the timeout counter, which results + in chipselect reset for AST2400/AST2500. diff --git a/Documentation/ABI/testing/sysfs-devices-platform-stratix10-rsu b/Documentation/ABI/testing/sysfs-devices-platform-stratix10-rsu new file mode 100644 index 000000000000..ae9af984471a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-platform-stratix10-rsu @@ -0,0 +1,128 @@ + Intel Stratix10 Remote System Update (RSU) device attributes + +What: /sys/devices/platform/stratix10-rsu.0/current_image +Date: August 2019 +KernelVersion: 5.4 +Contact: Richard Gong +Description: + (RO) the address in flash of currently running image. + +What: /sys/devices/platform/stratix10-rsu.0/fail_image +Date: August 2019 +KernelVersion: 5.4 +Contact: Richard Gong +Description: + (RO) the address in flash of failed image. + +What: /sys/devices/platform/stratix10-rsu.0/state +Date: August 2019 +KernelVersion: 5.4 +Contact: Richard Gong +Description: + (RO) the state of RSU system. + The state field has two parts: major error code in + upper 16 bits and minor error code in lower 16 bits. + + b[15:0] + Currently used only when major error is 0xF006 + (CPU watchdog timeout), in which case the minor + error code is the value reported by CPU to + firmware through the RSU notify command before + the watchdog timeout occurs. + + b[31:16] + 0xF001 bitstream error + 0xF002 hardware access failure + 0xF003 bitstream corruption + 0xF004 internal error + 0xF005 device error + 0xF006 CPU watchdog timeout + 0xF007 internal unknown error + +What: /sys/devices/platform/stratix10-rsu.0/version +Date: August 2019 +KernelVersion: 5.4 +Contact: Richard Gong +Description: + (RO) the version number of RSU firmware. 19.3 or late + version includes information about the firmware which + reported the error. + + pre 19.3: + b[31:0] + 0x0 version number + + 19.3 or late: + b[15:0] + 0x1 version number + b[31:16] + 0x0 no error + 0x0DCF Decision CMF error + 0x0ACF Application CMF error + +What: /sys/devices/platform/stratix10-rsu.0/error_location +Date: August 2019 +KernelVersion: 5.4 +Contact: Richard Gong +Description: + (RO) the error offset inside the image that failed. + +What: /sys/devices/platform/stratix10-rsu.0/error_details +Date: August 2019 +KernelVersion: 5.4 +Contact: Richard Gong +Description: + (RO) error code. + +What: /sys/devices/platform/stratix10-rsu.0/retry_counter +Date: August 2019 +KernelVersion: 5.4 +Contact: Richard Gong +Description: + (RO) the current image's retry counter, which is used by + user to know how many times the images is still allowed + to reload itself before giving up and starting RSU + fail-over flow. + +What: /sys/devices/platform/stratix10-rsu.0/reboot_image +Date: August 2019 +KernelVersion: 5.4 +Contact: Richard Gong +Description: + (WO) the address in flash of image to be loaded on next + reboot command. + +What: /sys/devices/platform/stratix10-rsu.0/notify +Date: August 2019 +KernelVersion: 5.4 +Contact: Richard Gong +Description: + (WO) client to notify firmware with different actions. + + b[15:0] + inform firmware the current software execution + stage. + 0 the first stage bootloader didn't run or + didn't reach the point of launching second + stage bootloader. + 1 failed in second bootloader or didn't get + to the point of launching the operating + system. + 2 both first and second stage bootloader ran + and the operating system launch was + attempted. + + b[16] + 1 firmware to reset current image retry + counter. + 0 no action. + + b[17] + 1 firmware to clear RSU log + 0 no action. + + b[18] + this is negative logic + 1 no action + 0 firmware record the notify code defined + in b[15:0]. diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power index 80a00f7b6667..1763e64dd152 100644 --- a/Documentation/ABI/testing/sysfs-devices-power +++ b/Documentation/ABI/testing/sysfs-devices-power @@ -260,3 +260,12 @@ Description: This attribute has no effect on system-wide suspend/resume and hibernation. + +What: /sys/devices/.../power/runtime_status +Date: April 2010 +Contact: Rafael J. Wysocki +Description: + The /sys/devices/.../power/runtime_status attribute contains + the current runtime PM status of the device, which may be + "suspended", "suspending", "resuming", "active", "error" (fatal + error), or "unsupported" (runtime PM is disabled). diff --git a/Documentation/ABI/testing/sysfs-devices-soc b/Documentation/ABI/testing/sysfs-devices-soc index 6d9cc253f2b2..ba3a3fac0ee1 100644 --- a/Documentation/ABI/testing/sysfs-devices-soc +++ b/Documentation/ABI/testing/sysfs-devices-soc @@ -26,6 +26,13 @@ Description: Read-only attribute common to all SoCs. Contains SoC family name (e.g. DB8500). +What: /sys/devices/socX/serial_number +Date: January 2019 +contact: Bjorn Andersson +Description: + Read-only attribute supported by most SoCs. Contains the SoC's + serial number, if available. + What: /sys/devices/socX/soc_id Date: January 2012 contact: Lee Jones diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 5f7d7b14fa44..06d0931119cc 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -562,3 +562,13 @@ Description: Umwait control or C0.2 state. The time is an unsigned 32-bit number. Note that a value of zero means there is no limit. Low order two bits must be zero. + +What: /sys/devices/system/cpu/svm +Date: August 2019 +Contact: Linux kernel mailing list + Linux for PowerPC mailing list +Description: Secure Virtual Machine + + If 1, it means the system is using the Protected Execution + Facility in POWER9 and newer processors. i.e., it is a Secure + Virtual Machine. diff --git a/Documentation/ABI/testing/sysfs-driver-habanalabs b/Documentation/ABI/testing/sysfs-driver-habanalabs index f433fc6db3c6..782df74042ed 100644 --- a/Documentation/ABI/testing/sysfs-driver-habanalabs +++ b/Documentation/ABI/testing/sysfs-driver-habanalabs @@ -57,6 +57,7 @@ KernelVersion: 5.1 Contact: oded.gabbay@gmail.com Description: Allows the user to set the maximum clock frequency for MME, TPC and IC when the power management profile is set to "automatic". + This property is valid only for the Goya ASIC family What: /sys/class/habanalabs/hl/ic_clk Date: Jan 2019 @@ -127,8 +128,8 @@ Description: Power management profile. Values are "auto", "manual". In "auto" the max clock frequency to a low value when there are no user processes that are opened on the device's file. In "manual" mode, the user sets the maximum clock frequency by writing to - ic_clk, mme_clk and tpc_clk - + ic_clk, mme_clk and tpc_clk. This property is valid only for + the Goya ASIC family What: /sys/class/habanalabs/hl/preboot_btl_ver Date: Jan 2019 @@ -186,11 +187,4 @@ What: /sys/class/habanalabs/hl/uboot_ver Date: Jan 2019 KernelVersion: 5.1 Contact: oded.gabbay@gmail.com -Description: Version of the u-boot running on the device's CPU - -What: /sys/class/habanalabs/hl/write_open_cnt -Date: Jan 2019 -KernelVersion: 5.1 -Contact: oded.gabbay@gmail.com -Description: Displays the total number of user processes that are currently - opened on the device's file +Description: Version of the u-boot running on the device's CPU \ No newline at end of file diff --git a/Documentation/ABI/testing/sysfs-firmware-efi b/Documentation/ABI/testing/sysfs-firmware-efi index e794eac32a90..5e4d0b27cdfe 100644 --- a/Documentation/ABI/testing/sysfs-firmware-efi +++ b/Documentation/ABI/testing/sysfs-firmware-efi @@ -28,3 +28,11 @@ Description: Displays the physical addresses of all EFI Configuration versions are always printed first, i.e. ACPI20 comes before ACPI. Users: dmidecode + +What: /sys/firmware/efi/tables/rci2 +Date: July 2019 +Contact: Narendra K , linux-bugs@dell.com +Description: Displays the content of the Runtime Configuration Interface + Table version 2 on Dell EMC PowerEdge systems in binary format +Users: It is used by Dell EMC OpenManage Server Administrator tool to + populate BIOS setup page. diff --git a/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm b/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm new file mode 100644 index 000000000000..15595fab88d1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm @@ -0,0 +1,37 @@ +What: /sys/firmware/turris-mox-rwtm/board_version +Date: August 2019 +KernelVersion: 5.4 +Contact: Marek Behún +Description: (R) Board version burned into eFuses of this Turris Mox board. + Format: %i + +What: /sys/firmware/turris-mox-rwtm/mac_address* +Date: August 2019 +KernelVersion: 5.4 +Contact: Marek Behún +Description: (R) MAC addresses burned into eFuses of this Turris Mox board. + Format: %pM + +What: /sys/firmware/turris-mox-rwtm/pubkey +Date: August 2019 +KernelVersion: 5.4 +Contact: Marek Behún +Description: (R) ECDSA public key (in pubkey hex compressed form) computed + as pair to the ECDSA private key burned into eFuses of this + Turris Mox Board. + Format: string + +What: /sys/firmware/turris-mox-rwtm/ram_size +Date: August 2019 +KernelVersion: 5.4 +Contact: Marek Behún +Description: (R) RAM size in MiB of this Turris Mox board as was detected + during manufacturing and burned into eFuses. Can be 512 or 1024. + Format: %i + +What: /sys/firmware/turris-mox-rwtm/serial_number +Date: August 2019 +KernelVersion: 5.4 +Contact: Marek Behún +Description: (R) Serial number burned into eFuses of this Turris Mox device. + Format: %016X diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index dca326e0ee3e..7ab2b1b5e255 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -251,3 +251,10 @@ Description: If checkpoint=disable, it displays the number of blocks that are unusable. If checkpoint=enable it displays the enumber of blocks that would be unusable if checkpoint=disable were to be set. + +What: /sys/fs/f2fs//encoding +Date July 2019 +Contact: "Daniel Rosenberg" +Description: + Displays name and version of the encoding set for the filesystem. + If no encoding is set, displays (none) diff --git a/Documentation/ABI/testing/sysfs-kernel-btf b/Documentation/ABI/testing/sysfs-kernel-btf new file mode 100644 index 000000000000..2c9744b2cd59 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-btf @@ -0,0 +1,17 @@ +What: /sys/kernel/btf +Date: Aug 2019 +KernelVersion: 5.5 +Contact: bpf@vger.kernel.org +Description: + Contains BTF type information and related data for kernel and + kernel modules. + +What: /sys/kernel/btf/vmlinux +Date: Aug 2019 +KernelVersion: 5.5 +Contact: bpf@vger.kernel.org +Description: + Read-only binary attribute exposing kernel's own BTF type + information with description of all internal kernel types. See + Documentation/bpf/btf.rst for detailed description of format + itself. diff --git a/Documentation/ABI/testing/sysfs-kernel-slab b/Documentation/ABI/testing/sysfs-kernel-slab index 29601d93a1c2..ed35833ad7f0 100644 --- a/Documentation/ABI/testing/sysfs-kernel-slab +++ b/Documentation/ABI/testing/sysfs-kernel-slab @@ -429,10 +429,15 @@ KernelVersion: 2.6.22 Contact: Pekka Enberg , Christoph Lameter Description: - The shrink file is written when memory should be reclaimed from - a cache. Empty partial slabs are freed and the partial list is - sorted so the slabs with the fewest available objects are used - first. + The shrink file is used to reclaim unused slab cache + memory from a cache. Empty per-cpu or partial slabs + are freed and the partial list is sorted so the slabs + with the fewest available objects are used first. + It only accepts a value of "1" on write for shrinking + the cache. Other input values are considered invalid. + Shrinking slab caches might be expensive and can + adversely impact other running applications. So it + should be used with care. What: /sys/kernel/slab/cache/slab_size Date: May 2007 diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme b/Documentation/ABI/testing/sysfs-platform-dfl-fme index 8fa4febfa4b2..72634d3ae4f4 100644 --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme @@ -21,3 +21,88 @@ Contact: Wu Hao Description: Read-only. It returns Bitstream (static FPGA region) meta data, which includes the synthesis date, seed and other information of this static FPGA region. + +What: /sys/bus/platform/devices/dfl-fme.0/cache_size +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-only. It returns cache size of this FPGA device. + +What: /sys/bus/platform/devices/dfl-fme.0/fabric_version +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-only. It returns fabric version of this FPGA device. + Userspace applications need this information to select + best data channels per different fabric design. + +What: /sys/bus/platform/devices/dfl-fme.0/socket_id +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-only. It returns socket_id to indicate which socket + this FPGA belongs to, only valid for integrated solution. + User only needs this information, in case standard numa node + can't provide correct information. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/pcie0_errors +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-Write. Read this file for errors detected on pcie0 link. + Write this file to clear errors logged in pcie0_errors. Write + fails with -EINVAL if input parsing fails or input error code + doesn't match. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/pcie1_errors +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-Write. Read this file for errors detected on pcie1 link. + Write this file to clear errors logged in pcie1_errors. Write + fails with -EINVAL if input parsing fails or input error code + doesn't match. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/nonfatal_errors +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-only. It returns non-fatal errors detected. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/catfatal_errors +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-only. It returns catastrophic and fatal errors detected. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/inject_errors +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-Write. Read this file to check errors injected. Write this + file to inject errors for testing purpose. Write fails with + -EINVAL if input parsing fails or input inject error code isn't + supported. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/fme_errors +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-Write. Read this file to get errors detected on FME. + Write this file to clear errors logged in fme_errors. Write + fials with -EINVAL if input parsing fails or input error code + doesn't match. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/first_error +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-only. Read this file to get the first error detected by + hardware. + +What: /sys/bus/platform/devices/dfl-fme.0/errors/next_error +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-only. Read this file to get the second error detected by + hardware. diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-port b/Documentation/ABI/testing/sysfs-platform-dfl-port index 6a92dda517b0..65658267fcc0 100644 --- a/Documentation/ABI/testing/sysfs-platform-dfl-port +++ b/Documentation/ABI/testing/sysfs-platform-dfl-port @@ -14,3 +14,88 @@ Description: Read-only. User can program different PR bitstreams to FPGA Accelerator Function Unit (AFU) for different functions. It returns uuid which could be used to identify which PR bitstream is programmed in this AFU. + +What: /sys/bus/platform/devices/dfl-port.0/power_state +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-only. It reports the APx (AFU Power) state, different APx + means different throttling level. When reading this file, it + returns "0" - Normal / "1" - AP1 / "2" - AP2 / "6" - AP6. + +What: /sys/bus/platform/devices/dfl-port.0/ap1_event +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-write. Read this file for AP1 (AFU Power State 1) event. + It's used to indicate transient AP1 state. Write 1 to this + file to clear AP1 event. + +What: /sys/bus/platform/devices/dfl-port.0/ap2_event +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-write. Read this file for AP2 (AFU Power State 2) event. + It's used to indicate transient AP2 state. Write 1 to this + file to clear AP2 event. + +What: /sys/bus/platform/devices/dfl-port.0/ltr +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-write. Read or set AFU latency tolerance reporting value. + Set ltr to 1 if the AFU can tolerate latency >= 40us or set it + to 0 if it is latency sensitive. + +What: /sys/bus/platform/devices/dfl-port.0/userclk_freqcmd +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Write-only. User writes command to this interface to set + userclock to AFU. + +What: /sys/bus/platform/devices/dfl-port.0/userclk_freqsts +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-only. Read this file to get the status of issued command + to userclck_freqcmd. + +What: /sys/bus/platform/devices/dfl-port.0/userclk_freqcntrcmd +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Write-only. User writes command to this interface to set + userclock counter. + +What: /sys/bus/platform/devices/dfl-port.0/userclk_freqcntrsts +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-only. Read this file to get the status of issued command + to userclck_freqcntrcmd. + +What: /sys/bus/platform/devices/dfl-port.0/errors/errors +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-Write. Read this file to get errors detected on port and + Accelerated Function Unit (AFU). Write error code to this file + to clear errors. Write fails with -EINVAL if input parsing + fails or input error code doesn't match. Write fails with + -EBUSY or -ETIMEDOUT if error can't be cleared as hardware + in low power state (-EBUSY) or not respoding (-ETIMEDOUT). + +What: /sys/bus/platform/devices/dfl-port.0/errors/first_error +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-only. Read this file to get the first error detected by + hardware. + +What: /sys/bus/platform/devices/dfl-port.0/errors/first_malformed_req +Date: August 2019 +KernelVersion: 5.4 +Contact: Wu Hao +Description: Read-only. Read this file to get the first malformed request + captured by hardware. diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power index 3c5130355011..6f87b9dd384b 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power @@ -301,3 +301,109 @@ Description: Using this sysfs file will override any values that were set using the kernel command line for disk offset. + +What: /sys/power/suspend_stats +Date: July 2019 +Contact: Kalesh Singh +Description: + The /sys/power/suspend_stats directory contains suspend related + statistics. + +What: /sys/power/suspend_stats/success +Date: July 2019 +Contact: Kalesh Singh +Description: + The /sys/power/suspend_stats/success file contains the number + of times entering system sleep state succeeded. + +What: /sys/power/suspend_stats/fail +Date: July 2019 +Contact: Kalesh Singh +Description: + The /sys/power/suspend_stats/fail file contains the number + of times entering system sleep state failed. + +What: /sys/power/suspend_stats/failed_freeze +Date: July 2019 +Contact: Kalesh Singh +Description: + The /sys/power/suspend_stats/failed_freeze file contains the + number of times freezing processes failed. + +What: /sys/power/suspend_stats/failed_prepare +Date: July 2019 +Contact: Kalesh Singh +Description: + The /sys/power/suspend_stats/failed_prepare file contains the + number of times preparing all non-sysdev devices for + a system PM transition failed. + +What: /sys/power/suspend_stats/failed_resume +Date: July 2019 +Contact: Kalesh Singh +Description: + The /sys/power/suspend_stats/failed_resume file contains the + number of times executing "resume" callbacks of + non-sysdev devices failed. + +What: /sys/power/suspend_stats/failed_resume_early +Date: July 2019 +Contact: Kalesh Singh +Description: + The /sys/power/suspend_stats/failed_resume_early file contains + the number of times executing "early resume" callbacks + of devices failed. + +What: /sys/power/suspend_stats/failed_resume_noirq +Date: July 2019 +Contact: Kalesh Singh +Description: + The /sys/power/suspend_stats/failed_resume_noirq file contains + the number of times executing "noirq resume" callbacks + of devices failed. + +What: /sys/power/suspend_stats/failed_suspend +Date: July 2019 +Contact: Kalesh Singh +Description: + The /sys/power/suspend_stats/failed_suspend file contains + the number of times executing "suspend" callbacks + of all non-sysdev devices failed. + +What: /sys/power/suspend_stats/failed_suspend_late +Date: July 2019 +Contact: Kalesh Singh +Description: + The /sys/power/suspend_stats/failed_suspend_late file contains + the number of times executing "late suspend" callbacks + of all devices failed. + +What: /sys/power/suspend_stats/failed_suspend_noirq +Date: July 2019 +Contact: Kalesh Singh +Description: + The /sys/power/suspend_stats/failed_suspend_noirq file contains + the number of times executing "noirq suspend" callbacks + of all devices failed. + +What: /sys/power/suspend_stats/last_failed_dev +Date: July 2019 +Contact: Kalesh Singh +Description: + The /sys/power/suspend_stats/last_failed_dev file contains + the last device for which a suspend/resume callback failed. + +What: /sys/power/suspend_stats/last_failed_errno +Date: July 2019 +Contact: Kalesh Singh +Description: + The /sys/power/suspend_stats/last_failed_errno file contains + the errno of the last failed attempt at entering + system sleep state. + +What: /sys/power/suspend_stats/last_failed_step +Date: July 2019 +Contact: Kalesh Singh +Description: + The /sys/power/suspend_stats/last_failed_step file contains + the last failed step in the suspend/resume path. diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index e47c63bd4887..2d8d2fed7317 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -204,6 +204,14 @@ Returns the maximum size of a mapping for the device. The size parameter of the mapping functions like dma_map_single(), dma_map_page() and others should not be larger than the returned value. +:: + + unsigned long + dma_get_merge_boundary(struct device *dev); + +Returns the DMA merge boundary. If the device cannot merge any the DMA address +segments, the function returns 0. + Part Id - Streaming DMA mappings -------------------------------- @@ -595,17 +603,6 @@ For reasons of efficiency, most platforms choose to track the declared region only at the granularity of a page. For smaller allocations, you should use the dma_pool() API. -:: - - void - dma_release_declared_memory(struct device *dev) - -Remove the memory region previously declared from the system. This -API performs *no* in-use checking for this region and will return -unconditionally having removed all the required structures. It is the -driver's job to ensure that no parts of this memory region are -currently in use. - Part III - Debug drivers use of the DMA-API ------------------------------------------- diff --git a/Documentation/PCI/index.rst b/Documentation/PCI/index.rst index f4c6121868c3..6768305e4c26 100644 --- a/Documentation/PCI/index.rst +++ b/Documentation/PCI/index.rst @@ -9,7 +9,7 @@ Linux PCI Bus Subsystem :numbered: pci - picebus-howto + pciebus-howto pci-iov-howto msi-howto acpi-info diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst index e5d450df06b4..13beee23cb04 100644 --- a/Documentation/PCI/pci-error-recovery.rst +++ b/Documentation/PCI/pci-error-recovery.rst @@ -421,7 +421,6 @@ That is, the recovery API only requires that: - drivers/net/ixgbe - drivers/net/cxgb3 - drivers/net/s2io.c - - drivers/net/qlge The End ------- diff --git a/Documentation/PCI/picebus-howto.rst b/Documentation/PCI/pciebus-howto.rst similarity index 100% rename from Documentation/PCI/picebus-howto.rst rename to Documentation/PCI/pciebus-howto.rst diff --git a/Documentation/RCU/Design/Requirements/Requirements.html b/Documentation/RCU/Design/Requirements/Requirements.html index 5a9238a2883c..467251f7fef6 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.html +++ b/Documentation/RCU/Design/Requirements/Requirements.html @@ -2129,6 +2129,8 @@ Some of the relevant points of interest are as follows:
  • Hotplug CPU.
  • Scheduler and RCU.
  • Tracing and RCU. +
  • +Accesses to User Memory and RCU.
  • Energy Efficiency.
  • Scheduling-Clock Interrupts and RCU. @@ -2512,7 +2514,7 @@ disabled across the entire RCU read-side critical section.

    It is possible to use tracing on RCU code, but tracing itself uses RCU. -For this reason, rcu_dereference_raw_notrace() +For this reason, rcu_dereference_raw_check() is provided for use by tracing, which avoids the destructive recursion that could otherwise ensue. This API is also used by virtualization in some architectures, @@ -2521,6 +2523,75 @@ cannot be used. The tracing folks both located the requirement and provided the needed fix, so this surprise requirement was relatively painless. +

    +Accesses to User Memory and RCU

    + +

    +The kernel needs to access user-space memory, for example, to access +data referenced by system-call parameters. +The get_user() macro does this job. + +

    +However, user-space memory might well be paged out, which means +that get_user() might well page-fault and thus block while +waiting for the resulting I/O to complete. +It would be a very bad thing for the compiler to reorder +a get_user() invocation into an RCU read-side critical +section. +For example, suppose that the source code looked like this: + +

    +
    + 1 rcu_read_lock();
+ 2 p = rcu_dereference(gp);
+ 3 v = p->value;
+ 4 rcu_read_unlock();
+ 5 get_user(user_v, user_p);
+ 6 do_something_with(v, user_v);
+
    +
    + +

    +The compiler must not be permitted to transform this source code into +the following: + +

    +
    + 1 rcu_read_lock();
+ 2 p = rcu_dereference(gp);
+ 3 get_user(user_v, user_p); // BUG: POSSIBLE PAGE FAULT!!!
+ 4 v = p->value;
+ 5 rcu_read_unlock();
+ 6 do_something_with(v, user_v);
+
    +
    + +

    +If the compiler did make this transformation in a +CONFIG_PREEMPT=n kernel build, and if get_user() did +page fault, the result would be a quiescent state in the middle +of an RCU read-side critical section. +This misplaced quiescent state could result in line 4 being +a use-after-free access, which could be bad for your kernel's +actuarial statistics. +Similar examples can be constructed with the call to get_user() +preceding the rcu_read_lock(). + +

    +Unfortunately, get_user() doesn't have any particular +ordering properties, and in some architectures the underlying asm +isn't even marked volatile. +And even if it was marked volatile, the above access to +p->value is not volatile, so the compiler would not have any +reason to keep those two accesses in order. + +

    +Therefore, the Linux-kernel definitions of rcu_read_lock() +and rcu_read_unlock() must act as compiler barriers, +at least for outermost instances of rcu_read_lock() and +rcu_read_unlock() within a nested set of RCU read-side critical +sections. +

    Energy Efficiency

    diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt index 13e88fc00f01..f48f4621ccbc 100644 --- a/Documentation/RCU/stallwarn.txt +++ b/Documentation/RCU/stallwarn.txt @@ -57,6 +57,12 @@ o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that CONFIG_PREEMPT_RCU case, you might see stall-warning messages. + You can use the rcutree.kthread_prio kernel boot parameter to + increase the scheduling priority of RCU's kthreads, which can + help avoid this problem. However, please note that doing this + can increase your system's context-switch rate and thus degrade + performance. + o A periodic interrupt whose handler takes longer than the time interval between successive pairs of interrupts. This can prevent RCU's kthreads and softirq handlers from running. diff --git a/Documentation/acpi/dsd/leds.txt b/Documentation/acpi/dsd/leds.txt deleted file mode 100644 index cc58b1a574c5..000000000000 --- a/Documentation/acpi/dsd/leds.txt +++ /dev/null @@ -1,99 +0,0 @@ -Describing and referring to LEDs in ACPI - -Individual LEDs are described by hierarchical data extension [6] nodes under the -device node, the LED driver chip. The "reg" property in the LED specific nodes -tells the numerical ID of each individual LED output to which the LEDs are -connected. [3] The hierarchical data nodes are named "led@X", where X is the -number of the LED output. - -Referring to LEDs in Device tree is documented in [4], in "flash-leds" property -documentation. In short, LEDs are directly referred to by using phandles. - -While Device tree allows referring to any node in the tree[1], in ACPI -references are limited to device nodes only [2]. For this reason using the same -mechanism on ACPI is not possible. A mechanism to refer to non-device ACPI nodes -is documented in [7]. - -ACPI allows (as does DT) using integer arguments after the reference. A -combination of the LED driver device reference and an integer argument, -referring to the "reg" property of the relevant LED, is used to identify -individual LEDs. The value of the "reg" property is a contract between the -firmware and software, it uniquely identifies the LED driver outputs. - -Under the LED driver device, The first hierarchical data extension package list -entry shall contain the string "led@" followed by the number of the LED, -followed by the referred object name. That object shall be named "LED" followed -by the number of the LED. - -An ASL example of a camera sensor device and a LED driver device for two LEDs. -Objects not relevant for LEDs or the references to them have been omitted. - - Device (LED) - { - Name (_DSD, Package () { - ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), - Package () { - Package () { "led@0", LED0 }, - Package () { "led@1", LED1 }, - } - }) - Name (LED0, Package () { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package () { "reg", 0 }, - Package () { "flash-max-microamp", 1000000 }, - Package () { "flash-timeout-us", 200000 }, - Package () { "led-max-microamp", 100000 }, - Package () { "label", "white:flash" }, - } - }) - Name (LED1, Package () { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package () { "reg", 1 }, - Package () { "led-max-microamp", 10000 }, - Package () { "label", "red:indicator" }, - } - }) - } - - Device (SEN) - { - Name (_DSD, Package () { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package () { - "flash-leds", - Package () { ^LED, "led@0", ^LED, "led@1" }, - } - } - }) - } - -where - - LED LED driver device - LED0 First LED - LED1 Second LED - SEN Camera sensor device (or another device the LED is - related to) - -[1] Device tree. , referenced 2019-02-21. - -[2] Advanced Configuration and Power Interface Specification. - , - referenced 2019-02-21. - -[3] Documentation/devicetree/bindings/leds/common.txt - -[4] Documentation/devicetree/bindings/media/video-interfaces.txt - -[5] Device Properties UUID For _DSD. - , - referenced 2019-02-21. - -[6] Hierarchical Data Extension UUID For _DSD. - , - referenced 2019-02-21. - -[7] Documentation/firmware-guide/acpi/dsd/data-node-references.rst diff --git a/Documentation/admin-guide/auxdisplay/cfag12864b.rst b/Documentation/admin-guide/auxdisplay/cfag12864b.rst new file mode 100644 index 000000000000..18c2865bd322 --- /dev/null +++ b/Documentation/admin-guide/auxdisplay/cfag12864b.rst @@ -0,0 +1,98 @@ +=================================== +cfag12864b LCD Driver Documentation +=================================== + +:License: GPLv2 +:Author & Maintainer: Miguel Ojeda Sandonis +:Date: 2006-10-27 + + + +.. INDEX + + 1. DRIVER INFORMATION + 2. DEVICE INFORMATION + 3. WIRING + 4. USERSPACE PROGRAMMING + +1. Driver Information +--------------------- + +This driver supports a cfag12864b LCD. + + +2. Device Information +--------------------- + +:Manufacturer: Crystalfontz +:Device Name: Crystalfontz 12864b LCD Series +:Device Code: cfag12864b +:Webpage: http://www.crystalfontz.com +:Device Webpage: http://www.crystalfontz.com/products/12864b/ +:Type: LCD (Liquid Crystal Display) +:Width: 128 +:Height: 64 +:Colors: 2 (B/N) +:Controller: ks0108 +:Controllers: 2 +:Pages: 8 each controller +:Addresses: 64 each page +:Data size: 1 byte each address +:Memory size: 2 * 8 * 64 * 1 = 1024 bytes = 1 Kbyte + + +3. Wiring +--------- + +The cfag12864b LCD Series don't have official wiring. + +The common wiring is done to the parallel port as shown:: + + Parallel Port cfag12864b + + Name Pin# Pin# Name + + Strobe ( 1)------------------------------(17) Enable + Data 0 ( 2)------------------------------( 4) Data 0 + Data 1 ( 3)------------------------------( 5) Data 1 + Data 2 ( 4)------------------------------( 6) Data 2 + Data 3 ( 5)------------------------------( 7) Data 3 + Data 4 ( 6)------------------------------( 8) Data 4 + Data 5 ( 7)------------------------------( 9) Data 5 + Data 6 ( 8)------------------------------(10) Data 6 + Data 7 ( 9)------------------------------(11) Data 7 + (10) [+5v]---( 1) Vdd + (11) [GND]---( 2) Ground + (12) [+5v]---(14) Reset + (13) [GND]---(15) Read / Write + Line (14)------------------------------(13) Controller Select 1 + (15) + Init (16)------------------------------(12) Controller Select 2 + Select (17)------------------------------(16) Data / Instruction + Ground (18)---[GND] [+5v]---(19) LED + + Ground (19)---[GND] + Ground (20)---[GND] E A Values: + Ground (21)---[GND] [GND]---[P1]---(18) Vee - R = Resistor = 22 ohm + Ground (22)---[GND] | - P1 = Preset = 10 Kohm + Ground (23)---[GND] ---- S ------( 3) V0 - P2 = Preset = 1 Kohm + Ground (24)---[GND] | | + Ground (25)---[GND] [GND]---[P2]---[R]---(20) LED - + + +4. Userspace Programming +------------------------ + +The cfag12864bfb describes a framebuffer device (/dev/fbX). + +It has a size of 1024 bytes = 1 Kbyte. +Each bit represents one pixel. If the bit is high, the pixel will +turn on. If the pixel is low, the pixel will turn off. + +You can use the framebuffer as a file: fopen, fwrite, fclose... +Although the LCD won't get updated until the next refresh time arrives. + +Also, you can mmap the framebuffer: open & mmap, munmap & close... +which is the best option for most uses. + +Check samples/auxdisplay/cfag12864b-example.c +for a real working userspace complete program with usage examples. diff --git a/Documentation/admin-guide/auxdisplay/index.rst b/Documentation/admin-guide/auxdisplay/index.rst new file mode 100644 index 000000000000..e466f0595248 --- /dev/null +++ b/Documentation/admin-guide/auxdisplay/index.rst @@ -0,0 +1,16 @@ +========================= +Auxiliary Display Support +========================= + +.. toctree:: + :maxdepth: 1 + + ks0108.rst + cfag12864b.rst + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/admin-guide/auxdisplay/ks0108.rst b/Documentation/admin-guide/auxdisplay/ks0108.rst new file mode 100644 index 000000000000..c0b7faf73136 --- /dev/null +++ b/Documentation/admin-guide/auxdisplay/ks0108.rst @@ -0,0 +1,50 @@ +========================================== +ks0108 LCD Controller Driver Documentation +========================================== + +:License: GPLv2 +:Author & Maintainer: Miguel Ojeda Sandonis +:Date: 2006-10-27 + + + +.. INDEX + + 1. DRIVER INFORMATION + 2. DEVICE INFORMATION + 3. WIRING + + +1. Driver Information +--------------------- + +This driver supports the ks0108 LCD controller. + + +2. Device Information +--------------------- + +:Manufacturer: Samsung +:Device Name: KS0108 LCD Controller +:Device Code: ks0108 +:Webpage: - +:Device Webpage: - +:Type: LCD Controller (Liquid Crystal Display Controller) +:Width: 64 +:Height: 64 +:Colors: 2 (B/N) +:Pages: 8 +:Addresses: 64 each page +:Data size: 1 byte each address +:Memory size: 8 * 64 * 1 = 512 bytes + + +3. Wiring +--------- + +The driver supports data parallel port wiring. + +If you aren't building LCD related hardware, you should check +your LCD specific wiring information in the same folder. + +For example, check Documentation/admin-guide/auxdisplay/cfag12864b.rst diff --git a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst index 1d7d962933be..36d43ae7dc13 100644 --- a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst +++ b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst @@ -130,12 +130,6 @@ Proportional weight policy files dev weight 8:16 300 -- blkio.leaf_weight[_device] - - Equivalents of blkio.weight[_device] for the purpose of - deciding how much weight tasks in the given cgroup has while - competing with the cgroup's child cgroups. For details, - please refer to Documentation/block/cfq-iosched.txt. - - blkio.time - disk time allocated to cgroup per device in milliseconds. First two fields specify the major and minor number of the device and diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst index 41bdc038dad9..0ae4f564c2d6 100644 --- a/Documentation/admin-guide/cgroup-v1/memory.rst +++ b/Documentation/admin-guide/cgroup-v1/memory.rst @@ -85,8 +85,10 @@ Brief summary of control files. memory.oom_control set/show oom controls. memory.numa_stat show the number of memory usage per numa node - memory.kmem.limit_in_bytes set/show hard limit for kernel memory + This knob is deprecated and shouldn't be + used. It is planned that this be removed in + the foreseeable future. memory.kmem.usage_in_bytes show current kernel memory allocation memory.kmem.failcnt show the number of kernel memory usage hits limits diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 3b29005aa981..0fa8c0e615c2 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -951,6 +951,13 @@ controller implements weight and absolute bandwidth limit models for normal scheduling policy and absolute bandwidth allocation model for realtime scheduling policy. +In all the above models, cycles distribution is defined only on a temporal +base and it does not account for the frequency at which tasks are executed. +The (optional) utilization clamping support allows to hint the schedutil +cpufreq governor about the minimum desired frequency which should always be +provided by a CPU, as well as the maximum desired frequency, which should not +be exceeded by a CPU. + WARNING: cgroup2 doesn't yet support control of realtime processes and the cpu controller can only be enabled when all RT processes are in the root cgroup. Be aware that system management software may already @@ -1016,6 +1023,33 @@ All time durations are in microseconds. Shows pressure stall information for CPU. See Documentation/accounting/psi.rst for details. + cpu.uclamp.min + A read-write single value file which exists on non-root cgroups. + The default is "0", i.e. no utilization boosting. + + The requested minimum utilization (protection) as a percentage + rational number, e.g. 12.34 for 12.34%. + + This interface allows reading and setting minimum utilization clamp + values similar to the sched_setattr(2). This minimum utilization + value is used to clamp the task specific minimum utilization clamp. + + The requested minimum utilization (protection) is always capped by + the current value for the maximum utilization (limit), i.e. + `cpu.uclamp.max`. + + cpu.uclamp.max + A read-write single value file which exists on non-root cgroups. + The default is "max". i.e. no utilization capping + + The requested maximum utilization (limit) as a percentage rational + number, e.g. 98.76 for 98.76%. + + This interface allows reading and setting maximum utilization clamp + values similar to the sched_setattr(2). This maximum utilization + value is used to clamp the task specific maximum utilization clamp. + + Memory ------ @@ -1435,6 +1469,103 @@ IO Interface Files 8:16 rbytes=1459200 wbytes=314773504 rios=192 wios=353 dbytes=0 dios=0 8:0 rbytes=90430464 wbytes=299008000 rios=8950 wios=1252 dbytes=50331648 dios=3021 + io.cost.qos + A read-write nested-keyed file with exists only on the root + cgroup. + + This file configures the Quality of Service of the IO cost + model based controller (CONFIG_BLK_CGROUP_IOCOST) which + currently implements "io.weight" proportional control. Lines + are keyed by $MAJ:$MIN device numbers and not ordered. The + line for a given device is populated on the first write for + the device on "io.cost.qos" or "io.cost.model". The following + nested keys are defined. + + ====== ===================================== + enable Weight-based control enable + ctrl "auto" or "user" + rpct Read latency percentile [0, 100] + rlat Read latency threshold + wpct Write latency percentile [0, 100] + wlat Write latency threshold + min Minimum scaling percentage [1, 10000] + max Maximum scaling percentage [1, 10000] + ====== ===================================== + + The controller is disabled by default and can be enabled by + setting "enable" to 1. "rpct" and "wpct" parameters default + to zero and the controller uses internal device saturation + state to adjust the overall IO rate between "min" and "max". + + When a better control quality is needed, latency QoS + parameters can be configured. For example:: + + 8:16 enable=1 ctrl=auto rpct=95.00 rlat=75000 wpct=95.00 wlat=150000 min=50.00 max=150.0 + + shows that on sdb, the controller is enabled, will consider + the device saturated if the 95th percentile of read completion + latencies is above 75ms or write 150ms, and adjust the overall + IO issue rate between 50% and 150% accordingly. + + The lower the saturation point, the better the latency QoS at + the cost of aggregate bandwidth. The narrower the allowed + adjustment range between "min" and "max", the more conformant + to the cost model the IO behavior. Note that the IO issue + base rate may be far off from 100% and setting "min" and "max" + blindly can lead to a significant loss of device capacity or + control quality. "min" and "max" are useful for regulating + devices which show wide temporary behavior changes - e.g. a + ssd which accepts writes at the line speed for a while and + then completely stalls for multiple seconds. + + When "ctrl" is "auto", the parameters are controlled by the + kernel and may change automatically. Setting "ctrl" to "user" + or setting any of the percentile and latency parameters puts + it into "user" mode and disables the automatic changes. The + automatic mode can be restored by setting "ctrl" to "auto". + + io.cost.model + A read-write nested-keyed file with exists only on the root + cgroup. + + This file configures the cost model of the IO cost model based + controller (CONFIG_BLK_CGROUP_IOCOST) which currently + implements "io.weight" proportional control. Lines are keyed + by $MAJ:$MIN device numbers and not ordered. The line for a + given device is populated on the first write for the device on + "io.cost.qos" or "io.cost.model". The following nested keys + are defined. + + ===== ================================ + ctrl "auto" or "user" + model The cost model in use - "linear" + ===== ================================ + + When "ctrl" is "auto", the kernel may change all parameters + dynamically. When "ctrl" is set to "user" or any other + parameters are written to, "ctrl" become "user" and the + automatic changes are disabled. + + When "model" is "linear", the following model parameters are + defined. + + ============= ======================================== + [r|w]bps The maximum sequential IO throughput + [r|w]seqiops The maximum 4k sequential IOs per second + [r|w]randiops The maximum 4k random IOs per second + ============= ======================================== + + From the above, the builtin linear model determines the base + costs of a sequential and random IO and the cost coefficient + for the IO size. While simple, this model can cover most + common device classes acceptably. + + The IO cost model isn't expected to be accurate in absolute + sense and is scaled to the device behavior dynamically. + + If needed, tools/cgroup/iocost_coef_gen.py can be used to + generate device-specific coefficients. + io.weight A read-write flat-keyed file which exists on non-root cgroups. The default is "default 100". diff --git a/Documentation/admin-guide/cifs/authors.rst b/Documentation/admin-guide/cifs/authors.rst new file mode 100644 index 000000000000..b02d6dd6c070 --- /dev/null +++ b/Documentation/admin-guide/cifs/authors.rst @@ -0,0 +1,69 @@ +======= +Authors +======= + +Original Author +--------------- + +Steve French (sfrench@samba.org) + +The author wishes to express his appreciation and thanks to: +Andrew Tridgell (Samba team) for his early suggestions about smb/cifs VFS +improvements. Thanks to IBM for allowing me time and test resources to pursue +this project, to Jim McDonough from IBM (and the Samba Team) for his help, to +the IBM Linux JFS team for explaining many esoteric Linux filesystem features. +Jeremy Allison of the Samba team has done invaluable work in adding the server +side of the original CIFS Unix extensions and reviewing and implementing +portions of the newer CIFS POSIX extensions into the Samba 3 file server. Thank +Dave Boutcher of IBM Rochester (author of the OS/400 smb/cifs filesystem client) +for proving years ago that very good smb/cifs clients could be done on Unix-like +operating systems. Volker Lendecke, Andrew Tridgell, Urban Widmark, John +Newbigin and others for their work on the Linux smbfs module. Thanks to +the other members of the Storage Network Industry Association CIFS Technical +Workgroup for their work specifying this highly complex protocol and finally +thanks to the Samba team for their technical advice and encouragement. + +Patch Contributors +------------------ + +- Zwane Mwaikambo +- Andi Kleen +- Amrut Joshi +- Shobhit Dayal +- Sergey Vlasov +- Richard Hughes +- Yury Umanets +- Mark Hamzy (for some of the early cifs IPv6 work) +- Domen Puncer +- Jesper Juhl (in particular for lots of whitespace/formatting cleanup) +- Vince Negri and Dave Stahl (for finding an important caching bug) +- Adrian Bunk (kcalloc cleanups) +- Miklos Szeredi +- Kazeon team for various fixes especially for 2.4 version. +- Asser Ferno (Change Notify support) +- Shaggy (Dave Kleikamp) for innumerable small fs suggestions and some good cleanup +- Gunter Kukkukk (testing and suggestions for support of old servers) +- Igor Mammedov (DFS support) +- Jeff Layton (many, many fixes, as well as great work on the cifs Kerberos code) +- Scott Lovenberg +- Pavel Shilovsky (for great work adding SMB2 support, and various SMB3 features) +- Aurelien Aptel (for DFS SMB3 work and some key bug fixes) +- Ronnie Sahlberg (for SMB3 xattr work, bug fixes, and lots of great work on compounding) +- Shirish Pargaonkar (for many ACL patches over the years) +- Sachin Prabhu (many bug fixes, including for reconnect, copy offload and security) +- Paulo Alcantara +- Long Li (some great work on RDMA, SMB Direct) + + +Test case and Bug Report contributors +------------------------------------- +Thanks to those in the community who have submitted detailed bug reports +and debug of problems they have found: Jochen Dolze, David Blaine, +Rene Scharfe, Martin Josefsson, Alexander Wild, Anthony Liguori, +Lars Muller, Urban Widmark, Massimiliano Ferrero, Howard Owen, +Olaf Kirch, Kieron Briggs, Nick Millington and others. Also special +mention to the Stanford Checker (SWAT) which pointed out many minor +bugs in error paths. Valuable suggestions also have come from Al Viro +and Dave Miller. + +And thanks to the IBM LTC and Power test teams and SuSE and Citrix and RedHat testers for finding multiple bugs during excellent stress test runs. diff --git a/Documentation/admin-guide/cifs/changes.rst b/Documentation/admin-guide/cifs/changes.rst new file mode 100644 index 000000000000..71f2ecb62299 --- /dev/null +++ b/Documentation/admin-guide/cifs/changes.rst @@ -0,0 +1,8 @@ +======= +Changes +======= + +See https://wiki.samba.org/index.php/LinuxCIFSKernel for summary +information (that may be easier to read than parsing the output of +"git log fs/cifs") about fixes/improvements to CIFS/SMB2/SMB3 support (changes +to cifs.ko module) by kernel version (and cifs internal module version). diff --git a/Documentation/admin-guide/cifs/index.rst b/Documentation/admin-guide/cifs/index.rst new file mode 100644 index 000000000000..fad5268635f5 --- /dev/null +++ b/Documentation/admin-guide/cifs/index.rst @@ -0,0 +1,21 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==== +CIFS +==== + +.. toctree:: + :maxdepth: 2 + + introduction + usage + todo + changes + authors + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/admin-guide/cifs/introduction.rst b/Documentation/admin-guide/cifs/introduction.rst new file mode 100644 index 000000000000..0b98f672d36f --- /dev/null +++ b/Documentation/admin-guide/cifs/introduction.rst @@ -0,0 +1,53 @@ +============ +Introduction +============ + + This is the client VFS module for the SMB3 NAS protocol as well + as for older dialects such as the Common Internet File System (CIFS) + protocol which was the successor to the Server Message Block + (SMB) protocol, the native file sharing mechanism for most early + PC operating systems. New and improved versions of CIFS are now + called SMB2 and SMB3. Use of SMB3 (and later, including SMB3.1.1) + is strongly preferred over using older dialects like CIFS due to + security reaasons. All modern dialects, including the most recent, + SMB3.1.1 are supported by the CIFS VFS module. The SMB3 protocol + is implemented and supported by all major file servers + such as all modern versions of Windows (including Windows 2016 + Server), as well as by Samba (which provides excellent + CIFS/SMB2/SMB3 server support and tools for Linux and many other + operating systems). Apple systems also support SMB3 well, as + do most Network Attached Storage vendors, so this network + filesystem client can mount to a wide variety of systems. + It also supports mounting to the cloud (for example + Microsoft Azure), including the necessary security features. + + The intent of this module is to provide the most advanced network + file system function for SMB3 compliant servers, including advanced + security features, excellent parallelized high performance i/o, better + POSIX compliance, secure per-user session establishment, encryption, + high performance safe distributed caching (leases/oplocks), optional packet + signing, large files, Unicode support and other internationalization + improvements. Since both Samba server and this filesystem client support + the CIFS Unix extensions (and in the future SMB3 POSIX extensions), + the combination can provide a reasonable alternative to other network and + cluster file systems for fileserving in some Linux to Linux environments, + not just in Linux to Windows (or Linux to Mac) environments. + + This filesystem has a mount utility (mount.cifs) and various user space + tools (including smbinfo and setcifsacl) that can be obtained from + + https://git.samba.org/?p=cifs-utils.git + + or + + git://git.samba.org/cifs-utils.git + + mount.cifs should be installed in the directory with the other mount helpers. + + For more information on the module see the project wiki page at + + https://wiki.samba.org/index.php/LinuxCIFS + + and + + https://wiki.samba.org/index.php/LinuxCIFS_utils diff --git a/Documentation/admin-guide/cifs/todo.rst b/Documentation/admin-guide/cifs/todo.rst new file mode 100644 index 000000000000..084c25f92dcb --- /dev/null +++ b/Documentation/admin-guide/cifs/todo.rst @@ -0,0 +1,133 @@ +==== +TODO +==== + +Version 2.14 December 21, 2018 + +A Partial List of Missing Features +================================== + +Contributions are welcome. There are plenty of opportunities +for visible, important contributions to this module. Here +is a partial list of the known problems and missing features: + +a) SMB3 (and SMB3.1.1) missing optional features: + + - multichannel (started), integration with RDMA + - directory leases (improved metadata caching), started (root dir only) + - T10 copy offload ie "ODX" (copy chunk, and "Duplicate Extents" ioctl + currently the only two server side copy mechanisms supported) + +b) improved sparse file support (fiemap and SEEK_HOLE are implemented + but additional features would be supportable by the protocol). + +c) Directory entry caching relies on a 1 second timer, rather than + using Directory Leases, currently only the root file handle is cached longer + +d) quota support (needs minor kernel change since quota calls + to make it to network filesystems or deviceless filesystems) + +e) Additional use cases can be optimized to use "compounding" (e.g. + open/query/close and open/setinfo/close) to reduce the number of + roundtrips to the server and improve performance. Various cases + (stat, statfs, create, unlink, mkdir) already have been improved by + using compounding but more can be done. In addition we could + significantly reduce redundant opens by using deferred close (with + handle caching leases) and better using reference counters on file + handles. + +f) Finish inotify support so kde and gnome file list windows + will autorefresh (partially complete by Asser). Needs minor kernel + vfs change to support removing D_NOTIFY on a file. + +g) Add GUI tool to configure /proc/fs/cifs settings and for display of + the CIFS statistics (started) + +h) implement support for security and trusted categories of xattrs + (requires minor protocol extension) to enable better support for SELINUX + +i) Add support for tree connect contexts (see MS-SMB2) a new SMB3.1.1 protocol + feature (may be especially useful for virtualization). + +j) Create UID mapping facility so server UIDs can be mapped on a per + mount or a per server basis to client UIDs or nobody if no mapping + exists. Also better integration with winbind for resolving SID owners + +k) Add tools to take advantage of more smb3 specific ioctls and features + (passthrough ioctl/fsctl is now implemented in cifs.ko to allow + sending various SMB3 fsctls and query info and set info calls + directly from user space) Add tools to make setting various non-POSIX + metadata attributes easier from tools (e.g. extending what was done + in smb-info tool). + +l) encrypted file support + +m) improved stats gathering tools (perhaps integration with nfsometer?) + to extend and make easier to use what is currently in /proc/fs/cifs/Stats + +n) Add support for claims based ACLs ("DAC") + +o) mount helper GUI (to simplify the various configuration options on mount) + +p) Add support for witness protocol (perhaps ioctl to cifs.ko from user space + tool listening on witness protocol RPC) to allow for notification of share + move, server failover, and server adapter changes. And also improve other + failover scenarios, e.g. when client knows multiple DFS entries point to + different servers, and the server we are connected to has gone down. + +q) Allow mount.cifs to be more verbose in reporting errors with dialect + or unsupported feature errors. + +r) updating cifs documentation, and user guide. + +s) Addressing bugs found by running a broader set of xfstests in standard + file system xfstest suite. + +t) split cifs and smb3 support into separate modules so legacy (and less + secure) CIFS dialect can be disabled in environments that don't need it + and simplify the code. + +v) POSIX Extensions for SMB3.1.1 (started, create and mkdir support added + so far). + +w) Add support for additional strong encryption types, and additional spnego + authentication mechanisms (see MS-SMB2) + +x) Finish support for SMB3.1.1 compression + +Known Bugs +========== + +See http://bugzilla.samba.org - search on product "CifsVFS" for +current bug list. Also check http://bugzilla.kernel.org (Product = File System, Component = CIFS) + +1) existing symbolic links (Windows reparse points) are recognized but + can not be created remotely. They are implemented for Samba and those that + support the CIFS Unix extensions, although earlier versions of Samba + overly restrict the pathnames. +2) follow_link and readdir code does not follow dfs junctions + but recognizes them + +Misc testing to do +================== +1) check out max path names and max path name components against various server + types. Try nested symlinks (8 deep). Return max path name in stat -f information + +2) Improve xfstest's cifs/smb3 enablement and adapt xfstests where needed to test + cifs/smb3 better + +3) Additional performance testing and optimization using iozone and similar - + there are some easy changes that can be done to parallelize sequential writes, + and when signing is disabled to request larger read sizes (larger than + negotiated size) and send larger write sizes to modern servers. + +4) More exhaustively test against less common servers + +5) Continue to extend the smb3 "buildbot" which does automated xfstesting + against Windows, Samba and Azure currently - to add additional tests and + to allow the buildbot to execute the tests faster. The URL for the + buildbot is: http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com + +6) Address various coverity warnings (most are not bugs per-se, but + the more warnings are addressed, the easier it is to spot real + problems that static analyzers will point out in the future). diff --git a/Documentation/admin-guide/cifs/usage.rst b/Documentation/admin-guide/cifs/usage.rst new file mode 100644 index 000000000000..d3fb67b8a976 --- /dev/null +++ b/Documentation/admin-guide/cifs/usage.rst @@ -0,0 +1,869 @@ +===== +Usage +===== + +This module supports the SMB3 family of advanced network protocols (as well +as older dialects, originally called "CIFS" or SMB1). + +The CIFS VFS module for Linux supports many advanced network filesystem +features such as hierarchical DFS like namespace, hardlinks, locking and more. +It was designed to comply with the SNIA CIFS Technical Reference (which +supersedes the 1992 X/Open SMB Standard) as well as to perform best practice +practical interoperability with Windows 2000, Windows XP, Samba and equivalent +servers. This code was developed in participation with the Protocol Freedom +Information Foundation. CIFS and now SMB3 has now become a defacto +standard for interoperating between Macs and Windows and major NAS appliances. + +Please see +MS-SMB2 (for detailed SMB2/SMB3/SMB3.1.1 protocol specification) +http://protocolfreedom.org/ and +http://samba.org/samba/PFIF/ +for more details. + + +For questions or bug reports please contact: + + smfrench@gmail.com + +See the project page at: https://wiki.samba.org/index.php/LinuxCIFS_utils + +Build instructions +================== + +For Linux: + +1) Download the kernel (e.g. from http://www.kernel.org) + and change directory into the top of the kernel directory tree + (e.g. /usr/src/linux-2.5.73) +2) make menuconfig (or make xconfig) +3) select cifs from within the network filesystem choices +4) save and exit +5) make + + +Installation instructions +========================= + +If you have built the CIFS vfs as module (successfully) simply +type ``make modules_install`` (or if you prefer, manually copy the file to +the modules directory e.g. /lib/modules/2.4.10-4GB/kernel/fs/cifs/cifs.ko). + +If you have built the CIFS vfs into the kernel itself, follow the instructions +for your distribution on how to install a new kernel (usually you +would simply type ``make install``). + +If you do not have the utility mount.cifs (in the Samba 4.x source tree and on +the CIFS VFS web site) copy it to the same directory in which mount helpers +reside (usually /sbin). Although the helper software is not +required, mount.cifs is recommended. Most distros include a ``cifs-utils`` +package that includes this utility so it is recommended to install this. + +Note that running the Winbind pam/nss module (logon service) on all of your +Linux clients is useful in mapping Uids and Gids consistently across the +domain to the proper network user. The mount.cifs mount helper can be +found at cifs-utils.git on git.samba.org + +If cifs is built as a module, then the size and number of network buffers +and maximum number of simultaneous requests to one server can be configured. +Changing these from their defaults is not recommended. By executing modinfo:: + + modinfo kernel/fs/cifs/cifs.ko + +on kernel/fs/cifs/cifs.ko the list of configuration changes that can be made +at module initialization time (by running insmod cifs.ko) can be seen. + +Recommendations +=============== + +To improve security the SMB2.1 dialect or later (usually will get SMB3) is now +the new default. To use old dialects (e.g. to mount Windows XP) use "vers=1.0" +on mount (or vers=2.0 for Windows Vista). Note that the CIFS (vers=1.0) is +much older and less secure than the default dialect SMB3 which includes +many advanced security features such as downgrade attack detection +and encrypted shares and stronger signing and authentication algorithms. +There are additional mount options that may be helpful for SMB3 to get +improved POSIX behavior (NB: can use vers=3.0 to force only SMB3, never 2.1): + + ``mfsymlinks`` and ``cifsacl`` and ``idsfromsid`` + +Allowing User Mounts +==================== + +To permit users to mount and unmount over directories they own is possible +with the cifs vfs. A way to enable such mounting is to mark the mount.cifs +utility as suid (e.g. ``chmod +s /sbin/mount.cifs``). To enable users to +umount shares they mount requires + +1) mount.cifs version 1.4 or later +2) an entry for the share in /etc/fstab indicating that a user may + unmount it e.g.:: + + //server/usersharename /mnt/username cifs user 0 0 + +Note that when the mount.cifs utility is run suid (allowing user mounts), +in order to reduce risks, the ``nosuid`` mount flag is passed in on mount to +disallow execution of an suid program mounted on the remote target. +When mount is executed as root, nosuid is not passed in by default, +and execution of suid programs on the remote target would be enabled +by default. This can be changed, as with nfs and other filesystems, +by simply specifying ``nosuid`` among the mount options. For user mounts +though to be able to pass the suid flag to mount requires rebuilding +mount.cifs with the following flag: CIFS_ALLOW_USR_SUID + +There is a corresponding manual page for cifs mounting in the Samba 3.0 and +later source tree in docs/manpages/mount.cifs.8 + +Allowing User Unmounts +====================== + +To permit users to ummount directories that they have user mounted (see above), +the utility umount.cifs may be used. It may be invoked directly, or if +umount.cifs is placed in /sbin, umount can invoke the cifs umount helper +(at least for most versions of the umount utility) for umount of cifs +mounts, unless umount is invoked with -i (which will avoid invoking a umount +helper). As with mount.cifs, to enable user unmounts umount.cifs must be marked +as suid (e.g. ``chmod +s /sbin/umount.cifs``) or equivalent (some distributions +allow adding entries to a file to the /etc/permissions file to achieve the +equivalent suid effect). For this utility to succeed the target path +must be a cifs mount, and the uid of the current user must match the uid +of the user who mounted the resource. + +Also note that the customary way of allowing user mounts and unmounts is +(instead of using mount.cifs and unmount.cifs as suid) to add a line +to the file /etc/fstab for each //server/share you wish to mount, but +this can become unwieldy when potential mount targets include many +or unpredictable UNC names. + +Samba Considerations +==================== + +Most current servers support SMB2.1 and SMB3 which are more secure, +but there are useful protocol extensions for the older less secure CIFS +dialect, so to get the maximum benefit if mounting using the older dialect +(CIFS/SMB1), we recommend using a server that supports the SNIA CIFS +Unix Extensions standard (e.g. almost any version of Samba ie version +2.2.5 or later) but the CIFS vfs works fine with a wide variety of CIFS servers. +Note that uid, gid and file permissions will display default values if you do +not have a server that supports the Unix extensions for CIFS (such as Samba +2.2.5 or later). To enable the Unix CIFS Extensions in the Samba server, add +the line:: + + unix extensions = yes + +to your smb.conf file on the server. Note that the following smb.conf settings +are also useful (on the Samba server) when the majority of clients are Unix or +Linux:: + + case sensitive = yes + delete readonly = yes + ea support = yes + +Note that server ea support is required for supporting xattrs from the Linux +cifs client, and that EA support is present in later versions of Samba (e.g. +3.0.6 and later (also EA support works in all versions of Windows, at least to +shares on NTFS filesystems). Extended Attribute (xattr) support is an optional +feature of most Linux filesystems which may require enabling via +make menuconfig. Client support for extended attributes (user xattr) can be +disabled on a per-mount basis by specifying ``nouser_xattr`` on mount. + +The CIFS client can get and set POSIX ACLs (getfacl, setfacl) to Samba servers +version 3.10 and later. Setting POSIX ACLs requires enabling both XATTR and +then POSIX support in the CIFS configuration options when building the cifs +module. POSIX ACL support can be disabled on a per mount basic by specifying +``noacl`` on mount. + +Some administrators may want to change Samba's smb.conf ``map archive`` and +``create mask`` parameters from the default. Unless the create mask is changed +newly created files can end up with an unnecessarily restrictive default mode, +which may not be what you want, although if the CIFS Unix extensions are +enabled on the server and client, subsequent setattr calls (e.g. chmod) can +fix the mode. Note that creating special devices (mknod) remotely +may require specifying a mkdev function to Samba if you are not using +Samba 3.0.6 or later. For more information on these see the manual pages +(``man smb.conf``) on the Samba server system. Note that the cifs vfs, +unlike the smbfs vfs, does not read the smb.conf on the client system +(the few optional settings are passed in on mount via -o parameters instead). +Note that Samba 2.2.7 or later includes a fix that allows the CIFS VFS to delete +open files (required for strict POSIX compliance). Windows Servers already +supported this feature. Samba server does not allow symlinks that refer to files +outside of the share, so in Samba versions prior to 3.0.6, most symlinks to +files with absolute paths (ie beginning with slash) such as:: + + ln -s /mnt/foo bar + +would be forbidden. Samba 3.0.6 server or later includes the ability to create +such symlinks safely by converting unsafe symlinks (ie symlinks to server +files that are outside of the share) to a samba specific format on the server +that is ignored by local server applications and non-cifs clients and that will +not be traversed by the Samba server). This is opaque to the Linux client +application using the cifs vfs. Absolute symlinks will work to Samba 3.0.5 or +later, but only for remote clients using the CIFS Unix extensions, and will +be invisbile to Windows clients and typically will not affect local +applications running on the same server as Samba. + +Use instructions +================ + +Once the CIFS VFS support is built into the kernel or installed as a module +(cifs.ko), you can use mount syntax like the following to access Samba or +Mac or Windows servers:: + + mount -t cifs //9.53.216.11/e$ /mnt -o username=myname,password=mypassword + +Before -o the option -v may be specified to make the mount.cifs +mount helper display the mount steps more verbosely. +After -o the following commonly used cifs vfs specific options +are supported:: + + username= + password= + domain= + +Other cifs mount options are described below. Use of TCP names (in addition to +ip addresses) is available if the mount helper (mount.cifs) is installed. If +you do not trust the server to which are mounted, or if you do not have +cifs signing enabled (and the physical network is insecure), consider use +of the standard mount options ``noexec`` and ``nosuid`` to reduce the risk of +running an altered binary on your local system (downloaded from a hostile server +or altered by a hostile router). + +Although mounting using format corresponding to the CIFS URL specification is +not possible in mount.cifs yet, it is possible to use an alternate format +for the server and sharename (which is somewhat similar to NFS style mount +syntax) instead of the more widely used UNC format (i.e. \\server\share):: + + mount -t cifs tcp_name_of_server:share_name /mnt -o user=myname,pass=mypasswd + +When using the mount helper mount.cifs, passwords may be specified via alternate +mechanisms, instead of specifying it after -o using the normal ``pass=`` syntax +on the command line: +1) By including it in a credential file. Specify credentials=filename as one +of the mount options. Credential files contain two lines:: + + username=someuser + password=your_password + +2) By specifying the password in the PASSWD environment variable (similarly + the user name can be taken from the USER environment variable). +3) By specifying the password in a file by name via PASSWD_FILE +4) By specifying the password in a file by file descriptor via PASSWD_FD + +If no password is provided, mount.cifs will prompt for password entry + +Restrictions +============ + +Servers must support either "pure-TCP" (port 445 TCP/IP CIFS connections) or RFC +1001/1002 support for "Netbios-Over-TCP/IP." This is not likely to be a +problem as most servers support this. + +Valid filenames differ between Windows and Linux. Windows typically restricts +filenames which contain certain reserved characters (e.g.the character : +which is used to delimit the beginning of a stream name by Windows), while +Linux allows a slightly wider set of valid characters in filenames. Windows +servers can remap such characters when an explicit mapping is specified in +the Server's registry. Samba starting with version 3.10 will allow such +filenames (ie those which contain valid Linux characters, which normally +would be forbidden for Windows/CIFS semantics) as long as the server is +configured for Unix Extensions (and the client has not disabled +/proc/fs/cifs/LinuxExtensionsEnabled). In addition the mount option +``mapposix`` can be used on CIFS (vers=1.0) to force the mapping of +illegal Windows/NTFS/SMB characters to a remap range (this mount parm +is the default for SMB3). This remap (``mapposix``) range is also +compatible with Mac (and "Services for Mac" on some older Windows). + +CIFS VFS Mount Options +====================== +A partial list of the supported mount options follows: + + username + The user name to use when trying to establish + the CIFS session. + password + The user password. If the mount helper is + installed, the user will be prompted for password + if not supplied. + ip + The ip address of the target server + unc + The target server Universal Network Name (export) to + mount. + domain + Set the SMB/CIFS workgroup name prepended to the + username during CIFS session establishment + forceuid + Set the default uid for inodes to the uid + passed in on mount. For mounts to servers + which do support the CIFS Unix extensions, such as a + properly configured Samba server, the server provides + the uid, gid and mode so this parameter should not be + specified unless the server and clients uid and gid + numbering differ. If the server and client are in the + same domain (e.g. running winbind or nss_ldap) and + the server supports the Unix Extensions then the uid + and gid can be retrieved from the server (and uid + and gid would not have to be specified on the mount. + For servers which do not support the CIFS Unix + extensions, the default uid (and gid) returned on lookup + of existing files will be the uid (gid) of the person + who executed the mount (root, except when mount.cifs + is configured setuid for user mounts) unless the ``uid=`` + (gid) mount option is specified. Also note that permission + checks (authorization checks) on accesses to a file occur + at the server, but there are cases in which an administrator + may want to restrict at the client as well. For those + servers which do not report a uid/gid owner + (such as Windows), permissions can also be checked at the + client, and a crude form of client side permission checking + can be enabled by specifying file_mode and dir_mode on + the client. (default) + forcegid + (similar to above but for the groupid instead of uid) (default) + noforceuid + Fill in file owner information (uid) by requesting it from + the server if possible. With this option, the value given in + the uid= option (on mount) will only be used if the server + can not support returning uids on inodes. + noforcegid + (similar to above but for the group owner, gid, instead of uid) + uid + Set the default uid for inodes, and indicate to the + cifs kernel driver which local user mounted. If the server + supports the unix extensions the default uid is + not used to fill in the owner fields of inodes (files) + unless the ``forceuid`` parameter is specified. + gid + Set the default gid for inodes (similar to above). + file_mode + If CIFS Unix extensions are not supported by the server + this overrides the default mode for file inodes. + fsc + Enable local disk caching using FS-Cache (off by default). This + option could be useful to improve performance on a slow link, + heavily loaded server and/or network where reading from the + disk is faster than reading from the server (over the network). + This could also impact scalability positively as the + number of calls to the server are reduced. However, local + caching is not suitable for all workloads for e.g. read-once + type workloads. So, you need to consider carefully your + workload/scenario before using this option. Currently, local + disk caching is functional for CIFS files opened as read-only. + dir_mode + If CIFS Unix extensions are not supported by the server + this overrides the default mode for directory inodes. + port + attempt to contact the server on this tcp port, before + trying the usual ports (port 445, then 139). + iocharset + Codepage used to convert local path names to and from + Unicode. Unicode is used by default for network path + names if the server supports it. If iocharset is + not specified then the nls_default specified + during the local client kernel build will be used. + If server does not support Unicode, this parameter is + unused. + rsize + default read size (usually 16K). The client currently + can not use rsize larger than CIFSMaxBufSize. CIFSMaxBufSize + defaults to 16K and may be changed (from 8K to the maximum + kmalloc size allowed by your kernel) at module install time + for cifs.ko. Setting CIFSMaxBufSize to a very large value + will cause cifs to use more memory and may reduce performance + in some cases. To use rsize greater than 127K (the original + cifs protocol maximum) also requires that the server support + a new Unix Capability flag (for very large read) which some + newer servers (e.g. Samba 3.0.26 or later) do. rsize can be + set from a minimum of 2048 to a maximum of 130048 (127K or + CIFSMaxBufSize, whichever is smaller) + wsize + default write size (default 57344) + maximum wsize currently allowed by CIFS is 57344 (fourteen + 4096 byte pages) + actimeo=n + attribute cache timeout in seconds (default 1 second). + After this timeout, the cifs client requests fresh attribute + information from the server. This option allows to tune the + attribute cache timeout to suit the workload needs. Shorter + timeouts mean better the cache coherency, but increased number + of calls to the server. Longer timeouts mean reduced number + of calls to the server at the expense of less stricter cache + coherency checks (i.e. incorrect attribute cache for a short + period of time). + rw + mount the network share read-write (note that the + server may still consider the share read-only) + ro + mount network share read-only + version + used to distinguish different versions of the + mount helper utility (not typically needed) + sep + if first mount option (after the -o), overrides + the comma as the separator between the mount + parms. e.g.:: + + -o user=myname,password=mypassword,domain=mydom + + could be passed instead with period as the separator by:: + + -o sep=.user=myname.password=mypassword.domain=mydom + + this might be useful when comma is contained within username + or password or domain. This option is less important + when the cifs mount helper cifs.mount (version 1.1 or later) + is used. + nosuid + Do not allow remote executables with the suid bit + program to be executed. This is only meaningful for mounts + to servers such as Samba which support the CIFS Unix Extensions. + If you do not trust the servers in your network (your mount + targets) it is recommended that you specify this option for + greater security. + exec + Permit execution of binaries on the mount. + noexec + Do not permit execution of binaries on the mount. + dev + Recognize block devices on the remote mount. + nodev + Do not recognize devices on the remote mount. + suid + Allow remote files on this mountpoint with suid enabled to + be executed (default for mounts when executed as root, + nosuid is default for user mounts). + credentials + Although ignored by the cifs kernel component, it is used by + the mount helper, mount.cifs. When mount.cifs is installed it + opens and reads the credential file specified in order + to obtain the userid and password arguments which are passed to + the cifs vfs. + guest + Although ignored by the kernel component, the mount.cifs + mount helper will not prompt the user for a password + if guest is specified on the mount options. If no + password is specified a null password will be used. + perm + Client does permission checks (vfs_permission check of uid + and gid of the file against the mode and desired operation), + Note that this is in addition to the normal ACL check on the + target machine done by the server software. + Client permission checking is enabled by default. + noperm + Client does not do permission checks. This can expose + files on this mount to access by other users on the local + client system. It is typically only needed when the server + supports the CIFS Unix Extensions but the UIDs/GIDs on the + client and server system do not match closely enough to allow + access by the user doing the mount, but it may be useful with + non CIFS Unix Extension mounts for cases in which the default + mode is specified on the mount but is not to be enforced on the + client (e.g. perhaps when MultiUserMount is enabled) + Note that this does not affect the normal ACL check on the + target machine done by the server software (of the server + ACL against the user name provided at mount time). + serverino + Use server's inode numbers instead of generating automatically + incrementing inode numbers on the client. Although this will + make it easier to spot hardlinked files (as they will have + the same inode numbers) and inode numbers may be persistent, + note that the server does not guarantee that the inode numbers + are unique if multiple server side mounts are exported under a + single share (since inode numbers on the servers might not + be unique if multiple filesystems are mounted under the same + shared higher level directory). Note that some older + (e.g. pre-Windows 2000) do not support returning UniqueIDs + or the CIFS Unix Extensions equivalent and for those + this mount option will have no effect. Exporting cifs mounts + under nfsd requires this mount option on the cifs mount. + This is now the default if server supports the + required network operation. + noserverino + Client generates inode numbers (rather than using the actual one + from the server). These inode numbers will vary after + unmount or reboot which can confuse some applications, + but not all server filesystems support unique inode + numbers. + setuids + If the CIFS Unix extensions are negotiated with the server + the client will attempt to set the effective uid and gid of + the local process on newly created files, directories, and + devices (create, mkdir, mknod). If the CIFS Unix Extensions + are not negotiated, for newly created files and directories + instead of using the default uid and gid specified on + the mount, cache the new file's uid and gid locally which means + that the uid for the file can change when the inode is + reloaded (or the user remounts the share). + nosetuids + The client will not attempt to set the uid and gid on + on newly created files, directories, and devices (create, + mkdir, mknod) which will result in the server setting the + uid and gid to the default (usually the server uid of the + user who mounted the share). Letting the server (rather than + the client) set the uid and gid is the default. If the CIFS + Unix Extensions are not negotiated then the uid and gid for + new files will appear to be the uid (gid) of the mounter or the + uid (gid) parameter specified on the mount. + netbiosname + When mounting to servers via port 139, specifies the RFC1001 + source name to use to represent the client netbios machine + name when doing the RFC1001 netbios session initialize. + direct + Do not do inode data caching on files opened on this mount. + This precludes mmapping files on this mount. In some cases + with fast networks and little or no caching benefits on the + client (e.g. when the application is doing large sequential + reads bigger than page size without rereading the same data) + this can provide better performance than the default + behavior which caches reads (readahead) and writes + (writebehind) through the local Linux client pagecache + if oplock (caching token) is granted and held. Note that + direct allows write operations larger than page size + to be sent to the server. + strictcache + Use for switching on strict cache mode. In this mode the + client read from the cache all the time it has Oplock Level II, + otherwise - read from the server. All written data are stored + in the cache, but if the client doesn't have Exclusive Oplock, + it writes the data to the server. + rwpidforward + Forward pid of a process who opened a file to any read or write + operation on that file. This prevent applications like WINE + from failing on read and write if we use mandatory brlock style. + acl + Allow setfacl and getfacl to manage posix ACLs if server + supports them. (default) + noacl + Do not allow setfacl and getfacl calls on this mount + user_xattr + Allow getting and setting user xattrs (those attributes whose + name begins with ``user.`` or ``os2.``) as OS/2 EAs (extended + attributes) to the server. This allows support of the + setfattr and getfattr utilities. (default) + nouser_xattr + Do not allow getfattr/setfattr to get/set/list xattrs + mapchars + Translate six of the seven reserved characters (not backslash):: + + *?<>|: + + to the remap range (above 0xF000), which also + allows the CIFS client to recognize files created with + such characters by Windows's POSIX emulation. This can + also be useful when mounting to most versions of Samba + (which also forbids creating and opening files + whose names contain any of these seven characters). + This has no effect if the server does not support + Unicode on the wire. + nomapchars + Do not translate any of these seven characters (default). + nocase + Request case insensitive path name matching (case + sensitive is the default if the server supports it). + (mount option ``ignorecase`` is identical to ``nocase``) + posixpaths + If CIFS Unix extensions are supported, attempt to + negotiate posix path name support which allows certain + characters forbidden in typical CIFS filenames, without + requiring remapping. (default) + noposixpaths + If CIFS Unix extensions are supported, do not request + posix path name support (this may cause servers to + reject creatingfile with certain reserved characters). + nounix + Disable the CIFS Unix Extensions for this mount (tree + connection). This is rarely needed, but it may be useful + in order to turn off multiple settings all at once (ie + posix acls, posix locks, posix paths, symlink support + and retrieving uids/gids/mode from the server) or to + work around a bug in server which implement the Unix + Extensions. + nobrl + Do not send byte range lock requests to the server. + This is necessary for certain applications that break + with cifs style mandatory byte range locks (and most + cifs servers do not yet support requesting advisory + byte range locks). + forcemandatorylock + Even if the server supports posix (advisory) byte range + locking, send only mandatory lock requests. For some + (presumably rare) applications, originally coded for + DOS/Windows, which require Windows style mandatory byte range + locking, they may be able to take advantage of this option, + forcing the cifs client to only send mandatory locks + even if the cifs server would support posix advisory locks. + ``forcemand`` is accepted as a shorter form of this mount + option. + nostrictsync + If this mount option is set, when an application does an + fsync call then the cifs client does not send an SMB Flush + to the server (to force the server to write all dirty data + for this file immediately to disk), although cifs still sends + all dirty (cached) file data to the server and waits for the + server to respond to the write. Since SMB Flush can be + very slow, and some servers may be reliable enough (to risk + delaying slightly flushing the data to disk on the server), + turning on this option may be useful to improve performance for + applications that fsync too much, at a small risk of server + crash. If this mount option is not set, by default cifs will + send an SMB flush request (and wait for a response) on every + fsync call. + nodfs + Disable DFS (global name space support) even if the + server claims to support it. This can help work around + a problem with parsing of DFS paths with Samba server + versions 3.0.24 and 3.0.25. + remount + remount the share (often used to change from ro to rw mounts + or vice versa) + cifsacl + Report mode bits (e.g. on stat) based on the Windows ACL for + the file. (EXPERIMENTAL) + servern + Specify the server 's netbios name (RFC1001 name) to use + when attempting to setup a session to the server. + This is needed for mounting to some older servers (such + as OS/2 or Windows 98 and Windows ME) since they do not + support a default server name. A server name can be up + to 15 characters long and is usually uppercased. + sfu + When the CIFS Unix Extensions are not negotiated, attempt to + create device files and fifos in a format compatible with + Services for Unix (SFU). In addition retrieve bits 10-12 + of the mode via the SETFILEBITS extended attribute (as + SFU does). In the future the bottom 9 bits of the + mode also will be emulated using queries of the security + descriptor (ACL). + mfsymlinks + Enable support for Minshall+French symlinks + (see http://wiki.samba.org/index.php/UNIX_Extensions#Minshall.2BFrench_symlinks) + This option is ignored when specified together with the + 'sfu' option. Minshall+French symlinks are used even if + the server supports the CIFS Unix Extensions. + sign + Must use packet signing (helps avoid unwanted data modification + by intermediate systems in the route). Note that signing + does not work with lanman or plaintext authentication. + seal + Must seal (encrypt) all data on this mounted share before + sending on the network. Requires support for Unix Extensions. + Note that this differs from the sign mount option in that it + causes encryption of data sent over this mounted share but other + shares mounted to the same server are unaffected. + locallease + This option is rarely needed. Fcntl F_SETLEASE is + used by some applications such as Samba and NFSv4 server to + check to see whether a file is cacheable. CIFS has no way + to explicitly request a lease, but can check whether a file + is cacheable (oplocked). Unfortunately, even if a file + is not oplocked, it could still be cacheable (ie cifs client + could grant fcntl leases if no other local processes are using + the file) for cases for example such as when the server does not + support oplocks and the user is sure that the only updates to + the file will be from this client. Specifying this mount option + will allow the cifs client to check for leases (only) locally + for files which are not oplocked instead of denying leases + in that case. (EXPERIMENTAL) + sec + Security mode. Allowed values are: + + none + attempt to connection as a null user (no name) + krb5 + Use Kerberos version 5 authentication + krb5i + Use Kerberos authentication and packet signing + ntlm + Use NTLM password hashing (default) + ntlmi + Use NTLM password hashing with signing (if + /proc/fs/cifs/PacketSigningEnabled on or if + server requires signing also can be the default) + ntlmv2 + Use NTLMv2 password hashing + ntlmv2i + Use NTLMv2 password hashing with packet signing + lanman + (if configured in kernel config) use older + lanman hash + hard + Retry file operations if server is not responding + soft + Limit retries to unresponsive servers (usually only + one retry) before returning an error. (default) + +The mount.cifs mount helper also accepts a few mount options before -o +including: + +=============== =============================================================== + -S take password from stdin (equivalent to setting the environment + variable ``PASSWD_FD=0`` + -V print mount.cifs version + -? display simple usage information +=============== =============================================================== + +With most 2.6 kernel versions of modutils, the version of the cifs kernel +module can be displayed via modinfo. + +Misc /proc/fs/cifs Flags and Debug Info +======================================= + +Informational pseudo-files: + +======================= ======================================================= +DebugData Displays information about active CIFS sessions and + shares, features enabled as well as the cifs.ko + version. +Stats Lists summary resource usage information as well as per + share statistics. +======================= ======================================================= + +Configuration pseudo-files: + +======================= ======================================================= +SecurityFlags Flags which control security negotiation and + also packet signing. Authentication (may/must) + flags (e.g. for NTLM and/or NTLMv2) may be combined with + the signing flags. Specifying two different password + hashing mechanisms (as "must use") on the other hand + does not make much sense. Default flags are:: + + 0x07007 + + (NTLM, NTLMv2 and packet signing allowed). The maximum + allowable flags if you want to allow mounts to servers + using weaker password hashes is 0x37037 (lanman, + plaintext, ntlm, ntlmv2, signing allowed). Some + SecurityFlags require the corresponding menuconfig + options to be enabled (lanman and plaintext require + CONFIG_CIFS_WEAK_PW_HASH for example). Enabling + plaintext authentication currently requires also + enabling lanman authentication in the security flags + because the cifs module only supports sending + laintext passwords using the older lanman dialect + form of the session setup SMB. (e.g. for authentication + using plain text passwords, set the SecurityFlags + to 0x30030):: + + may use packet signing 0x00001 + must use packet signing 0x01001 + may use NTLM (most common password hash) 0x00002 + must use NTLM 0x02002 + may use NTLMv2 0x00004 + must use NTLMv2 0x04004 + may use Kerberos security 0x00008 + must use Kerberos 0x08008 + may use lanman (weak) password hash 0x00010 + must use lanman password hash 0x10010 + may use plaintext passwords 0x00020 + must use plaintext passwords 0x20020 + (reserved for future packet encryption) 0x00040 + +cifsFYI If set to non-zero value, additional debug information + will be logged to the system error log. This field + contains three flags controlling different classes of + debugging entries. The maximum value it can be set + to is 7 which enables all debugging points (default 0). + Some debugging statements are not compiled into the + cifs kernel unless CONFIG_CIFS_DEBUG2 is enabled in the + kernel configuration. cifsFYI may be set to one or + nore of the following flags (7 sets them all):: + + +-----------------------------------------------+------+ + | log cifs informational messages | 0x01 | + +-----------------------------------------------+------+ + | log return codes from cifs entry points | 0x02 | + +-----------------------------------------------+------+ + | log slow responses | 0x04 | + | (ie which take longer than 1 second) | | + | | | + | CONFIG_CIFS_STATS2 must be enabled in .config | | + +-----------------------------------------------+------+ + +traceSMB If set to one, debug information is logged to the + system error log with the start of smb requests + and responses (default 0) +LookupCacheEnable If set to one, inode information is kept cached + for one second improving performance of lookups + (default 1) +LinuxExtensionsEnabled If set to one then the client will attempt to + use the CIFS "UNIX" extensions which are optional + protocol enhancements that allow CIFS servers + to return accurate UID/GID information as well + as support symbolic links. If you use servers + such as Samba that support the CIFS Unix + extensions but do not want to use symbolic link + support and want to map the uid and gid fields + to values supplied at mount (rather than the + actual values, then set this to zero. (default 1) +======================= ======================================================= + +These experimental features and tracing can be enabled by changing flags in +/proc/fs/cifs (after the cifs module has been installed or built into the +kernel, e.g. insmod cifs). To enable a feature set it to 1 e.g. to enable +tracing to the kernel message log type:: + + echo 7 > /proc/fs/cifs/cifsFYI + +cifsFYI functions as a bit mask. Setting it to 1 enables additional kernel +logging of various informational messages. 2 enables logging of non-zero +SMB return codes while 4 enables logging of requests that take longer +than one second to complete (except for byte range lock requests). +Setting it to 4 requires CONFIG_CIFS_STATS2 to be set in kernel configuration +(.config). Setting it to seven enables all three. Finally, tracing +the start of smb requests and responses can be enabled via:: + + echo 1 > /proc/fs/cifs/traceSMB + +Per share (per client mount) statistics are available in /proc/fs/cifs/Stats. +Additional information is available if CONFIG_CIFS_STATS2 is enabled in the +kernel configuration (.config). The statistics returned include counters which +represent the number of attempted and failed (ie non-zero return code from the +server) SMB3 (or cifs) requests grouped by request type (read, write, close etc.). +Also recorded is the total bytes read and bytes written to the server for +that share. Note that due to client caching effects this can be less than the +number of bytes read and written by the application running on the client. +Statistics can be reset to zero by ``echo 0 > /proc/fs/cifs/Stats`` which may be +useful if comparing performance of two different scenarios. + +Also note that ``cat /proc/fs/cifs/DebugData`` will display information about +the active sessions and the shares that are mounted. + +Enabling Kerberos (extended security) works but requires version 1.2 or later +of the helper program cifs.upcall to be present and to be configured in the +/etc/request-key.conf file. The cifs.upcall helper program is from the Samba +project(http://www.samba.org). NTLM and NTLMv2 and LANMAN support do not +require this helper. Note that NTLMv2 security (which does not require the +cifs.upcall helper program), instead of using Kerberos, is sufficient for +some use cases. + +DFS support allows transparent redirection to shares in an MS-DFS name space. +In addition, DFS support for target shares which are specified as UNC +names which begin with host names (rather than IP addresses) requires +a user space helper (such as cifs.upcall) to be present in order to +translate host names to ip address, and the user space helper must also +be configured in the file /etc/request-key.conf. Samba, Windows servers and +many NAS appliances support DFS as a way of constructing a global name +space to ease network configuration and improve reliability. + +To use cifs Kerberos and DFS support, the Linux keyutils package should be +installed and something like the following lines should be added to the +/etc/request-key.conf file:: + + create cifs.spnego * * /usr/local/sbin/cifs.upcall %k + create dns_resolver * * /usr/local/sbin/cifs.upcall %k + +CIFS kernel module parameters +============================= +These module parameters can be specified or modified either during the time of +module loading or during the runtime by using the interface:: + + /proc/module/cifs/parameters/ + +i.e.:: + + echo "value" > /sys/module/cifs/parameters/ + +================= ========================================================== +1. enable_oplocks Enable or disable oplocks. Oplocks are enabled by default. + [Y/y/1]. To disable use any of [N/n/0]. +================= ========================================================== diff --git a/Documentation/filesystems/cifs/winucase_convert.pl b/Documentation/admin-guide/cifs/winucase_convert.pl similarity index 100% rename from Documentation/filesystems/cifs/winucase_convert.pl rename to Documentation/admin-guide/cifs/winucase_convert.pl diff --git a/Documentation/admin-guide/device-mapper/dm-clone.rst b/Documentation/admin-guide/device-mapper/dm-clone.rst new file mode 100644 index 000000000000..b43a34c1430a --- /dev/null +++ b/Documentation/admin-guide/device-mapper/dm-clone.rst @@ -0,0 +1,333 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +======== +dm-clone +======== + +Introduction +============ + +dm-clone is a device mapper target which produces a one-to-one copy of an +existing, read-only source device into a writable destination device: It +presents a virtual block device which makes all data appear immediately, and +redirects reads and writes accordingly. + +The main use case of dm-clone is to clone a potentially remote, high-latency, +read-only, archival-type block device into a writable, fast, primary-type device +for fast, low-latency I/O. The cloned device is visible/mountable immediately +and the copy of the source device to the destination device happens in the +background, in parallel with user I/O. + +For example, one could restore an application backup from a read-only copy, +accessible through a network storage protocol (NBD, Fibre Channel, iSCSI, AoE, +etc.), into a local SSD or NVMe device, and start using the device immediately, +without waiting for the restore to complete. + +When the cloning completes, the dm-clone table can be removed altogether and be +replaced, e.g., by a linear table, mapping directly to the destination device. + +The dm-clone target reuses the metadata library used by the thin-provisioning +target. + +Glossary +======== + + Hydration + The process of filling a region of the destination device with data from + the same region of the source device, i.e., copying the region from the + source to the destination device. + +Once a region gets hydrated we redirect all I/O regarding it to the destination +device. + +Design +====== + +Sub-devices +----------- + +The target is constructed by passing three devices to it (along with other +parameters detailed later): + +1. A source device - the read-only device that gets cloned and source of the + hydration. + +2. A destination device - the destination of the hydration, which will become a + clone of the source device. + +3. A small metadata device - it records which regions are already valid in the + destination device, i.e., which regions have already been hydrated, or have + been written to directly, via user I/O. + +The size of the destination device must be at least equal to the size of the +source device. + +Regions +------- + +dm-clone divides the source and destination devices in fixed sized regions. +Regions are the unit of hydration, i.e., the minimum amount of data copied from +the source to the destination device. + +The region size is configurable when you first create the dm-clone device. The +recommended region size is the same as the file system block size, which usually +is 4KB. The region size must be between 8 sectors (4KB) and 2097152 sectors +(1GB) and a power of two. + +Reads and writes from/to hydrated regions are serviced from the destination +device. + +A read to a not yet hydrated region is serviced directly from the source device. + +A write to a not yet hydrated region will be delayed until the corresponding +region has been hydrated and the hydration of the region starts immediately. + +Note that a write request with size equal to region size will skip copying of +the corresponding region from the source device and overwrite the region of the +destination device directly. + +Discards +-------- + +dm-clone interprets a discard request to a range that hasn't been hydrated yet +as a hint to skip hydration of the regions covered by the request, i.e., it +skips copying the region's data from the source to the destination device, and +only updates its metadata. + +If the destination device supports discards, then by default dm-clone will pass +down discard requests to it. + +Background Hydration +-------------------- + +dm-clone copies continuously from the source to the destination device, until +all of the device has been copied. + +Copying data from the source to the destination device uses bandwidth. The user +can set a throttle to prevent more than a certain amount of copying occurring at +any one time. Moreover, dm-clone takes into account user I/O traffic going to +the devices and pauses the background hydration when there is I/O in-flight. + +A message `hydration_threshold <#regions>` can be used to set the maximum number +of regions being copied, the default being 1 region. + +dm-clone employs dm-kcopyd for copying portions of the source device to the +destination device. By default, we issue copy requests of size equal to the +region size. A message `hydration_batch_size <#regions>` can be used to tune the +size of these copy requests. Increasing the hydration batch size results in +dm-clone trying to batch together contiguous regions, so we copy the data in +batches of this many regions. + +When the hydration of the destination device finishes, a dm event will be sent +to user space. + +Updating on-disk metadata +------------------------- + +On-disk metadata is committed every time a FLUSH or FUA bio is written. If no +such requests are made then commits will occur every second. This means the +dm-clone device behaves like a physical disk that has a volatile write cache. If +power is lost you may lose some recent writes. The metadata should always be +consistent in spite of any crash. + +Target Interface +================ + +Constructor +----------- + + :: + + clone + [<#feature args> []* [<#core args> []*]] + + ================ ============================================================== + metadata dev Fast device holding the persistent metadata + destination dev The destination device, where the source will be cloned + source dev Read only device containing the data that gets cloned + region size The size of a region in sectors + + #feature args Number of feature arguments passed + feature args no_hydration or no_discard_passdown + + #core args An even number of arguments corresponding to key/value pairs + passed to dm-clone + core args Key/value pairs passed to dm-clone, e.g. `hydration_threshold + 256` + ================ ============================================================== + +Optional feature arguments are: + + ==================== ========================================================= + no_hydration Create a dm-clone instance with background hydration + disabled + no_discard_passdown Disable passing down discards to the destination device + ==================== ========================================================= + +Optional core arguments are: + + ================================ ============================================== + hydration_threshold <#regions> Maximum number of regions being copied from + the source to the destination device at any + one time, during background hydration. + hydration_batch_size <#regions> During background hydration, try to batch + together contiguous regions, so we copy data + from the source to the destination device in + batches of this many regions. + ================================ ============================================== + +Status +------ + + :: + + <#used metadata blocks>/<#total metadata blocks> + <#hydrated regions>/<#total regions> <#hydrating regions> + <#feature args> * <#core args> * + + + ======================= ======================================================= + metadata block size Fixed block size for each metadata block in sectors + #used metadata blocks Number of metadata blocks used + #total metadata blocks Total number of metadata blocks + region size Configurable region size for the device in sectors + #hydrated regions Number of regions that have finished hydrating + #total regions Total number of regions to hydrate + #hydrating regions Number of regions currently hydrating + #feature args Number of feature arguments to follow + feature args Feature arguments, e.g. `no_hydration` + #core args Even number of core arguments to follow + core args Key/value pairs for tuning the core, e.g. + `hydration_threshold 256` + clone metadata mode ro if read-only, rw if read-write + + In serious cases where even a read-only mode is deemed + unsafe no further I/O will be permitted and the status + will just contain the string 'Fail'. If the metadata + mode changes, a dm event will be sent to user space. + ======================= ======================================================= + +Messages +-------- + + `disable_hydration` + Disable the background hydration of the destination device. + + `enable_hydration` + Enable the background hydration of the destination device. + + `hydration_threshold <#regions>` + Set background hydration threshold. + + `hydration_batch_size <#regions>` + Set background hydration batch size. + +Examples +======== + +Clone a device containing a file system +--------------------------------------- + +1. Create the dm-clone device. + + :: + + dmsetup create clone --table "0 1048576000 clone $metadata_dev $dest_dev \ + $source_dev 8 1 no_hydration" + +2. Mount the device and trim the file system. dm-clone interprets the discards + sent by the file system and it will not hydrate the unused space. + + :: + + mount /dev/mapper/clone /mnt/cloned-fs + fstrim /mnt/cloned-fs + +3. Enable background hydration of the destination device. + + :: + + dmsetup message clone 0 enable_hydration + +4. When the hydration finishes, we can replace the dm-clone table with a linear + table. + + :: + + dmsetup suspend clone + dmsetup load clone --table "0 1048576000 linear $dest_dev 0" + dmsetup resume clone + + The metadata device is no longer needed and can be safely discarded or reused + for other purposes. + +Known issues +============ + +1. We redirect reads, to not-yet-hydrated regions, to the source device. If + reading the source device has high latency and the user repeatedly reads from + the same regions, this behaviour could degrade performance. We should use + these reads as hints to hydrate the relevant regions sooner. Currently, we + rely on the page cache to cache these regions, so we hopefully don't end up + reading them multiple times from the source device. + +2. Release in-core resources, i.e., the bitmaps tracking which regions are + hydrated, after the hydration has finished. + +3. During background hydration, if we fail to read the source or write to the + destination device, we print an error message, but the hydration process + continues indefinitely, until it succeeds. We should stop the background + hydration after a number of failures and emit a dm event for user space to + notice. + +Why not...? +=========== + +We explored the following alternatives before implementing dm-clone: + +1. Use dm-cache with cache size equal to the source device and implement a new + cloning policy: + + * The resulting cache device is not a one-to-one mirror of the source device + and thus we cannot remove the cache device once cloning completes. + + * dm-cache writes to the source device, which violates our requirement that + the source device must be treated as read-only. + + * Caching is semantically different from cloning. + +2. Use dm-snapshot with a COW device equal to the source device: + + * dm-snapshot stores its metadata in the COW device, so the resulting device + is not a one-to-one mirror of the source device. + + * No background copying mechanism. + + * dm-snapshot needs to commit its metadata whenever a pending exception + completes, to ensure snapshot consistency. In the case of cloning, we don't + need to be so strict and can rely on committing metadata every time a FLUSH + or FUA bio is written, or periodically, like dm-thin and dm-cache do. This + improves the performance significantly. + +3. Use dm-mirror: The mirror target has a background copying/mirroring + mechanism, but it writes to all mirrors, thus violating our requirement that + the source device must be treated as read-only. + +4. Use dm-thin's external snapshot functionality. This approach is the most + promising among all alternatives, as the thinly-provisioned volume is a + one-to-one mirror of the source device and handles reads and writes to + un-provisioned/not-yet-cloned areas the same way as dm-clone does. + + Still: + + * There is no background copying mechanism, though one could be implemented. + + * Most importantly, we want to support arbitrary block devices as the + destination of the cloning process and not restrict ourselves to + thinly-provisioned volumes. Thin-provisioning has an inherent metadata + overhead, for maintaining the thin volume mappings, which significantly + degrades performance. + + Moreover, cloning a device shouldn't force the use of thin-provisioning. On + the other hand, if we wish to use thin provisioning, we can just use a thin + LV as dm-clone's destination device. diff --git a/Documentation/admin-guide/device-mapper/verity.rst b/Documentation/admin-guide/device-mapper/verity.rst index a4d1c1476d72..bb02caa45289 100644 --- a/Documentation/admin-guide/device-mapper/verity.rst +++ b/Documentation/admin-guide/device-mapper/verity.rst @@ -125,6 +125,13 @@ check_at_most_once blocks, and a hash block will not be verified any more after all the data blocks it covers have been verified anyway. +root_hash_sig_key_desc + This is the description of the USER_KEY that the kernel will lookup to get + the pkcs7 signature of the roothash. The pkcs7 signature is used to validate + the root hash during the creation of the device mapper block device. + Verification of roothash depends on the config DM_VERITY_VERIFY_ROOTHASH_SIG + being set in the kernel. + Theory of operation =================== diff --git a/Documentation/admin-guide/devices.txt b/Documentation/admin-guide/devices.txt index e56e00655153..1c5d2281efc9 100644 --- a/Documentation/admin-guide/devices.txt +++ b/Documentation/admin-guide/devices.txt @@ -1647,8 +1647,17 @@ 0 = /dev/comedi0 First comedi device 1 = /dev/comedi1 Second comedi device ... + 47 = /dev/comedi47 48th comedi device - See http://stm.lbl.gov/comedi. + Minors 48 to 255 are reserved for comedi subdevices with + pathnames of the form "/dev/comediX_subdY", where "X" is the + minor number of the associated comedi device and "Y" is the + subdevice number. These subdevice minors are assigned + dynamically, so there is no fixed mapping from subdevice + pathnames to minor numbers. + + See http://www.comedi.org/ for information about the Comedi + project. 98 block User-mode virtual block device 0 = /dev/ubda First user-mode block device diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst index 25f3b2532198..e05e581af5cf 100644 --- a/Documentation/admin-guide/hw-vuln/spectre.rst +++ b/Documentation/admin-guide/hw-vuln/spectre.rst @@ -41,10 +41,11 @@ Related CVEs The following CVE entries describe Spectre variants: - ============= ======================= ================= + ============= ======================= ========================== CVE-2017-5753 Bounds check bypass Spectre variant 1 CVE-2017-5715 Branch target injection Spectre variant 2 - ============= ======================= ================= + CVE-2019-1125 Spectre v1 swapgs Spectre variant 1 (swapgs) + ============= ======================= ========================== Problem ------- @@ -78,6 +79,13 @@ There are some extensions of Spectre variant 1 attacks for reading data over the network, see :ref:`[12] `. However such attacks are difficult, low bandwidth, fragile, and are considered low risk. +Note that, despite "Bounds Check Bypass" name, Spectre variant 1 is not +only about user-controlled array bounds checks. It can affect any +conditional checks. The kernel entry code interrupt, exception, and NMI +handlers all have conditional swapgs checks. Those may be problematic +in the context of Spectre v1, as kernel code can speculatively run with +a user GS. + Spectre variant 2 (Branch Target Injection) ------------------------------------------- @@ -132,6 +140,9 @@ not cover all possible attack vectors. 1. A user process attacking the kernel ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Spectre variant 1 +~~~~~~~~~~~~~~~~~ + The attacker passes a parameter to the kernel via a register or via a known address in memory during a syscall. Such parameter may be used later by the kernel as an index to an array or to derive @@ -144,7 +155,40 @@ not cover all possible attack vectors. potentially be influenced for Spectre attacks, new "nospec" accessor macros are used to prevent speculative loading of data. - Spectre variant 2 attacker can :ref:`poison ` the branch +Spectre variant 1 (swapgs) +~~~~~~~~~~~~~~~~~~~~~~~~~~ + + An attacker can train the branch predictor to speculatively skip the + swapgs path for an interrupt or exception. If they initialize + the GS register to a user-space value, if the swapgs is speculatively + skipped, subsequent GS-related percpu accesses in the speculation + window will be done with the attacker-controlled GS value. This + could cause privileged memory to be accessed and leaked. + + For example: + + :: + + if (coming from user space) + swapgs + mov %gs:, %reg + mov (%reg), %reg1 + + When coming from user space, the CPU can speculatively skip the + swapgs, and then do a speculative percpu load using the user GS + value. So the user can speculatively force a read of any kernel + value. If a gadget exists which uses the percpu value as an address + in another load/store, then the contents of the kernel value may + become visible via an L1 side channel attack. + + A similar attack exists when coming from kernel space. The CPU can + speculatively do the swapgs, causing the user GS to get used for the + rest of the speculative window. + +Spectre variant 2 +~~~~~~~~~~~~~~~~~ + + A spectre variant 2 attacker can :ref:`poison ` the branch target buffer (BTB) before issuing syscall to launch an attack. After entering the kernel, the kernel could use the poisoned branch target buffer on indirect jump and jump to gadget code in speculative @@ -280,11 +324,18 @@ The sysfs file showing Spectre variant 1 mitigation status is: The possible values in this file are: - ======================================= ================================= - 'Mitigation: __user pointer sanitation' Protection in kernel on a case by - case base with explicit pointer - sanitation. - ======================================= ================================= + .. list-table:: + + * - 'Not affected' + - The processor is not vulnerable. + * - 'Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers' + - The swapgs protections are disabled; otherwise it has + protection in the kernel on a case by case base with explicit + pointer sanitation and usercopy LFENCE barriers. + * - 'Mitigation: usercopy/swapgs barriers and __user pointer sanitization' + - Protection in the kernel on a case by case base with explicit + pointer sanitation, usercopy LFENCE barriers, and swapgs LFENCE + barriers. However, the protections are put in place on a case by case basis, and there is no guarantee that all possible attack vectors for Spectre @@ -366,12 +417,27 @@ Turning on mitigation for Spectre variant 1 and Spectre variant 2 1. Kernel mitigation ^^^^^^^^^^^^^^^^^^^^ +Spectre variant 1 +~~~~~~~~~~~~~~~~~ + For the Spectre variant 1, vulnerable kernel code (as determined by code audit or scanning tools) is annotated on a case by case basis to use nospec accessor macros for bounds clipping :ref:`[2] ` to avoid any usable disclosure gadgets. However, it may not cover all attack vectors for Spectre variant 1. + Copy-from-user code has an LFENCE barrier to prevent the access_ok() + check from being mis-speculated. The barrier is done by the + barrier_nospec() macro. + + For the swapgs variant of Spectre variant 1, LFENCE barriers are + added to interrupt, exception and NMI entry where needed. These + barriers are done by the FENCE_SWAPGS_KERNEL_ENTRY and + FENCE_SWAPGS_USER_ENTRY macros. + +Spectre variant 2 +~~~~~~~~~~~~~~~~~ + For Spectre variant 2 mitigation, the compiler turns indirect calls or jumps in the kernel into equivalent return trampolines (retpolines) :ref:`[3] ` :ref:`[9] ` to go to the target @@ -473,6 +539,12 @@ Mitigation control on the kernel command line Spectre variant 2 mitigation can be disabled or force enabled at the kernel command line. + nospectre_v1 + + [X86,PPC] Disable mitigations for Spectre Variant 1 + (bounds check bypass). With this option data leaks are + possible in the system. + nospectre_v2 [X86] Disable all mitigations for the Spectre variant 2 diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index 33feab2f4084..34cc20ee7f3a 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -77,7 +77,10 @@ configure specific aspects of kernel behavior to your liking. blockdev/index ext4 binderfs + cifs/index xfs + jfs + ufs pm/index thunderbolt LSM/index @@ -98,6 +101,7 @@ configure specific aspects of kernel behavior to your liking. iostats kernel-per-CPU-kthreads laptops/index + auxdisplay/index lcd-panel-cgram ldm lockup-watchdogs @@ -105,6 +109,7 @@ configure specific aspects of kernel behavior to your liking. pnp rtc svga + wimax/index video-output .. only:: subproject and html diff --git a/Documentation/admin-guide/jfs.rst b/Documentation/admin-guide/jfs.rst new file mode 100644 index 000000000000..9e12d936bc90 --- /dev/null +++ b/Documentation/admin-guide/jfs.rst @@ -0,0 +1,66 @@ +=========================================== +IBM's Journaled File System (JFS) for Linux +=========================================== + +JFS Homepage: http://jfs.sourceforge.net/ + +The following mount options are supported: + +(*) == default + +iocharset=name + Character set to use for converting from Unicode to + ASCII. The default is to do no conversion. Use + iocharset=utf8 for UTF-8 translations. This requires + CONFIG_NLS_UTF8 to be set in the kernel .config file. + iocharset=none specifies the default behavior explicitly. + +resize=value + Resize the volume to blocks. JFS only supports + growing a volume, not shrinking it. This option is only + valid during a remount, when the volume is mounted + read-write. The resize keyword with no value will grow + the volume to the full size of the partition. + +nointegrity + Do not write to the journal. The primary use of this option + is to allow for higher performance when restoring a volume + from backup media. The integrity of the volume is not + guaranteed if the system abnormally abends. + +integrity(*) + Commit metadata changes to the journal. Use this option to + remount a volume where the nointegrity option was + previously specified in order to restore normal behavior. + +errors=continue + Keep going on a filesystem error. +errors=remount-ro(*) + Remount the filesystem read-only on an error. +errors=panic + Panic and halt the machine if an error occurs. + +uid=value + Override on-disk uid with specified value +gid=value + Override on-disk gid with specified value +umask=value + Override on-disk umask with specified octal value. For + directories, the execute bit will be set if the corresponding + read bit is set. + +discard=minlen, discard/nodiscard(*) + This enables/disables the use of discard/TRIM commands. + The discard/TRIM commands are sent to the underlying + block device when blocks are freed. This is useful for SSD + devices and sparse/thinly-provisioned LUNs. The FITRIM ioctl + command is also available together with the nodiscard option. + The value of minlen specifies the minimum blockcount, when + a TRIM command to the block device is considered useful. + When no value is given to the discard option, it defaults to + 64 blocks, which means 256KiB in JFS. + The minlen value of discard overrides the minlen value given + on an FITRIM ioctl(). + +The JFS mailing list can be subscribed to by using the link labeled +"Mail list Subscribe" at our web page http://jfs.sourceforge.net/ diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 7ccd158b3894..c7ac2f3ac99f 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -809,6 +809,8 @@ enables the feature at boot time. By default, it is disabled and the system will work mostly the same as a kernel built without CONFIG_DEBUG_PAGEALLOC. + Note: to get most of debug_pagealloc error reports, it's + useful to also enable the page_owner functionality. on: enable the feature debugpat [X86] Enable PAT debugging @@ -860,6 +862,10 @@ disable_radix [PPC] Disable RADIX MMU mode on POWER9 + disable_tlbie [PPC] + Disable TLBIE instruction. Currently does not work + with KVM, with HASH MMU, or with coherent accelerators. + disable_cpu_apicid= [X86,APIC,SMP] Format: The number of initial APIC ID for the @@ -1044,6 +1050,10 @@ specified address. The serial port must already be setup and configured. Options are not yet supported. + sbi + Use RISC-V SBI (Supervisor Binary Interface) for early + console. + smh Use ARM semihosting calls for early console. s3c2410, @@ -1090,6 +1100,12 @@ the framebuffer, pass the 'ram' option so that it is mapped with the correct attributes. + linflex, + Use early console provided by Freescale LinFlex UART + serial driver for NXP S32V234 SoCs. A valid base + address must be provided, and the serial port must + already be setup and configured. + earlyprintk= [X86,SH,ARM,M68k,S390] earlyprintk=vga earlyprintk=sclp @@ -1197,12 +1213,6 @@ See comment before function elanfreq_setup() in arch/x86/kernel/cpu/cpufreq/elanfreq.c. - elevator= [IOSCHED] - Format: { "mq-deadline" | "kyber" | "bfq" } - See Documentation/block/deadline-iosched.rst, - Documentation/block/kyber-iosched.rst and - Documentation/block/bfq-iosched.rst for details. - elfcorehdr=[size[KMG]@]offset[KMG] [IA64,PPC,SH,X86,S390] Specifies physical address of start of kernel core image elf header and optionally the size. Generally @@ -1732,6 +1742,11 @@ Note that using this option lowers the security provided by tboot because it makes the system vulnerable to DMA attacks. + nobounce [Default off] + Disable bounce buffer for unstrusted devices such as + the Thunderbolt devices. This will treat the untrusted + devices as the trusted ones, hence might expose security + risks of DMA attacks. intel_idle.max_cstate= [KNL,HW,ACPI,X86] 0 disables intel_idle and fall back on acpi_idle. @@ -1811,7 +1826,7 @@ synchronously. iommu.passthrough= - [ARM64] Configure DMA to bypass the IOMMU by default. + [ARM64, X86] Configure DMA to bypass the IOMMU by default. Format: { "0" | "1" } 0 - Use IOMMU translation for DMA. 1 - Bypass the IOMMU for DMA. @@ -2261,6 +2276,15 @@ lockd.nlm_udpport=M [NFS] Assign UDP port. Format: + lockdown= [SECURITY] + { integrity | confidentiality } + Enable the kernel lockdown feature. If set to + integrity, kernel features that allow userland to + modify the running kernel are disabled. If set to + confidentiality, kernel features that allow userland + to extract confidential information from the kernel + are also disabled. + locktorture.nreaders_stress= [KNL] Set the number of locking read-acquisition kthreads. Defaults to being automatically set based on the @@ -2373,7 +2397,7 @@ machvec= [IA-64] Force the use of a particular machine-vector (machvec) in a generic kernel. - Example: machvec=hpzx1_swiotlb + Example: machvec=hpzx1 machtype= [Loongson] Share the same kernel image file between different yeeloong laptop. @@ -2604,7 +2628,7 @@ expose users to several CPU vulnerabilities. Equivalent to: nopti [X86,PPC] kpti=0 [ARM64] - nospectre_v1 [PPC] + nospectre_v1 [X86,PPC] nobp=0 [S390] nospectre_v2 [X86,PPC,S390,ARM64] spectre_v2_user=off [X86] @@ -2965,9 +2989,9 @@ nosmt=force: Force disable SMT, cannot be undone via the sysfs control file. - nospectre_v1 [PPC] Disable mitigations for Spectre Variant 1 (bounds - check bypass). With this option data leaks are possible - in the system. + nospectre_v1 [X86,PPC] Disable mitigations for Spectre Variant 1 + (bounds check bypass). With this option data leaks are + possible in the system. nospectre_v2 [X86,PPC_FSL_BOOK3E,ARM64] Disable all mitigations for the Spectre variant 2 (indirect branch prediction) @@ -3452,12 +3476,13 @@ specify the device is described above. If is not specified, PAGE_SIZE is used as alignment. - PCI-PCI bridge can be specified, if resource + A PCI-PCI bridge can be specified if resource windows need to be expanded. To specify the alignment for several instances of a device, the PCI vendor, device, subvendor, and subdevice may be - specified, e.g., 4096@pci:8086:9c22:103c:198f + specified, e.g., 12@pci:8086:9c22:103c:198f + for 4096-byte alignment. ecrc= Enable/disable PCIe ECRC (transaction layer end-to-end CRC checking). bios: Use BIOS/firmware settings. This is the @@ -3837,12 +3862,13 @@ RCU_BOOST is not set, valid values are 0-99 and the default is zero (non-realtime operation). - rcutree.rcu_nocb_leader_stride= [KNL] - Set the number of NOCB kthread groups, which - defaults to the square root of the number of - CPUs. Larger numbers reduces the wakeup overhead - on the per-CPU grace-period kthreads, but increases - that same overhead on each group's leader. + rcutree.rcu_nocb_gp_stride= [KNL] + Set the number of NOCB callback kthreads in + each group, which defaults to the square root + of the number of CPUs. Larger numbers reduce + the wakeup overhead on the global grace-period + kthread, but increases that same overhead on + each group's NOCB grace-period kthread. rcutree.qhimark= [KNL] Set threshold of queued RCU callbacks beyond which @@ -4047,6 +4073,10 @@ rcutorture.verbose= [KNL] Enable additional printk() statements. + rcupdate.rcu_cpu_stall_ftrace_dump= [KNL] + Dump ftrace buffer after reporting RCU CPU + stall warning. + rcupdate.rcu_cpu_stall_suppress= [KNL] Suppress RCU CPU stall warning messages. @@ -4090,6 +4120,13 @@ Run specified binary instead of /init from the ramdisk, used for early userspace startup. See initrd. + rdrand= [X86] + force - Override the decision by the kernel to hide the + advertisement of RDRAND support (this affects + certain AMD processors because of buggy BIOS + support, specifically around the suspend/resume + path). + rdt= [HW,X86,RDT] Turn on/off individual RDT features. List is: cmt, mbmtotal, mbmlocal, l3cat, l3cdp, l2cat, l2cdp, @@ -4620,6 +4657,11 @@ /sys/power/pm_test). Only available when CONFIG_PM_DEBUG is set. Default value is 5. + svm= [PPC] + Format: { on | off | y | n | 1 | 0 } + This parameter controls use of the Protected + Execution Facility on pSeries. + swapaccount=[0|1] [KNL] Enable accounting of swap in memory resource controller if no parameter or 1 is given or disable @@ -5305,3 +5347,22 @@ A hex value specifying bitmask with supplemental xhci host controller quirks. Meaning of each bit can be consulted in header drivers/usb/host/xhci.h. + + xmon [PPC] + Format: { early | on | rw | ro | off } + Controls if xmon debugger is enabled. Default is off. + Passing only "xmon" is equivalent to "xmon=early". + early Call xmon as early as possible on boot; xmon + debugger is called from setup_arch(). + on xmon debugger hooks will be installed so xmon + is only called on a kernel crash. Default mode, + i.e. either "ro" or "rw" mode, is controlled + with CONFIG_XMON_DEFAULT_RO_MODE. + rw xmon debugger hooks will be installed so xmon + is called only on a kernel crash, mode is write, + meaning SPR registers, memory and, other data + can be written using xmon commands. + ro same as "rw" option above but SPR registers, + memory, and other data can't be written using + xmon commands. + off xmon is disabled. diff --git a/Documentation/admin-guide/kernel-per-CPU-kthreads.rst b/Documentation/admin-guide/kernel-per-CPU-kthreads.rst index 4f18456dd3b1..baeeba8762ae 100644 --- a/Documentation/admin-guide/kernel-per-CPU-kthreads.rst +++ b/Documentation/admin-guide/kernel-per-CPU-kthreads.rst @@ -274,9 +274,7 @@ To reduce its OS jitter, do any of the following: (based on an earlier one from Gilad Ben-Yossef) that reduces or even eliminates vmstat overhead for some workloads at https://lkml.org/lkml/2013/9/4/379. - e. Boot with "elevator=noop" to avoid workqueue use by - the block layer. - f. If running on high-end powerpc servers, build with + e. If running on high-end powerpc servers, build with CONFIG_PPC_RTAS_DAEMON=n. This prevents the RTAS daemon from running on each CPU every second or so. (This will require editing Kconfig files and will defeat @@ -284,12 +282,12 @@ To reduce its OS jitter, do any of the following: due to the rtas_event_scan() function. WARNING: Please check your CPU specifications to make sure that this is safe on your particular system. - g. If running on Cell Processor, build your kernel with + f. If running on Cell Processor, build your kernel with CBE_CPUFREQ_SPU_GOVERNOR=n to avoid OS jitter from spu_gov_work(). WARNING: Please check your CPU specifications to make sure that this is safe on your particular system. - h. If running on PowerMAC, build your kernel with + g. If running on PowerMAC, build your kernel with CONFIG_PMAC_RACKMETER=n to disable the CPU-meter, avoiding OS jitter from rackmeter_do_timer(). diff --git a/Documentation/admin-guide/laptops/thinkpad-acpi.rst b/Documentation/admin-guide/laptops/thinkpad-acpi.rst index adea0bf2acc5..822907dcc845 100644 --- a/Documentation/admin-guide/laptops/thinkpad-acpi.rst +++ b/Documentation/admin-guide/laptops/thinkpad-acpi.rst @@ -49,6 +49,7 @@ detailed description): - Fan control and monitoring: fan speed, fan enable/disable - WAN enable and disable - UWB enable and disable + - LCD Shadow (PrivacyGuard) enable and disable A compatibility table by model and feature is maintained on the web site, http://ibm-acpi.sf.net/. I appreciate any success or failure @@ -1409,6 +1410,28 @@ Sysfs notes Documentation/driver-api/rfkill.rst for details. +LCD Shadow control +------------------ + +procfs: /proc/acpi/ibm/lcdshadow + +Some newer T480s and T490s ThinkPads provide a feature called +PrivacyGuard. By turning this feature on, the usable vertical and +horizontal viewing angles of the LCD can be limited (as if some privacy +screen was applied manually in front of the display). + +procfs notes +^^^^^^^^^^^^ + +The available commands are:: + + echo '0' >/proc/acpi/ibm/lcdshadow + echo '1' >/proc/acpi/ibm/lcdshadow + +The first command ensures the best viewing angle and the latter one turns +on the feature, restricting the viewing angles. + + EXPERIMENTAL: UWB ----------------- diff --git a/Documentation/admin-guide/perf/imx-ddr.rst b/Documentation/admin-guide/perf/imx-ddr.rst new file mode 100644 index 000000000000..517a205abad6 --- /dev/null +++ b/Documentation/admin-guide/perf/imx-ddr.rst @@ -0,0 +1,52 @@ +===================================================== +Freescale i.MX8 DDR Performance Monitoring Unit (PMU) +===================================================== + +There are no performance counters inside the DRAM controller, so performance +signals are brought out to the edge of the controller where a set of 4 x 32 bit +counters is implemented. This is controlled by the CSV modes programed in counter +control register which causes a large number of PERF signals to be generated. + +Selection of the value for each counter is done via the config registers. There +is one register for each counter. Counter 0 is special in that it always counts +“time” and when expired causes a lock on itself and the other counters and an +interrupt is raised. If any other counter overflows, it continues counting, and +no interrupt is raised. + +The "format" directory describes format of the config (event ID) and config1 +(AXI filtering) fields of the perf_event_attr structure, see /sys/bus/event_source/ +devices/imx8_ddr0/format/. The "events" directory describes the events types +hardware supported that can be used with perf tool, see /sys/bus/event_source/ +devices/imx8_ddr0/events/. + e.g.:: + perf stat -a -e imx8_ddr0/cycles/ cmd + perf stat -a -e imx8_ddr0/read/,imx8_ddr0/write/ cmd + +AXI filtering is only used by CSV modes 0x41 (axid-read) and 0x42 (axid-write) +to count reading or writing matches filter setting. Filter setting is various +from different DRAM controller implementations, which is distinguished by quirks +in the driver. + +* With DDR_CAP_AXI_ID_FILTER quirk. + Filter is defined with two configuration parts: + --AXI_ID defines AxID matching value. + --AXI_MASKING defines which bits of AxID are meaningful for the matching. + 0：corresponding bit is masked. + 1: corresponding bit is not masked, i.e. used to do the matching. + + AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance counter. + When non-masked bits are matching corresponding AXI_ID bits then counter is + incremented. Perf counter is incremented if + AxID && AXI_MASKING == AXI_ID && AXI_MASKING + + This filter doesn't support filter different AXI ID for axid-read and axid-write + event at the same time as this filter is shared between counters. + e.g.:: + perf stat -a -e imx8_ddr0/axid-read,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd + perf stat -a -e imx8_ddr0/axid-write,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd + + NOTE: axi_mask is inverted in userspace(i.e. set bits are bits to mask), and + it will be reverted in driver automatically. so that the user can just specify + axi_id to monitor a specific id, rather than having to specify axi_mask. + e.g.:: + perf stat -a -e imx8_ddr0/axid-read,axi_id=0x12/ cmd, which will monitor ARID=0x12 diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst index a7d44e71019d..287b98708a40 100644 --- a/Documentation/admin-guide/sysctl/net.rst +++ b/Documentation/admin-guide/sysctl/net.rst @@ -39,7 +39,6 @@ Table : Subdirectories in /proc/sys/net 802 E802 protocol ax25 AX25 ethernet Ethernet protocol rose X.25 PLP layer ipv4 IP version 4 x25 X.25 protocol - ipx IPX token-ring IBM token ring bridge Bridging decnet DEC net ipv6 IP version 6 tipc TIPC ========= =================== = ========== ================== @@ -401,33 +400,7 @@ interface. (network) that the route leads to, the router (may be directly connected), the route flags, and the device the route is using. - -5. IPX ------- - -The IPX protocol has no tunable values in proc/sys/net. - -The IPX protocol does, however, provide proc/net/ipx. This lists each IPX -socket giving the local and remote addresses in Novell format (that is -network:node:port). In accordance with the strange Novell tradition, -everything but the port is in hex. Not_Connected is displayed for sockets that -are not tied to a specific remote address. The Tx and Rx queue sizes indicate -the number of bytes pending for transmission and reception. The state -indicates the state the socket is in and the uid is the owning uid of the -socket. - -The /proc/net/ipx_interface file lists all IPX interfaces. For each interface -it gives the network number, the node number, and indicates if the network is -the primary network. It also indicates which device it is bound to (or -Internal for internal networks) and the Frame Type if appropriate. Linux -supports 802.3, 802.2, 802.2 SNAP and DIX (Blue Book) ethernet framing for -IPX. - -The /proc/net/ipx_route table holds a list of IPX routes. For each route it -gives the destination network, the router node (or Directly) and the network -address of the router (or Connected) for internal networks. - -6. TIPC +5. TIPC ------- tipc_rmem diff --git a/Documentation/admin-guide/sysrq.rst b/Documentation/admin-guide/sysrq.rst index 7b9035c01a2e..72b2cfb066f4 100644 --- a/Documentation/admin-guide/sysrq.rst +++ b/Documentation/admin-guide/sysrq.rst @@ -171,22 +171,20 @@ It seems others find it useful as (System Attention Key) which is useful when you want to exit a program that will not let you switch consoles. (For example, X or a svgalib program.) -``reboot(b)`` is good when you're unable to shut down. But you should also -``sync(s)`` and ``umount(u)`` first. +``reboot(b)`` is good when you're unable to shut down, it is an equivalent +of pressing the "reset" button. ``crash(c)`` can be used to manually trigger a crashdump when the system is hung. Note that this just triggers a crash if there is no dump mechanism available. -``sync(s)`` is great when your system is locked up, it allows you to sync your -disks and will certainly lessen the chance of data loss and fscking. Note -that the sync hasn't taken place until you see the "OK" and "Done" appear -on the screen. (If the kernel is really in strife, you may not ever get the -OK or Done message...) +``sync(s)`` is handy before yanking removable medium or after using a rescue +shell that provides no graceful shutdown -- it will ensure your data is +safely written to the disk. Note that the sync hasn't taken place until you see +the "OK" and "Done" appear on the screen. -``umount(u)`` is basically useful in the same ways as ``sync(s)``. I generally -``sync(s)``, ``umount(u)``, then ``reboot(b)`` when my system locks. It's saved -me many a fsck. Again, the unmount (remount read-only) hasn't taken place until -you see the "OK" and "Done" message appear on the screen. +``umount(u)`` can be used to mark filesystems as properly unmounted. From the +running system's point of view, they will be remounted read-only. The remount +isn't complete until you see the "OK" and "Done" message appear on the screen. The loglevels ``0``-``9`` are useful when your console is being flooded with kernel messages you do not want to see. Selecting ``0`` will prevent all but diff --git a/Documentation/admin-guide/ufs.rst b/Documentation/admin-guide/ufs.rst new file mode 100644 index 000000000000..55d15297f8d7 --- /dev/null +++ b/Documentation/admin-guide/ufs.rst @@ -0,0 +1,68 @@ +========= +Using UFS +========= + +mount -t ufs -o ufstype=type_of_ufs device dir + + +UFS Options +=========== + +ufstype=type_of_ufs + UFS is a file system widely used in different operating systems. + The problem are differences among implementations. Features of + some implementations are undocumented, so its hard to recognize + type of ufs automatically. That's why user must specify type of + ufs manually by mount option ufstype. Possible values are: + + old + old format of ufs + default value, supported as read-only + + 44bsd + used in FreeBSD, NetBSD, OpenBSD + supported as read-write + + ufs2 + used in FreeBSD 5.x + supported as read-write + + 5xbsd + synonym for ufs2 + + sun + used in SunOS (Solaris) + supported as read-write + + sunx86 + used in SunOS for Intel (Solarisx86) + supported as read-write + + hp + used in HP-UX + supported as read-only + + nextstep + used in NextStep + supported as read-only + + nextstep-cd + used for NextStep CDROMs (block_size == 2048) + supported as read-only + + openstep + used in OpenStep + supported as read-only + + +Possible Problems +----------------- + +See next section, if you have any. + + +Bug Reports +----------- + +Any ufs bug report you can send to daniel.pirkl@email.cz or +to dushistov@mail.ru (do not send partition tables bug reports). diff --git a/Documentation/admin-guide/wimax/i2400m.rst b/Documentation/admin-guide/wimax/i2400m.rst new file mode 100644 index 000000000000..194388c0c351 --- /dev/null +++ b/Documentation/admin-guide/wimax/i2400m.rst @@ -0,0 +1,283 @@ +.. include:: + +==================================================== +Driver for the Intel Wireless Wimax Connection 2400m +==================================================== + +:Copyright: |copy| 2008 Intel Corporation < linux-wimax@intel.com > + + This provides a driver for the Intel Wireless WiMAX Connection 2400m + and a basic Linux kernel WiMAX stack. + +1. Requirements +=============== + + * Linux installation with Linux kernel 2.6.22 or newer (if building + from a separate tree) + * Intel i2400m Echo Peak or Baxter Peak; this includes the Intel + Wireless WiMAX/WiFi Link 5x50 series. + * build tools: + + + Linux kernel development package for the target kernel; to + build against your currently running kernel, you need to have + the kernel development package corresponding to the running + image installed (usually if your kernel is named + linux-VERSION, the development package is called + linux-dev-VERSION or linux-headers-VERSION). + + GNU C Compiler, make + +2. Compilation and installation +=============================== + +2.1. Compilation of the drivers included in the kernel +------------------------------------------------------ + + Configure the kernel; to enable the WiMAX drivers select Drivers > + Networking Drivers > WiMAX device support. Enable all of them as + modules (easier). + + If USB or SDIO are not enabled in the kernel configuration, the options + to build the i2400m USB or SDIO drivers will not show. Enable said + subsystems and go back to the WiMAX menu to enable the drivers. + + Compile and install your kernel as usual. + +2.2. Compilation of the drivers distributed as an standalone module +------------------------------------------------------------------- + + To compile:: + + $ cd source/directory + $ make + + Once built you can load and unload using the provided load.sh script; + load.sh will load the modules, load.sh u will unload them. + + To install in the default kernel directories (and enable auto loading + when the device is plugged):: + + $ make install + $ depmod -a + + If your kernel development files are located in a non standard + directory or if you want to build for a kernel that is not the + currently running one, set KDIR to the right location:: + + $ make KDIR=/path/to/kernel/dev/tree + + For more information, please contact linux-wimax@intel.com. + +3. Installing the firmware +-------------------------- + + The firmware can be obtained from http://linuxwimax.org or might have + been supplied with your hardware. + + It has to be installed in the target system:: + + $ cp FIRMWAREFILE.sbcf /lib/firmware/i2400m-fw-BUSTYPE-1.3.sbcf + + * NOTE: if your firmware came in an .rpm or .deb file, just install + it as normal, with the rpm (rpm -i FIRMWARE.rpm) or dpkg + (dpkg -i FIRMWARE.deb) commands. No further action is needed. + * BUSTYPE will be usb or sdio, depending on the hardware you have. + Each hardware type comes with its own firmware and will not work + with other types. + +4. Design +========= + + This package contains two major parts: a WiMAX kernel stack and a + driver for the Intel i2400m. + + The WiMAX stack is designed to provide for common WiMAX control + services to current and future WiMAX devices from any vendor; please + see README.wimax for details. + + The i2400m kernel driver is broken up in two main parts: the bus + generic driver and the bus-specific drivers. The bus generic driver + forms the drivercore and contain no knowledge of the actual method we + use to connect to the device. The bus specific drivers are just the + glue to connect the bus-generic driver and the device. Currently only + USB and SDIO are supported. See drivers/net/wimax/i2400m/i2400m.h for + more information. + + The bus generic driver is logically broken up in two parts: OS-glue and + hardware-glue. The OS-glue interfaces with Linux. The hardware-glue + interfaces with the device on using an interface provided by the + bus-specific driver. The reason for this breakup is to be able to + easily reuse the hardware-glue to write drivers for other OSes; note + the hardware glue part is written as a native Linux driver; no + abstraction layers are used, so to port to another OS, the Linux kernel + API calls should be replaced with the target OS's. + +5. Usage +======== + + To load the driver, follow the instructions in the install section; + once the driver is loaded, plug in the device (unless it is permanently + plugged in). The driver will enumerate the device, upload the firmware + and output messages in the kernel log (dmesg, /var/log/messages or + /var/log/kern.log) such as:: + + ... + i2400m_usb 5-4:1.0: firmware interface version 8.0.0 + i2400m_usb 5-4:1.0: WiMAX interface wmx0 (00:1d:e1:01:94:2c) ready + + At this point the device is ready to work. + + Current versions require the Intel WiMAX Network Service in userspace + to make things work. See the network service's README for instructions + on how to scan, connect and disconnect. + +5.1. Module parameters +---------------------- + + Module parameters can be set at kernel or module load time or by + echoing values:: + + $ echo VALUE > /sys/module/MODULENAME/parameters/PARAMETERNAME + + To make changes permanent, for example, for the i2400m module, you can + also create a file named /etc/modprobe.d/i2400m containing:: + + options i2400m idle_mode_disabled=1 + + To find which parameters are supported by a module, run:: + + $ modinfo path/to/module.ko + + During kernel bootup (if the driver is linked in the kernel), specify + the following to the kernel command line:: + + i2400m.PARAMETER=VALUE + +5.1.1. i2400m: idle_mode_disabled +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + The i2400m module supports a parameter to disable idle mode. This + parameter, once set, will take effect only when the device is + reinitialized by the driver (eg: following a reset or a reconnect). + +5.2. Debug operations: debugfs entries +-------------------------------------- + + The driver will register debugfs entries that allow the user to tweak + debug settings. There are three main container directories where + entries are placed, which correspond to the three blocks a i2400m WiMAX + driver has: + + * /sys/kernel/debug/wimax:DEVNAME/ for the generic WiMAX stack + controls + * /sys/kernel/debug/wimax:DEVNAME/i2400m for the i2400m generic + driver controls + * /sys/kernel/debug/wimax:DEVNAME/i2400m-usb (or -sdio) for the + bus-specific i2400m-usb or i2400m-sdio controls). + + Of course, if debugfs is mounted in a directory other than + /sys/kernel/debug, those paths will change. + +5.2.1. Increasing debug output +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + The files named *dl_* indicate knobs for controlling the debug output + of different submodules:: + + # find /sys/kernel/debug/wimax\:wmx0 -name \*dl_\* + /sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_tx + /sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_rx + /sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_notif + /sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_fw + /sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_usb + /sys/kernel/debug/wimax:wmx0/i2400m/dl_tx + /sys/kernel/debug/wimax:wmx0/i2400m/dl_rx + /sys/kernel/debug/wimax:wmx0/i2400m/dl_rfkill + /sys/kernel/debug/wimax:wmx0/i2400m/dl_netdev + /sys/kernel/debug/wimax:wmx0/i2400m/dl_fw + /sys/kernel/debug/wimax:wmx0/i2400m/dl_debugfs + /sys/kernel/debug/wimax:wmx0/i2400m/dl_driver + /sys/kernel/debug/wimax:wmx0/i2400m/dl_control + /sys/kernel/debug/wimax:wmx0/wimax_dl_stack + /sys/kernel/debug/wimax:wmx0/wimax_dl_op_rfkill + /sys/kernel/debug/wimax:wmx0/wimax_dl_op_reset + /sys/kernel/debug/wimax:wmx0/wimax_dl_op_msg + /sys/kernel/debug/wimax:wmx0/wimax_dl_id_table + /sys/kernel/debug/wimax:wmx0/wimax_dl_debugfs + + By reading the file you can obtain the current value of said debug + level; by writing to it, you can set it. + + To increase the debug level of, for example, the i2400m's generic TX + engine, just write:: + + $ echo 3 > /sys/kernel/debug/wimax:wmx0/i2400m/dl_tx + + Increasing numbers yield increasing debug information; for details of + what is printed and the available levels, check the source. The code + uses 0 for disabled and increasing values until 8. + +5.2.2. RX and TX statistics +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + The i2400m/rx_stats and i2400m/tx_stats provide statistics about the + data reception/delivery from the device:: + + $ cat /sys/kernel/debug/wimax:wmx0/i2400m/rx_stats + 45 1 3 34 3104 48 480 + + The numbers reported are: + + * packets/RX-buffer: total, min, max + * RX-buffers: total RX buffers received, accumulated RX buffer size + in bytes, min size received, max size received + + Thus, to find the average buffer size received, divide accumulated + RX-buffer / total RX-buffers. + + To clear the statistics back to 0, write anything to the rx_stats file:: + + $ echo 1 > /sys/kernel/debug/wimax:wmx0/i2400m_rx_stats + + Likewise for TX. + + Note the packets this debug file refers to are not network packet, but + packets in the sense of the device-specific protocol for communication + to the host. See drivers/net/wimax/i2400m/tx.c. + +5.2.3. Tracing messages received from user space +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + To echo messages received from user space into the trace pipe that the + i2400m driver creates, set the debug file i2400m/trace_msg_from_user to + 1:: + + $ echo 1 > /sys/kernel/debug/wimax:wmx0/i2400m/trace_msg_from_user + +5.2.4. Performing a device reset +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + By writing a 0, a 1 or a 2 to the file + /sys/kernel/debug/wimax:wmx0/reset, the driver performs a warm (without + disconnecting from the bus), cold (disconnecting from the bus) or bus + (bus specific) reset on the device. + +5.2.5. Asking the device to enter power saving mode +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + By writing any value to the /sys/kernel/debug/wimax:wmx0 file, the + device will attempt to enter power saving mode. + +6. Troubleshooting +================== + +6.1. Driver complains about ``i2400m-fw-usb-1.2.sbcf: request failed`` +---------------------------------------------------------------------- + + If upon connecting the device, the following is output in the kernel + log:: + + i2400m_usb 5-4:1.0: fw i2400m-fw-usb-1.3.sbcf: request failed: -2 + + This means that the driver cannot locate the firmware file named + /lib/firmware/i2400m-fw-usb-1.2.sbcf. Check that the file is present in + the right location. diff --git a/Documentation/admin-guide/wimax/index.rst b/Documentation/admin-guide/wimax/index.rst new file mode 100644 index 000000000000..fdf7c1f99ff5 --- /dev/null +++ b/Documentation/admin-guide/wimax/index.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============== +WiMAX subsystem +=============== + +.. toctree:: + :maxdepth: 2 + + wimax + + i2400m + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/admin-guide/wimax/wimax.rst b/Documentation/admin-guide/wimax/wimax.rst new file mode 100644 index 000000000000..817ee8ba2732 --- /dev/null +++ b/Documentation/admin-guide/wimax/wimax.rst @@ -0,0 +1,89 @@ +.. include:: + +======================== +Linux kernel WiMAX stack +======================== + +:Copyright: |copy| 2008 Intel Corporation < linux-wimax@intel.com > + + This provides a basic Linux kernel WiMAX stack to provide a common + control API for WiMAX devices, usable from kernel and user space. + +1. Design +========= + + The WiMAX stack is designed to provide for common WiMAX control + services to current and future WiMAX devices from any vendor. + + Because currently there is only one and we don't know what would be the + common services, the APIs it currently provides are very minimal. + However, it is done in such a way that it is easily extensible to + accommodate future requirements. + + The stack works by embedding a struct wimax_dev in your device's + control structures. This provides a set of callbacks that the WiMAX + stack will call in order to implement control operations requested by + the user. As well, the stack provides API functions that the driver + calls to notify about changes of state in the device. + + The stack exports the API calls needed to control the device to user + space using generic netlink as a marshalling mechanism. You can access + them using your own code or use the wrappers provided for your + convenience in libwimax (in the wimax-tools package). + + For detailed information on the stack, please see + include/linux/wimax.h. + +2. Usage +======== + + For usage in a driver (registration, API, etc) please refer to the + instructions in the header file include/linux/wimax.h. + + When a device is registered with the WiMAX stack, a set of debugfs + files will appear in /sys/kernel/debug/wimax:wmxX can tweak for + control. + +2.1. Obtaining debug information: debugfs entries +------------------------------------------------- + + The WiMAX stack is compiled, by default, with debug messages that can + be used to diagnose issues. By default, said messages are disabled. + + The drivers will register debugfs entries that allow the user to tweak + debug settings. + + Each driver, when registering with the stack, will cause a debugfs + directory named wimax:DEVICENAME to be created; optionally, it might + create more subentries below it. + +2.1.1. Increasing debug output +------------------------------ + + The files named *dl_* indicate knobs for controlling the debug output + of different submodules of the WiMAX stack:: + + # find /sys/kernel/debug/wimax\:wmx0 -name \*dl_\* + /sys/kernel/debug/wimax:wmx0/wimax_dl_stack + /sys/kernel/debug/wimax:wmx0/wimax_dl_op_rfkill + /sys/kernel/debug/wimax:wmx0/wimax_dl_op_reset + /sys/kernel/debug/wimax:wmx0/wimax_dl_op_msg + /sys/kernel/debug/wimax:wmx0/wimax_dl_id_table + /sys/kernel/debug/wimax:wmx0/wimax_dl_debugfs + /sys/kernel/debug/wimax:wmx0/.... # other driver specific files + + NOTE: + Of course, if debugfs is mounted in a directory other than + /sys/kernel/debug, those paths will change. + + By reading the file you can obtain the current value of said debug + level; by writing to it, you can set it. + + To increase the debug level of, for example, the id-table submodule, + just write: + + $ echo 3 > /sys/kernel/debug/wimax:wmx0/wimax_dl_id_table + + Increasing numbers yield increasing debug information; for details of + what is printed and the available levels, check the source. The code + uses 0 for disabled and increasing values until 8. diff --git a/Documentation/admin-guide/xfs.rst b/Documentation/admin-guide/xfs.rst index e76665a8f2f2..fb5b39f73059 100644 --- a/Documentation/admin-guide/xfs.rst +++ b/Documentation/admin-guide/xfs.rst @@ -337,11 +337,12 @@ None at present. Removed Sysctls =============== +============================= ======= Name Removed - ---- ------- +============================= ======= fs.xfs.xfsbufd_centisec v4.0 fs.xfs.age_buffer_centisecs v4.0 - +============================= ======= Error handling ============== diff --git a/Documentation/arm/sa1100/adsbitsy.rst b/Documentation/arm/sa1100/adsbitsy.rst deleted file mode 100644 index c179cb26b682..000000000000 --- a/Documentation/arm/sa1100/adsbitsy.rst +++ /dev/null @@ -1,51 +0,0 @@ -=============================== -ADS Bitsy Single Board Computer -=============================== - -(It is different from Bitsy(iPAQ) of Compaq) - -For more details, contact Applied Data Systems or see -http://www.applieddata.net/products.html - -The Linux support for this product has been provided by -Woojung Huh - -Use 'make adsbitsy_config' before any 'make config'. -This will set up defaults for ADS Bitsy support. - -The kernel zImage is linked to be loaded and executed at 0xc0400000. - -Linux can be used with the ADS BootLoader that ships with the -newer rev boards. See their documentation on how to load Linux. - -Supported peripherals -===================== - -- SA1100 LCD frame buffer (8/16bpp...sort of) -- SA1111 USB Master -- SA1100 serial port -- pcmcia, compact flash -- touchscreen(ucb1200) -- console on LCD screen -- serial ports (ttyS[0-2]) - - ttyS0 is default for serial console - -To do -===== - -- everything else! :-) - -Notes -===== - -- The flash on board is divided into 3 partitions. - You should be careful to use flash on board. - Its partition is different from GraphicsClient Plus and GraphicsMaster - -- 16bpp mode requires a different cable than what ships with the board. - Contact ADS or look through the manual to wire your own. Currently, - if you compile with 16bit mode support and switch into a lower bpp - mode, the timing is off so the image is corrupted. This will be - fixed soon. - -Any contribution can be sent to nico@fluxnic.net and will be greatly welcome! diff --git a/Documentation/arm/sa1100/assabet.rst b/Documentation/arm/sa1100/assabet.rst index 3e704831c311..a761e128fb08 100644 --- a/Documentation/arm/sa1100/assabet.rst +++ b/Documentation/arm/sa1100/assabet.rst @@ -14,7 +14,7 @@ Building the kernel To build the kernel with current defaults:: - make assabet_config + make assabet_defconfig make oldconfig make zImage diff --git a/Documentation/arm/sa1100/brutus.rst b/Documentation/arm/sa1100/brutus.rst deleted file mode 100644 index e1a23bee6d44..000000000000 --- a/Documentation/arm/sa1100/brutus.rst +++ /dev/null @@ -1,69 +0,0 @@ -====== -Brutus -====== - -Brutus is an evaluation platform for the SA1100 manufactured by Intel. -For more details, see: - -http://developer.intel.com - -To compile for Brutus, you must issue the following commands:: - - make brutus_config - make config - [accept all the defaults] - make zImage - -The resulting kernel will end up in linux/arch/arm/boot/zImage. This file -must be loaded at 0xc0008000 in Brutus's memory and execution started at -0xc0008000 as well with the value of registers r0 = 0 and r1 = 16 upon -entry. - -But prior to execute the kernel, a ramdisk image must also be loaded in -memory. Use memory address 0xd8000000 for this. Note that the file -containing the (compressed) ramdisk image must not exceed 4 MB. - -Typically, you'll need angelboot to load the kernel. -The following angelboot.opt file should be used:: - - base 0xc0008000 - entry 0xc0008000 - r0 0x00000000 - r1 0x00000010 - device /dev/ttyS0 - options "9600 8N1" - baud 115200 - otherfile ramdisk_img.gz - otherbase 0xd8000000 - -Then load the kernel and ramdisk with:: - - angelboot -f angelboot.opt zImage - -The first Brutus serial port (assumed to be linked to /dev/ttyS0 on your -host PC) is used by angel to load the kernel and ramdisk image. The serial -console is provided through the second Brutus serial port. To access it, -you may use minicom configured with /dev/ttyS1, 9600 baud, 8N1, no flow -control. - -Currently supported -=================== - - - RS232 serial ports - - audio output - - LCD screen - - keyboard - -The actual Brutus support may not be complete without extra patches. -If such patches exist, they should be found from -ftp.netwinder.org/users/n/nico. - -A full PCMCIA support is still missing, although it's possible to hack -some drivers in order to drive already inserted cards at boot time with -little modifications. - -Any contribution is welcome. - -Please send patches to nico@fluxnic.net - -Have Fun ! diff --git a/Documentation/arm/sa1100/freebird.rst b/Documentation/arm/sa1100/freebird.rst deleted file mode 100644 index 81043d0c6d64..000000000000 --- a/Documentation/arm/sa1100/freebird.rst +++ /dev/null @@ -1,25 +0,0 @@ -======== -Freebird -======== - -Freebird-1.1 is produced by Legend(C), Inc. -`http://web.archive.org/web/*/http://www.legend.com.cn` -and software/linux maintained by Coventive(C), Inc. -(http://www.coventive.com) - -Based on the Nicolas's strongarm kernel tree. - -Maintainer: - -Chester Kuo - - - - - -Author: - -- Tim wu -- CIH -- Eric Peng -- Jeff Lee -- Allen Cheng -- Tony Liu diff --git a/Documentation/arm/sa1100/graphicsclient.rst b/Documentation/arm/sa1100/graphicsclient.rst deleted file mode 100644 index a73d61c3ce91..000000000000 --- a/Documentation/arm/sa1100/graphicsclient.rst +++ /dev/null @@ -1,102 +0,0 @@ -============================================= -ADS GraphicsClient Plus Single Board Computer -============================================= - -For more details, contact Applied Data Systems or see -http://www.applieddata.net/products.html - -The original Linux support for this product has been provided by -Nicolas Pitre . Continued development work by -Woojung Huh - -It's currently possible to mount a root filesystem via NFS providing a -complete Linux environment. Otherwise a ramdisk image may be used. The -board supports MTD/JFFS, so you could also mount something on there. - -Use 'make graphicsclient_config' before any 'make config'. This will set up -defaults for GraphicsClient Plus support. - -The kernel zImage is linked to be loaded and executed at 0xc0200000. -Also the following registers should have the specified values upon entry:: - - r0 = 0 - r1 = 29 (this is the GraphicsClient architecture number) - -Linux can be used with the ADS BootLoader that ships with the -newer rev boards. See their documentation on how to load Linux. -Angel is not available for the GraphicsClient Plus AFAIK. - -There is a board known as just the GraphicsClient that ADS used to -produce but has end of lifed. This code will not work on the older -board with the ADS bootloader, but should still work with Angel, -as outlined below. In any case, if you're planning on deploying -something en masse, you should probably get the newer board. - -If using Angel on the older boards, here is a typical angel.opt option file -if the kernel is loaded through the Angel Debug Monitor:: - - base 0xc0200000 - entry 0xc0200000 - r0 0x00000000 - r1 0x0000001d - device /dev/ttyS1 - options "38400 8N1" - baud 115200 - #otherfile ramdisk.gz - #otherbase 0xc0800000 - exec minicom - -Then the kernel (and ramdisk if otherfile/otherbase lines above are -uncommented) would be loaded with:: - - angelboot -f angelboot.opt zImage - -Here it is assumed that the board is connected to ttyS1 on your PC -and that minicom is preconfigured with /dev/ttyS1, 38400 baud, 8N1, no flow -control by default. - -If any other bootloader is used, ensure it accomplish the same, especially -for r0/r1 register values before jumping into the kernel. - - -Supported peripherals -===================== - -- SA1100 LCD frame buffer (8/16bpp...sort of) -- on-board SMC 92C96 ethernet NIC -- SA1100 serial port -- flash memory access (MTD/JFFS) -- pcmcia -- touchscreen(ucb1200) -- ps/2 keyboard -- console on LCD screen -- serial ports (ttyS[0-2]) - - ttyS0 is default for serial console -- Smart I/O (ADC, keypad, digital inputs, etc) - See http://www.eurotech-inc.com/linux-sbc.asp for IOCTL documentation - and example user space code. ps/2 keybd is multiplexed through this driver - -To do -===== - -- UCB1200 audio with new ucb_generic layer -- everything else! :-) - -Notes -===== - -- The flash on board is divided into 3 partitions. mtd0 is where - the ADS boot ROM and zImage is stored. It's been marked as - read-only to keep you from blasting over the bootloader. :) mtd1 is - for the ramdisk.gz image. mtd2 is user flash space and can be - utilized for either JFFS or if you're feeling crazy, running ext2 - on top of it. If you're not using the ADS bootloader, you're - welcome to blast over the mtd1 partition also. - -- 16bpp mode requires a different cable than what ships with the board. - Contact ADS or look through the manual to wire your own. Currently, - if you compile with 16bit mode support and switch into a lower bpp - mode, the timing is off so the image is corrupted. This will be - fixed soon. - -Any contribution can be sent to nico@fluxnic.net and will be greatly welcome! diff --git a/Documentation/arm/sa1100/graphicsmaster.rst b/Documentation/arm/sa1100/graphicsmaster.rst deleted file mode 100644 index e39892514f0c..000000000000 --- a/Documentation/arm/sa1100/graphicsmaster.rst +++ /dev/null @@ -1,60 +0,0 @@ -======================================== -ADS GraphicsMaster Single Board Computer -======================================== - -For more details, contact Applied Data Systems or see -http://www.applieddata.net/products.html - -The original Linux support for this product has been provided by -Nicolas Pitre . Continued development work by -Woojung Huh - -Use 'make graphicsmaster_config' before any 'make config'. -This will set up defaults for GraphicsMaster support. - -The kernel zImage is linked to be loaded and executed at 0xc0400000. - -Linux can be used with the ADS BootLoader that ships with the -newer rev boards. See their documentation on how to load Linux. - -Supported peripherals -===================== - -- SA1100 LCD frame buffer (8/16bpp...sort of) -- SA1111 USB Master -- on-board SMC 92C96 ethernet NIC -- SA1100 serial port -- flash memory access (MTD/JFFS) -- pcmcia, compact flash -- touchscreen(ucb1200) -- ps/2 keyboard -- console on LCD screen -- serial ports (ttyS[0-2]) - - ttyS0 is default for serial console -- Smart I/O (ADC, keypad, digital inputs, etc) - See http://www.eurotech-inc.com/linux-sbc.asp for IOCTL documentation - and example user space code. ps/2 keybd is multiplexed through this driver - -To do -===== - -- everything else! :-) - -Notes -===== - -- The flash on board is divided into 3 partitions. mtd0 is where - the zImage is stored. It's been marked as read-only to keep you - from blasting over the bootloader. :) mtd1 is - for the ramdisk.gz image. mtd2 is user flash space and can be - utilized for either JFFS or if you're feeling crazy, running ext2 - on top of it. If you're not using the ADS bootloader, you're - welcome to blast over the mtd1 partition also. - -- 16bpp mode requires a different cable than what ships with the board. - Contact ADS or look through the manual to wire your own. Currently, - if you compile with 16bit mode support and switch into a lower bpp - mode, the timing is off so the image is corrupted. This will be - fixed soon. - -Any contribution can be sent to nico@fluxnic.net and will be greatly welcome! diff --git a/Documentation/arm/sa1100/huw_webpanel.rst b/Documentation/arm/sa1100/huw_webpanel.rst deleted file mode 100644 index 1dc7ccb165f0..000000000000 --- a/Documentation/arm/sa1100/huw_webpanel.rst +++ /dev/null @@ -1,21 +0,0 @@ -======================= -Hoeft & Wessel Webpanel -======================= - -The HUW_WEBPANEL is a product of the german company Hoeft & Wessel AG - -If you want more information, please visit -http://www.hoeft-wessel.de - -To build the kernel:: - - make huw_webpanel_config - make oldconfig - [accept all defaults] - make zImage - -Mostly of the work is done by: -Roman Jordan jor@hoeft-wessel.de -Christoph Schulz schu@hoeft-wessel.de - -2000/12/18/ diff --git a/Documentation/arm/sa1100/index.rst b/Documentation/arm/sa1100/index.rst index 68c2a280a745..c9aed43280ff 100644 --- a/Documentation/arm/sa1100/index.rst +++ b/Documentation/arm/sa1100/index.rst @@ -7,19 +7,7 @@ Intel StrongARM 1100 .. toctree:: :maxdepth: 1 - adsbitsy assabet - brutus cerf - freebird - graphicsclient - graphicsmaster - huw_webpanel - itsy lart - nanoengine - pangolin - pleb serial_uart - tifon - yopy diff --git a/Documentation/arm/sa1100/itsy.rst b/Documentation/arm/sa1100/itsy.rst deleted file mode 100644 index f49896ba3ef1..000000000000 --- a/Documentation/arm/sa1100/itsy.rst +++ /dev/null @@ -1,47 +0,0 @@ -==== -Itsy -==== - -Itsy is a research project done by the Western Research Lab, and Systems -Research Center in Palo Alto, CA. The Itsy project is one of several -research projects at Compaq that are related to pocket computing. - -For more information, see: - - http://www.hpl.hp.com/downloads/crl/itsy/ - -Notes on initial 2.4 Itsy support (8/27/2000) : - -The port was done on an Itsy version 1.5 machine with a daughtercard with -64 Meg of DRAM and 32 Meg of Flash. The initial work includes support for -serial console (to see what you're doing). No other devices have been -enabled. - -To build, do a "make menuconfig" (or xmenuconfig) and select Itsy support. -Disable Flash and LCD support. and then do a make zImage. -Finally, you will need to cd to arch/arm/boot/tools and execute a make there -to build the params-itsy program used to boot the kernel. - -In order to install the port of 2.4 to the itsy, You will need to set the -configuration parameters in the monitor as follows:: - - Arg 1:0x08340000, Arg2: 0xC0000000, Arg3:18 (0x12), Arg4:0 - -Make sure the start-routine address is set to 0x00060000. - -Next, flash the params-itsy program to 0x00060000 ("p 1 0x00060000" in the -flash menu) Flash the kernel in arch/arm/boot/zImage into 0x08340000 -("p 1 0x00340000"). Finally flash an initial ramdisk into 0xC8000000 -("p 2 0x0") We used ramdisk-2-30.gz from the 0.11 version directory on -handhelds.org. - -The serial connection we established was at: - -8-bit data, no parity, 1 stop bit(s), 115200.00 b/s. in the monitor, in the -params-itsy program, and in the kernel itself. This can be changed, but -not easily. The monitor parameters are easily changed, the params program -setup is assembly outl's, and the kernel is a configuration item specific to -the itsy. (i.e. grep for CONFIG_SA1100_ITSY and you'll find where it is.) - - -This should get you a properly booting 2.4 kernel on the itsy. diff --git a/Documentation/arm/sa1100/nanoengine.rst b/Documentation/arm/sa1100/nanoengine.rst deleted file mode 100644 index 47f1a14cf98a..000000000000 --- a/Documentation/arm/sa1100/nanoengine.rst +++ /dev/null @@ -1,11 +0,0 @@ -========== -nanoEngine -========== - -"nanoEngine" is a SA1110 based single board computer from -Bright Star Engineering Inc. See www.brightstareng.com/arm -for more info. -(Ref: Stuart Adams ) - -Also visit Larry Doolittle's "Linux for the nanoEngine" site: -http://www.brightstareng.com/arm/nanoeng.htm diff --git a/Documentation/arm/sa1100/pangolin.rst b/Documentation/arm/sa1100/pangolin.rst deleted file mode 100644 index f0c5c1618553..000000000000 --- a/Documentation/arm/sa1100/pangolin.rst +++ /dev/null @@ -1,29 +0,0 @@ -======== -Pangolin -======== - -Pangolin is a StrongARM 1110-based evaluation platform produced -by Dialogue Technology (http://www.dialogue.com.tw/). -It has EISA slots for ease of configuration with SDRAM/Flash -memory card, USB/Serial/Audio card, Compact Flash card, -PCMCIA/IDE card and TFT-LCD card. - -To compile for Pangolin, you must issue the following commands:: - - make pangolin_config - make oldconfig - make zImage - -Supported peripherals -===================== - -- SA1110 serial port (UART1/UART2/UART3) -- flash memory access -- compact flash driver -- UDA1341 sound driver -- SA1100 LCD controller for 800x600 16bpp TFT-LCD -- MQ-200 driver for 800x600 16bpp TFT-LCD -- Penmount(touch panel) driver -- PCMCIA driver -- SMC91C94 LAN driver -- IDE driver (experimental) diff --git a/Documentation/arm/sa1100/pleb.rst b/Documentation/arm/sa1100/pleb.rst deleted file mode 100644 index d5b732967aa3..000000000000 --- a/Documentation/arm/sa1100/pleb.rst +++ /dev/null @@ -1,13 +0,0 @@ -==== -PLEB -==== - -The PLEB project was started as a student initiative at the School of -Computer Science and Engineering, University of New South Wales to make a -pocket computer capable of running the Linux Kernel. - -PLEB support has yet to be fully integrated. - -For more information, see: - - http://www.cse.unsw.edu.au diff --git a/Documentation/arm/sa1100/tifon.rst b/Documentation/arm/sa1100/tifon.rst deleted file mode 100644 index c26e910b9ea7..000000000000 --- a/Documentation/arm/sa1100/tifon.rst +++ /dev/null @@ -1,7 +0,0 @@ -===== -Tifon -===== - -More info has to come... - -Contact: Peter Danielsson diff --git a/Documentation/arm/sa1100/yopy.rst b/Documentation/arm/sa1100/yopy.rst deleted file mode 100644 index 5b35a5f61a44..000000000000 --- a/Documentation/arm/sa1100/yopy.rst +++ /dev/null @@ -1,5 +0,0 @@ -==== -Yopy -==== - -See http://www.yopydeveloper.org for more. diff --git a/Documentation/arm/samsung-s3c24xx/index.rst b/Documentation/arm/samsung-s3c24xx/index.rst index 5b8a7f9398d8..ccb951a0bedb 100644 --- a/Documentation/arm/samsung-s3c24xx/index.rst +++ b/Documentation/arm/samsung-s3c24xx/index.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0 -========================== +========================== Samsung S3C24XX SoC Family ========================== diff --git a/Documentation/arm/sh-mobile/.gitignore b/Documentation/arm/sh-mobile/.gitignore deleted file mode 100644 index c928dbf3cc88..000000000000 --- a/Documentation/arm/sh-mobile/.gitignore +++ /dev/null @@ -1 +0,0 @@ -vrl4 diff --git a/Documentation/arm64/index.rst b/Documentation/arm64/index.rst index 96b696ba4e6c..5c0c69dc58aa 100644 --- a/Documentation/arm64/index.rst +++ b/Documentation/arm64/index.rst @@ -16,6 +16,7 @@ ARM64 Architecture pointer-authentication silicon-errata sve + tagged-address-abi tagged-pointers .. only:: subproject and html diff --git a/Documentation/arm64/kasan-offsets.sh b/Documentation/arm64/kasan-offsets.sh new file mode 100644 index 000000000000..2b7a021db363 --- /dev/null +++ b/Documentation/arm64/kasan-offsets.sh @@ -0,0 +1,27 @@ +#!/bin/sh + +# Print out the KASAN_SHADOW_OFFSETS required to place the KASAN SHADOW +# start address at the mid-point of the kernel VA space + +print_kasan_offset () { + printf "%02d\t" $1 + printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) \ + + (1 << ($1 - 32 - $2)) \ + - (1 << (64 - 32 - $2)) )) +} + +echo KASAN_SHADOW_SCALE_SHIFT = 3 +printf "VABITS\tKASAN_SHADOW_OFFSET\n" +print_kasan_offset 48 3 +print_kasan_offset 47 3 +print_kasan_offset 42 3 +print_kasan_offset 39 3 +print_kasan_offset 36 3 +echo +echo KASAN_SHADOW_SCALE_SHIFT = 4 +printf "VABITS\tKASAN_SHADOW_OFFSET\n" +print_kasan_offset 48 4 +print_kasan_offset 47 4 +print_kasan_offset 42 4 +print_kasan_offset 39 4 +print_kasan_offset 36 4 diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst index 464b880fc4b7..b040909e45f8 100644 --- a/Documentation/arm64/memory.rst +++ b/Documentation/arm64/memory.rst @@ -14,6 +14,10 @@ with the 4KB page configuration, allowing 39-bit (512GB) or 48-bit 64KB pages, only 2 levels of translation tables, allowing 42-bit (4TB) virtual address, are used but the memory layout is the same. +ARMv8.2 adds optional support for Large Virtual Address space. This is +only available when running with a 64KB page size and expands the +number of descriptors in the first level of translation. + User addresses have bits 63:48 set to 0 while the kernel addresses have the same bits set to 1. TTBRx selection is given by bit 63 of the virtual address. The swapper_pg_dir contains only kernel (global) @@ -22,40 +26,43 @@ The swapper_pg_dir address is written to TTBR1 and never written to TTBR0. -AArch64 Linux memory layout with 4KB pages + 3 levels:: - - Start End Size Use - ----------------------------------------------------------------------- - 0000000000000000 0000007fffffffff 512GB user - ffffff8000000000 ffffffffffffffff 512GB kernel - - -AArch64 Linux memory layout with 4KB pages + 4 levels:: +AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit):: Start End Size Use ----------------------------------------------------------------------- 0000000000000000 0000ffffffffffff 256TB user - ffff000000000000 ffffffffffffffff 256TB kernel + ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map + ffff800000000000 ffff9fffffffffff 32TB kasan shadow region + ffffa00000000000 ffffa00007ffffff 128MB bpf jit region + ffffa00008000000 ffffa0000fffffff 128MB modules + ffffa00010000000 fffffdffbffeffff ~93TB vmalloc + fffffdffbfff0000 fffffdfffe5f8fff ~998MB [guard region] + fffffdfffe5f9000 fffffdfffe9fffff 4124KB fixed mappings + fffffdfffea00000 fffffdfffebfffff 2MB [guard region] + fffffdfffec00000 fffffdffffbfffff 16MB PCI I/O space + fffffdffffc00000 fffffdffffdfffff 2MB [guard region] + fffffdffffe00000 ffffffffffdfffff 2TB vmemmap + ffffffffffe00000 ffffffffffffffff 2MB [guard region] -AArch64 Linux memory layout with 64KB pages + 2 levels:: +AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support):: Start End Size Use ----------------------------------------------------------------------- - 0000000000000000 000003ffffffffff 4TB user - fffffc0000000000 ffffffffffffffff 4TB kernel - - -AArch64 Linux memory layout with 64KB pages + 3 levels:: - - Start End Size Use - ----------------------------------------------------------------------- - 0000000000000000 0000ffffffffffff 256TB user - ffff000000000000 ffffffffffffffff 256TB kernel - - -For details of the virtual kernel memory layout please see the kernel -booting log. + 0000000000000000 000fffffffffffff 4PB user + fff0000000000000 fff7ffffffffffff 2PB kernel logical memory map + fff8000000000000 fffd9fffffffffff 1440TB [gap] + fffda00000000000 ffff9fffffffffff 512TB kasan shadow region + ffffa00000000000 ffffa00007ffffff 128MB bpf jit region + ffffa00008000000 ffffa0000fffffff 128MB modules + ffffa00010000000 fffff81ffffeffff ~88TB vmalloc + fffff81fffff0000 fffffc1ffe58ffff ~3TB [guard region] + fffffc1ffe590000 fffffc1ffe9fffff 4544KB fixed mappings + fffffc1ffea00000 fffffc1ffebfffff 2MB [guard region] + fffffc1ffec00000 fffffc1fffbfffff 16MB PCI I/O space + fffffc1fffc00000 fffffc1fffdfffff 2MB [guard region] + fffffc1fffe00000 ffffffffffdfffff 3968GB vmemmap + ffffffffffe00000 ffffffffffffffff 2MB [guard region] Translation table lookup with 4KB pages:: @@ -83,7 +90,8 @@ Translation table lookup with 64KB pages:: | | | | [15:0] in-page offset | | | +----------> [28:16] L3 index | | +--------------------------> [41:29] L2 index - | +-------------------------------> [47:42] L1 index + | +-------------------------------> [47:42] L1 index (48-bit) + | [51:42] L1 index (52-bit) +-------------------------------------------------> [63] TTBR0/1 @@ -96,3 +104,62 @@ ARM64_HARDEN_EL2_VECTORS is selected for particular CPUs. When using KVM with the Virtualization Host Extensions, no additional mappings are created, since the host kernel runs directly in EL2. + +52-bit VA support in the kernel +------------------------------- +If the ARMv8.2-LVA optional feature is present, and we are running +with a 64KB page size; then it is possible to use 52-bits of address +space for both userspace and kernel addresses. However, any kernel +binary that supports 52-bit must also be able to fall back to 48-bit +at early boot time if the hardware feature is not present. + +This fallback mechanism necessitates the kernel .text to be in the +higher addresses such that they are invariant to 48/52-bit VAs. Due +to the kasan shadow being a fraction of the entire kernel VA space, +the end of the kasan shadow must also be in the higher half of the +kernel VA space for both 48/52-bit. (Switching from 48-bit to 52-bit, +the end of the kasan shadow is invariant and dependent on ~0UL, +whilst the start address will "grow" towards the lower addresses). + +In order to optimise phys_to_virt and virt_to_phys, the PAGE_OFFSET +is kept constant at 0xFFF0000000000000 (corresponding to 52-bit), +this obviates the need for an extra variable read. The physvirt +offset and vmemmap offsets are computed at early boot to enable +this logic. + +As a single binary will need to support both 48-bit and 52-bit VA +spaces, the VMEMMAP must be sized large enough for 52-bit VAs and +also must be sized large enought to accommodate a fixed PAGE_OFFSET. + +Most code in the kernel should not need to consider the VA_BITS, for +code that does need to know the VA size the variables are +defined as follows: + +VA_BITS constant the *maximum* VA space size + +VA_BITS_MIN constant the *minimum* VA space size + +vabits_actual variable the *actual* VA space size + + +Maximum and minimum sizes can be useful to ensure that buffers are +sized large enough or that addresses are positioned close enough for +the "worst" case. + +52-bit userspace VAs +-------------------- +To maintain compatibility with software that relies on the ARMv8.0 +VA space maximum size of 48-bits, the kernel will, by default, +return virtual addresses to userspace from a 48-bit range. + +Software can "opt-in" to receiving VAs from a 52-bit space by +specifying an mmap hint parameter that is larger than 48-bit. +For example: + maybe_high_address = mmap(~0UL, size, prot, flags,...); + +It is also possible to build a debug kernel that returns addresses +from a 52-bit space by enabling the following kernel config options: + CONFIG_EXPERT=y && CONFIG_ARM64_FORCE_52BIT=y + +Note that this option is only intended for debugging applications +and should not be used in production. diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst index 3e57d09246e6..17ea3fecddaa 100644 --- a/Documentation/arm64/silicon-errata.rst +++ b/Documentation/arm64/silicon-errata.rst @@ -115,6 +115,8 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | Hisilicon | Hip0{6,7} | #161010701 | N/A | +----------------+-----------------+-----------------+-----------------------------+ +| Hisilicon | Hip0{6,7} | #161010803 | N/A | ++----------------+-----------------+-----------------+-----------------------------+ | Hisilicon | Hip07 | #161600802 | HISILICON_ERRATUM_161600802 | +----------------+-----------------+-----------------+-----------------------------+ | Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A | diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst new file mode 100644 index 000000000000..d4a85d535bf9 --- /dev/null +++ b/Documentation/arm64/tagged-address-abi.rst @@ -0,0 +1,156 @@ +========================== +AArch64 TAGGED ADDRESS ABI +========================== + +Authors: Vincenzo Frascino + Catalin Marinas + +Date: 21 August 2019 + +This document describes the usage and semantics of the Tagged Address +ABI on AArch64 Linux. + +1. Introduction +--------------- + +On AArch64 the ``TCR_EL1.TBI0`` bit is set by default, allowing +userspace (EL0) to perform memory accesses through 64-bit pointers with +a non-zero top byte. This document describes the relaxation of the +syscall ABI that allows userspace to pass certain tagged pointers to +kernel syscalls. + +2. AArch64 Tagged Address ABI +----------------------------- + +From the kernel syscall interface perspective and for the purposes of +this document, a "valid tagged pointer" is a pointer with a potentially +non-zero top-byte that references an address in the user process address +space obtained in one of the following ways: + +- ``mmap()`` syscall where either: + + - flags have the ``MAP_ANONYMOUS`` bit set or + - the file descriptor refers to a regular file (including those + returned by ``memfd_create()``) or ``/dev/zero`` + +- ``brk()`` syscall (i.e. the heap area between the initial location of + the program break at process creation and its current location). + +- any memory mapped by the kernel in the address space of the process + during creation and with the same restrictions as for ``mmap()`` above + (e.g. data, bss, stack). + +The AArch64 Tagged Address ABI has two stages of relaxation depending +how the user addresses are used by the kernel: + +1. User addresses not accessed by the kernel but used for address space + management (e.g. ``mmap()``, ``mprotect()``, ``madvise()``). The use + of valid tagged pointers in this context is always allowed. + +2. User addresses accessed by the kernel (e.g. ``write()``). This ABI + relaxation is disabled by default and the application thread needs to + explicitly enable it via ``prctl()`` as follows: + + - ``PR_SET_TAGGED_ADDR_CTRL``: enable or disable the AArch64 Tagged + Address ABI for the calling thread. + + The ``(unsigned int) arg2`` argument is a bit mask describing the + control mode used: + + - ``PR_TAGGED_ADDR_ENABLE``: enable AArch64 Tagged Address ABI. + Default status is disabled. + + Arguments ``arg3``, ``arg4``, and ``arg5`` must be 0. + + - ``PR_GET_TAGGED_ADDR_CTRL``: get the status of the AArch64 Tagged + Address ABI for the calling thread. + + Arguments ``arg2``, ``arg3``, ``arg4``, and ``arg5`` must be 0. + + The ABI properties described above are thread-scoped, inherited on + clone() and fork() and cleared on exec(). + + Calling ``prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0)`` + returns ``-EINVAL`` if the AArch64 Tagged Address ABI is globally + disabled by ``sysctl abi.tagged_addr_disabled=1``. The default + ``sysctl abi.tagged_addr_disabled`` configuration is 0. + +When the AArch64 Tagged Address ABI is enabled for a thread, the +following behaviours are guaranteed: + +- All syscalls except the cases mentioned in section 3 can accept any + valid tagged pointer. + +- The syscall behaviour is undefined for invalid tagged pointers: it may + result in an error code being returned, a (fatal) signal being raised, + or other modes of failure. + +- The syscall behaviour for a valid tagged pointer is the same as for + the corresponding untagged pointer. + + +A definition of the meaning of tagged pointers on AArch64 can be found +in Documentation/arm64/tagged-pointers.rst. + +3. AArch64 Tagged Address ABI Exceptions +----------------------------------------- + +The following system call parameters must be untagged regardless of the +ABI relaxation: + +- ``prctl()`` other than pointers to user data either passed directly or + indirectly as arguments to be accessed by the kernel. + +- ``ioctl()`` other than pointers to user data either passed directly or + indirectly as arguments to be accessed by the kernel. + +- ``shmat()`` and ``shmdt()``. + +Any attempt to use non-zero tagged pointers may result in an error code +being returned, a (fatal) signal being raised, or other modes of +failure. + +4. Example of correct usage +--------------------------- +.. code-block:: c + + #include + #include + #include + #include + #include + + #define PR_SET_TAGGED_ADDR_CTRL 55 + #define PR_TAGGED_ADDR_ENABLE (1UL << 0) + + #define TAG_SHIFT 56 + + int main(void) + { + int tbi_enabled = 0; + unsigned long tag = 0; + char *ptr; + + /* check/enable the tagged address ABI */ + if (!prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0)) + tbi_enabled = 1; + + /* memory allocation */ + ptr = mmap(NULL, sysconf(_SC_PAGE_SIZE), PROT_READ | PROT_WRITE, + MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); + if (ptr == MAP_FAILED) + return 1; + + /* set a non-zero tag if the ABI is available */ + if (tbi_enabled) + tag = rand() & 0xff; + ptr = (char *)((unsigned long)ptr | (tag << TAG_SHIFT)); + + /* memory access to a tagged address */ + strcpy(ptr, "tagged pointer\n"); + + /* syscall with a tagged pointer */ + write(1, ptr, strlen(ptr)); + + return 0; + } diff --git a/Documentation/arm64/tagged-pointers.rst b/Documentation/arm64/tagged-pointers.rst index 2acdec3ebbeb..eab4323609b9 100644 --- a/Documentation/arm64/tagged-pointers.rst +++ b/Documentation/arm64/tagged-pointers.rst @@ -20,7 +20,9 @@ Passing tagged addresses to the kernel -------------------------------------- All interpretation of userspace memory addresses by the kernel assumes -an address tag of 0x00. +an address tag of 0x00, unless the application enables the AArch64 +Tagged Address ABI explicitly +(Documentation/arm64/tagged-address-abi.rst). This includes, but is not limited to, addresses found in: @@ -33,13 +35,15 @@ This includes, but is not limited to, addresses found in: - the frame pointer (x29) and frame records, e.g. when interpreting them to generate a backtrace or call graph. -Using non-zero address tags in any of these locations may result in an -error code being returned, a (fatal) signal being raised, or other modes -of failure. +Using non-zero address tags in any of these locations when the +userspace application did not enable the AArch64 Tagged Address ABI may +result in an error code being returned, a (fatal) signal being raised, +or other modes of failure. -For these reasons, passing non-zero address tags to the kernel via -system calls is forbidden, and using a non-zero address tag for sp is -strongly discouraged. +For these reasons, when the AArch64 Tagged Address ABI is disabled, +passing non-zero address tags to the kernel via system calls is +forbidden, and using a non-zero address tag for sp is strongly +discouraged. Programs maintaining a frame pointer and frame records that use non-zero address tags may suffer impaired or inaccurate debug and profiling @@ -59,6 +63,9 @@ be preserved. The architecture prevents the use of a tagged PC, so the upper byte will be set to a sign-extension of bit 55 on exception return. +This behaviour is maintained when the AArch64 Tagged Address ABI is +enabled. + Other considerations -------------------- diff --git a/Documentation/auxdisplay/cfag12864b b/Documentation/auxdisplay/cfag12864b deleted file mode 100644 index 12fd51b8de75..000000000000 --- a/Documentation/auxdisplay/cfag12864b +++ /dev/null @@ -1,105 +0,0 @@ - =================================== - cfag12864b LCD Driver Documentation - =================================== - -License: GPLv2 -Author & Maintainer: Miguel Ojeda Sandonis -Date: 2006-10-27 - - - --------- -0. INDEX --------- - - 1. DRIVER INFORMATION - 2. DEVICE INFORMATION - 3. WIRING - 4. USERSPACE PROGRAMMING - - ---------------------- -1. DRIVER INFORMATION ---------------------- - -This driver supports a cfag12864b LCD. - - ---------------------- -2. DEVICE INFORMATION ---------------------- - -Manufacturer: Crystalfontz -Device Name: Crystalfontz 12864b LCD Series -Device Code: cfag12864b -Webpage: http://www.crystalfontz.com -Device Webpage: http://www.crystalfontz.com/products/12864b/ -Type: LCD (Liquid Crystal Display) -Width: 128 -Height: 64 -Colors: 2 (B/N) -Controller: ks0108 -Controllers: 2 -Pages: 8 each controller -Addresses: 64 each page -Data size: 1 byte each address -Memory size: 2 * 8 * 64 * 1 = 1024 bytes = 1 Kbyte - - ---------- -3. WIRING ---------- - -The cfag12864b LCD Series don't have official wiring. - -The common wiring is done to the parallel port as shown: - -Parallel Port cfag12864b - - Name Pin# Pin# Name - -Strobe ( 1)------------------------------(17) Enable -Data 0 ( 2)------------------------------( 4) Data 0 -Data 1 ( 3)------------------------------( 5) Data 1 -Data 2 ( 4)------------------------------( 6) Data 2 -Data 3 ( 5)------------------------------( 7) Data 3 -Data 4 ( 6)------------------------------( 8) Data 4 -Data 5 ( 7)------------------------------( 9) Data 5 -Data 6 ( 8)------------------------------(10) Data 6 -Data 7 ( 9)------------------------------(11) Data 7 - (10) [+5v]---( 1) Vdd - (11) [GND]---( 2) Ground - (12) [+5v]---(14) Reset - (13) [GND]---(15) Read / Write - Line (14)------------------------------(13) Controller Select 1 - (15) - Init (16)------------------------------(12) Controller Select 2 -Select (17)------------------------------(16) Data / Instruction -Ground (18)---[GND] [+5v]---(19) LED + -Ground (19)---[GND] -Ground (20)---[GND] E A Values: -Ground (21)---[GND] [GND]---[P1]---(18) Vee - R = Resistor = 22 ohm -Ground (22)---[GND] | - P1 = Preset = 10 Kohm -Ground (23)---[GND] ---- S ------( 3) V0 - P2 = Preset = 1 Kohm -Ground (24)---[GND] | | -Ground (25)---[GND] [GND]---[P2]---[R]---(20) LED - - - ------------------------- -4. USERSPACE PROGRAMMING ------------------------- - -The cfag12864bfb describes a framebuffer device (/dev/fbX). - -It has a size of 1024 bytes = 1 Kbyte. -Each bit represents one pixel. If the bit is high, the pixel will -turn on. If the pixel is low, the pixel will turn off. - -You can use the framebuffer as a file: fopen, fwrite, fclose... -Although the LCD won't get updated until the next refresh time arrives. - -Also, you can mmap the framebuffer: open & mmap, munmap & close... -which is the best option for most uses. - -Check samples/auxdisplay/cfag12864b-example.c -for a real working userspace complete program with usage examples. diff --git a/Documentation/auxdisplay/ks0108 b/Documentation/auxdisplay/ks0108 deleted file mode 100644 index 8ddda0c8ceef..000000000000 --- a/Documentation/auxdisplay/ks0108 +++ /dev/null @@ -1,55 +0,0 @@ - ========================================== - ks0108 LCD Controller Driver Documentation - ========================================== - -License: GPLv2 -Author & Maintainer: Miguel Ojeda Sandonis -Date: 2006-10-27 - - - --------- -0. INDEX --------- - - 1. DRIVER INFORMATION - 2. DEVICE INFORMATION - 3. WIRING - - ---------------------- -1. DRIVER INFORMATION ---------------------- - -This driver supports the ks0108 LCD controller. - - ---------------------- -2. DEVICE INFORMATION ---------------------- - -Manufacturer: Samsung -Device Name: KS0108 LCD Controller -Device Code: ks0108 -Webpage: - -Device Webpage: - -Type: LCD Controller (Liquid Crystal Display Controller) -Width: 64 -Height: 64 -Colors: 2 (B/N) -Pages: 8 -Addresses: 64 each page -Data size: 1 byte each address -Memory size: 8 * 64 * 1 = 512 bytes - - ---------- -3. WIRING ---------- - -The driver supports data parallel port wiring. - -If you aren't building LCD related hardware, you should check -your LCD specific wiring information in the same folder. - -For example, check Documentation/auxdisplay/cfag12864b. diff --git a/Documentation/block/null_blk.rst b/Documentation/block/null_blk.rst index 31451d80783c..edbbab2f12f8 100644 --- a/Documentation/block/null_blk.rst +++ b/Documentation/block/null_blk.rst @@ -1,19 +1,16 @@ +.. SPDX-License-Identifier: GPL-2.0 + ======================== Null block device driver ======================== -1. Overview -=========== +Overview +======== -The null block device (/dev/nullb*) is used for benchmarking the various +The null block device (``/dev/nullb*``) is used for benchmarking the various block-layer implementations. It emulates a block device of X gigabytes in size. -The following instances are possible: - - Single-queue block-layer - - - Request-based. - - Single submission queue per device. - - Implements IO scheduling algorithms (CFQ, Deadline, noop). +It does not execute any read/write operation, just mark them as complete in +the request queue. The following instances are possible: Multi-queue block-layer @@ -27,15 +24,15 @@ The following instances are possible: All of them have a completion queue for each core in the system. -2. Module parameters applicable for all instances -================================================= +Module parameters +================= queue_mode=[0-2]: Default: 2-Multi-queue Selects which block-layer the module should instantiate with. = ============ 0 Bio-based - 1 Single-queue + 1 Single-queue (deprecated) 2 Multi-queue = ============ @@ -67,7 +64,7 @@ irqmode=[0-2]: Default: 1-Soft-irq completion_nsec=[ns]: Default: 10,000ns Combined with irqmode=2 (timer). The time each completion event must wait. -submit_queues=[1..nr_cpus]: +submit_queues=[1..nr_cpus]: Default: 1 The number of submission queues attached to the device driver. If unset, it defaults to 1. For multi-queue, it is ignored when use_per_node_hctx module parameter is 1. @@ -75,9 +72,11 @@ submit_queues=[1..nr_cpus]: hw_queue_depth=[0..qdepth]: Default: 64 The hardware queue depth of the device. -III: Multi-queue specific parameters +Multi-queue specific parameters +------------------------------- use_per_node_hctx=[0/1]: Default: 0 + Number of hardware context queues. = ===================================================================== 0 The number of submit queues are set to the value of the submit_queues @@ -87,6 +86,7 @@ use_per_node_hctx=[0/1]: Default: 0 = ===================================================================== no_sched=[0/1]: Default: 0 + Enable/disable the io scheduler. = ====================================== 0 nullb* use default blk-mq io scheduler @@ -94,6 +94,7 @@ no_sched=[0/1]: Default: 0 = ====================================== blocking=[0/1]: Default: 0 + Blocking behavior of the request queue. = =============================================================== 0 Register as a non-blocking blk-mq driver device. @@ -103,6 +104,7 @@ blocking=[0/1]: Default: 0 = =============================================================== shared_tags=[0/1]: Default: 0 + Sharing tags between devices. = ================================================================ 0 Tag set is not shared. @@ -111,6 +113,7 @@ shared_tags=[0/1]: Default: 0 = ================================================================ zoned=[0/1]: Default: 0 + Device is a random-access or a zoned block device. = ====================================================================== 0 Block device is exposed as a random-access block device. diff --git a/Documentation/block/switching-sched.rst b/Documentation/block/switching-sched.rst index 42042417380e..520f6b857544 100644 --- a/Documentation/block/switching-sched.rst +++ b/Documentation/block/switching-sched.rst @@ -2,10 +2,6 @@ Switching Scheduler =================== -To choose IO schedulers at boot time, use the argument 'elevator=deadline'. -'noop' and 'cfq' (the default) are also available. IO schedulers are assigned -globally at boot time only presently. - Each io queue has a set of io scheduler tunables associated with it. These tunables control how the io scheduler works. You can find these entries in:: diff --git a/Documentation/bpf/prog_flow_dissector.rst b/Documentation/bpf/prog_flow_dissector.rst index ed343abe541e..a78bf036cadd 100644 --- a/Documentation/bpf/prog_flow_dissector.rst +++ b/Documentation/bpf/prog_flow_dissector.rst @@ -26,6 +26,7 @@ The inputs are: * ``nhoff`` - initial offset of the networking header * ``thoff`` - initial offset of the transport header, initialized to nhoff * ``n_proto`` - L3 protocol type, parsed out of L2 header + * ``flags`` - optional flags Flow dissector BPF program should fill out the rest of the ``struct bpf_flow_keys`` fields. Input arguments ``nhoff/thoff/n_proto`` should be @@ -101,6 +102,23 @@ can be called for both cases and would have to be written carefully to handle both cases. +Flags +===== + +``flow_keys->flags`` might contain optional input flags that work as follows: + +* ``BPF_FLOW_DISSECTOR_F_PARSE_1ST_FRAG`` - tells BPF flow dissector to + continue parsing first fragment; the default expected behavior is that + flow dissector returns as soon as it finds out that the packet is fragmented; + used by ``eth_get_headlen`` to estimate length of all headers for GRO. +* ``BPF_FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL`` - tells BPF flow dissector to + stop parsing as soon as it reaches IPv6 flow label; used by + ``___skb_get_hash`` and ``__skb_get_hash_symmetric`` to get flow hash. +* ``BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP`` - tells BPF flow dissector to stop + parsing as soon as it reaches encapsulated headers; used by routing + infrastructure. + + Reference Implementation ======================== diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index da0ed972d224..fa16a0538dcb 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -25,6 +25,7 @@ Core utilities librs genalloc errseq + packing printk-formats circular-buffers generic-radix-tree @@ -48,7 +49,7 @@ Interfaces for kernel debugging debug-objects tracepoint -.. only:: subproject +.. only:: subproject and html Indices ======= diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index 08af5caf036d..f77de49b1d51 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -42,6 +42,9 @@ String Manipulation .. kernel-doc:: lib/string.c :export: +.. kernel-doc:: include/linux/string.h + :internal: + .. kernel-doc:: mm/util.c :functions: kstrdup kstrdup_const kstrndup kmemdup kmemdup_nul memdup_user vmemdup_user strndup_user memdup_user_nul diff --git a/Documentation/core-api/packing.rst b/Documentation/core-api/packing.rst new file mode 100644 index 000000000000..d8c341fe383e --- /dev/null +++ b/Documentation/core-api/packing.rst @@ -0,0 +1,166 @@ +================================================ +Generic bitfield packing and unpacking functions +================================================ + +Problem statement +----------------- + +When working with hardware, one has to choose between several approaches of +interfacing with it. +One can memory-map a pointer to a carefully crafted struct over the hardware +device's memory region, and access its fields as struct members (potentially +declared as bitfields). But writing code this way would make it less portable, +due to potential endianness mismatches between the CPU and the hardware device. +Additionally, one has to pay close attention when translating register +definitions from the hardware documentation into bit field indices for the +structs. Also, some hardware (typically networking equipment) tends to group +its register fields in ways that violate any reasonable word boundaries +(sometimes even 64 bit ones). This creates the inconvenience of having to +define "high" and "low" portions of register fields within the struct. +A more robust alternative to struct field definitions would be to extract the +required fields by shifting the appropriate number of bits. But this would +still not protect from endianness mismatches, except if all memory accesses +were performed byte-by-byte. Also the code can easily get cluttered, and the +high-level idea might get lost among the many bit shifts required. +Many drivers take the bit-shifting approach and then attempt to reduce the +clutter with tailored macros, but more often than not these macros take +shortcuts that still prevent the code from being truly portable. + +The solution +------------ + +This API deals with 2 basic operations: + + - Packing a CPU-usable number into a memory buffer (with hardware + constraints/quirks) + - Unpacking a memory buffer (which has hardware constraints/quirks) + into a CPU-usable number. + +The API offers an abstraction over said hardware constraints and quirks, +over CPU endianness and therefore between possible mismatches between +the two. + +The basic unit of these API functions is the u64. From the CPU's +perspective, bit 63 always means bit offset 7 of byte 7, albeit only +logically. The question is: where do we lay this bit out in memory? + +The following examples cover the memory layout of a packed u64 field. +The byte offsets in the packed buffer are always implicitly 0, 1, ... 7. +What the examples show is where the logical bytes and bits sit. + +1. Normally (no quirks), we would do it like this: + +:: + + 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 + 7 6 5 4 + 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 + 3 2 1 0 + +That is, the MSByte (7) of the CPU-usable u64 sits at memory offset 0, and the +LSByte (0) of the u64 sits at memory offset 7. +This corresponds to what most folks would regard to as "big endian", where +bit i corresponds to the number 2^i. This is also referred to in the code +comments as "logical" notation. + + +2. If QUIRK_MSB_ON_THE_RIGHT is set, we do it like this: + +:: + + 56 57 58 59 60 61 62 63 48 49 50 51 52 53 54 55 40 41 42 43 44 45 46 47 32 33 34 35 36 37 38 39 + 7 6 5 4 + 24 25 26 27 28 29 30 31 16 17 18 19 20 21 22 23 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7 + 3 2 1 0 + +That is, QUIRK_MSB_ON_THE_RIGHT does not affect byte positioning, but +inverts bit offsets inside a byte. + + +3. If QUIRK_LITTLE_ENDIAN is set, we do it like this: + +:: + + 39 38 37 36 35 34 33 32 47 46 45 44 43 42 41 40 55 54 53 52 51 50 49 48 63 62 61 60 59 58 57 56 + 4 5 6 7 + 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24 + 0 1 2 3 + +Therefore, QUIRK_LITTLE_ENDIAN means that inside the memory region, every +byte from each 4-byte word is placed at its mirrored position compared to +the boundary of that word. + +4. If QUIRK_MSB_ON_THE_RIGHT and QUIRK_LITTLE_ENDIAN are both set, we do it + like this: + +:: + + 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 + 4 5 6 7 + 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 + 0 1 2 3 + + +5. If just QUIRK_LSW32_IS_FIRST is set, we do it like this: + +:: + + 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 + 3 2 1 0 + 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 + 7 6 5 4 + +In this case the 8 byte memory region is interpreted as follows: first +4 bytes correspond to the least significant 4-byte word, next 4 bytes to +the more significant 4-byte word. + + +6. If QUIRK_LSW32_IS_FIRST and QUIRK_MSB_ON_THE_RIGHT are set, we do it like + this: + +:: + + 24 25 26 27 28 29 30 31 16 17 18 19 20 21 22 23 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7 + 3 2 1 0 + 56 57 58 59 60 61 62 63 48 49 50 51 52 53 54 55 40 41 42 43 44 45 46 47 32 33 34 35 36 37 38 39 + 7 6 5 4 + + +7. If QUIRK_LSW32_IS_FIRST and QUIRK_LITTLE_ENDIAN are set, it looks like + this: + +:: + + 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24 + 0 1 2 3 + 39 38 37 36 35 34 33 32 47 46 45 44 43 42 41 40 55 54 53 52 51 50 49 48 63 62 61 60 59 58 57 56 + 4 5 6 7 + + +8. If QUIRK_LSW32_IS_FIRST, QUIRK_LITTLE_ENDIAN and QUIRK_MSB_ON_THE_RIGHT + are set, it looks like this: + +:: + + 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 + 0 1 2 3 + 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 + 4 5 6 7 + + +We always think of our offsets as if there were no quirk, and we translate +them afterwards, before accessing the memory region. + +Intended use +------------ + +Drivers that opt to use this API first need to identify which of the above 3 +quirk combinations (for a total of 8) match what the hardware documentation +describes. Then they should wrap the packing() function, creating a new +xxx_packing() that calls it using the proper QUIRK_* one-hot bits set. + +The packing() function returns an int-encoded error code, which protects the +programmer against incorrect API use. The errors are not expected to occur +durring runtime, therefore it is reasonable for xxx_packing() to return void +and simply swallow those errors. Optionally it can dump stack or print the +error description. diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index c6224d039bcb..ecbebf4ca8e7 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -13,10 +13,10 @@ Integer types If variable is of Type, use printk format specifier: ------------------------------------------------------------ - char %hhd or %hhx - unsigned char %hhu or %hhx - short int %hd or %hx - unsigned short int %hu or %hx + char %d or %x + unsigned char %u or %x + short int %d or %x + unsigned short int %u or %x int %d or %x unsigned int %u or %x long %ld or %lx @@ -25,10 +25,10 @@ Integer types unsigned long long %llu or %llx size_t %zu or %zx ssize_t %zd or %zx - s8 %hhd or %hhx - u8 %hhu or %hhx - s16 %hd or %hx - u16 %hu or %hx + s8 %d or %x + u8 %u or %x + s16 %d or %x + u16 %u or %x s32 %d or %x u32 %u or %x s64 %lld or %llx diff --git a/Documentation/cpu-freq/core.txt b/Documentation/cpu-freq/core.txt index 55193e680250..ed577d9c154b 100644 --- a/Documentation/cpu-freq/core.txt +++ b/Documentation/cpu-freq/core.txt @@ -57,19 +57,11 @@ transition notifiers. 2.1 CPUFreq policy notifiers ---------------------------- -These are notified when a new policy is intended to be set. Each -CPUFreq policy notifier is called twice for a policy transition: +These are notified when a new policy is created or removed. -1.) During CPUFREQ_ADJUST all CPUFreq notifiers may change the limit if - they see a need for this - may it be thermal considerations or - hardware limitations. - -2.) And during CPUFREQ_NOTIFY all notifiers are informed of the new policy - - if two hardware drivers failed to agree on a new policy before this - stage, the incompatible hardware shall be shut down, and the user - informed of this. - -The phase is specified in the second argument to the notifier. +The phase is specified in the second argument to the notifier. The phase is +CPUFREQ_CREATE_POLICY when the policy is first created and it is +CPUFREQ_REMOVE_POLICY when the policy is removed. The third argument, a void *pointer, points to a struct cpufreq_policy consisting of several values, including min, max (the lower and upper diff --git a/Documentation/crypto/crypto_engine.rst b/Documentation/crypto/crypto_engine.rst index 236c674d6897..3baa23c2cd08 100644 --- a/Documentation/crypto/crypto_engine.rst +++ b/Documentation/crypto/crypto_engine.rst @@ -1,4 +1,5 @@ .. SPDX-License-Identifier: GPL-2.0 + Crypto Engine ============= diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile index 6b0dfd5c17ba..5138a2f6232a 100644 --- a/Documentation/devicetree/bindings/Makefile +++ b/Documentation/devicetree/bindings/Makefile @@ -19,7 +19,9 @@ quiet_cmd_mk_schema = SCHEMA $@ DT_DOCS = $(shell \ cd $(srctree)/$(src) && \ - find * \( -name '*.yaml' ! -name $(DT_TMP_SCHEMA) \) \ + find * \( -name '*.yaml' ! \ + -name $(DT_TMP_SCHEMA) ! \ + -name '*.example.dt.yaml' \) \ ) DT_SCHEMA_FILES ?= $(addprefix $(src)/,$(DT_DOCS)) diff --git a/Documentation/devicetree/bindings/arm/actions.txt b/Documentation/devicetree/bindings/arm/actions.txt deleted file mode 100644 index d54f33c4e0da..000000000000 --- a/Documentation/devicetree/bindings/arm/actions.txt +++ /dev/null @@ -1,56 +0,0 @@ -Actions Semi platforms device tree bindings -------------------------------------------- - - -S500 SoC -======== - -Required root node properties: - - - compatible : must contain "actions,s500" - - -Modules: - -Root node property compatible must contain, depending on module: - - - LeMaker Guitar: "lemaker,guitar" - - -Boards: - -Root node property compatible must contain, depending on board: - - - Allo.com Sparky: "allo,sparky" - - Cubietech CubieBoard6: "cubietech,cubieboard6" - - LeMaker Guitar Base Board rev. B: "lemaker,guitar-bb-rev-b", "lemaker,guitar" - - -S700 SoC -======== - -Required root node properties: - -- compatible : must contain "actions,s700" - - -Boards: - -Root node property compatible must contain, depending on board: - - - Cubietech CubieBoard7: "cubietech,cubieboard7" - - -S900 SoC -======== - -Required root node properties: - -- compatible : must contain "actions,s900" - - -Boards: - -Root node property compatible must contain, depending on board: - - - uCRobotics Bubblegum-96: "ucrobotics,bubblegum-96" diff --git a/Documentation/devicetree/bindings/arm/actions.yaml b/Documentation/devicetree/bindings/arm/actions.yaml new file mode 100644 index 000000000000..ace3fdaa8396 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/actions.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/actions.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Actions Semi platforms device tree bindings + +maintainers: + - Andreas Färber + - Manivannan Sadhasivam + +properties: + compatible: + oneOf: + # The Actions Semi S500 is a quad-core ARM Cortex-A9 SoC. + - items: + - enum: + - allo,sparky # Allo.com Sparky + - cubietech,cubieboard6 # Cubietech CubieBoard6 + - const: actions,s500 + - items: + - enum: + - lemaker,guitar-bb-rev-b # LeMaker Guitar Base Board rev. B + - const: lemaker,guitar + - const: actions,s500 + + # The Actions Semi S700 is a quad-core ARM Cortex-A53 SoC. + - items: + - enum: + - cubietech,cubieboard7 # Cubietech CubieBoard7 + - const: actions,s700 + + # The Actions Semi S900 is a quad-core ARM Cortex-A53 SoC. + - items: + - enum: + - ucrobotics,bubblegum-96 # uCRobotics Bubblegum-96 + - const: actions,s900 diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 325c6fd3566d..99015cef8bb1 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -91,13 +91,11 @@ properties: - description: Boards with the Amlogic Meson GXL S905X SoC items: - enum: - - amediatech,x96-max - amlogic,p212 - hwacom,amazetv - khadas,vim - libretech,cc - nexbox,a95x - - seirobotics,sei510 - const: amlogic,s905x - const: amlogic,meson-gxl @@ -129,16 +127,33 @@ properties: - const: amlogic,a113d - const: amlogic,meson-axg - - description: Boards with the Amlogic Meson G12A S905D2 SoC + - description: Boards with the Amlogic Meson G12A S905D2/X2/Y2 SoC items: - enum: + - amediatech,x96-max - amlogic,u200 + - seirobotics,sei510 - const: amlogic,g12a + - description: Boards with the Amlogic Meson G12B A311D SoC + items: + - enum: + - khadas,vim3 + - const: amlogic,a311d + - const: amlogic,g12b + - description: Boards with the Amlogic Meson G12B S922X SoC items: - enum: - hardkernel,odroid-n2 + - khadas,vim3 + - const: amlogic,s922x - const: amlogic,g12b + - description: Boards with the Amlogic Meson SM1 S905X3/D3/Y3 SoC + items: + - enum: + - seirobotics,sei610 + - khadas,vim3l + - const: amlogic,sm1 ... diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt deleted file mode 100644 index c67d9f48fb91..000000000000 --- a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt +++ /dev/null @@ -1,28 +0,0 @@ -Amlogic Meson Firmware registers Interface ------------------------------------------- - -The Meson SoCs have a register bank with status and data shared with the -secure firmware. - -Required properties: - - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-ao-secure", "syscon" - -Properties should indentify components of this register interface : - -Meson GX SoC Information ------------------------- -A firmware register encodes the SoC type, package and revision information on -the Meson GX SoCs. -If present, the following property should be added : - -Optional properties: - - amlogic,has-chip-id: If present, the interface gives the current SoC version. - -Example -------- - -ao-secure@140 { - compatible = "amlogic,meson-gx-ao-secure", "syscon"; - reg = <0x0 0x140 0x0 0x140>; - amlogic,has-chip-id; -}; diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml new file mode 100644 index 000000000000..853d7d2b56f5 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 BayLibre, SAS +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/amlogic/amlogic,meson-gx-ao-secure.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic Meson Firmware registers Interface + +maintainers: + - Neil Armstrong + +description: | + The Meson SoCs have a register bank with status and data shared with the + secure firmware. + +# We need a select here so we don't match all nodes with 'syscon' +select: + properties: + compatible: + contains: + const: amlogic,meson-gx-ao-secure + required: + - compatible + +properties: + compatible: + items: + - const: amlogic,meson-gx-ao-secure + - const: syscon + + reg: + maxItems: 1 + + amlogic,has-chip-id: + description: | + A firmware register encodes the SoC type, package and revision + information on the Meson GX SoCs. If present, the interface gives + the current SoC version. + type: boolean + +required: + - compatible + - reg + +examples: + - | + ao-secure@140 { + compatible = "amlogic,meson-gx-ao-secure", "syscon"; + reg = <0x140 0x140>; + amlogic,has-chip-id; + }; diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt index 317a2fc3667a..083dbf96ee00 100644 --- a/Documentation/devicetree/bindings/arm/arm,scmi.txt +++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt @@ -73,6 +73,16 @@ Required properties: as used by the firmware. Refer to platform details for your implementation for the IDs to use. +Reset signal bindings for the reset domains based on SCMI Message Protocol +------------------------------------------------------------ + +This binding for the SCMI reset domain providers uses the generic reset +signal binding[5]. + +Required properties: + - #reset-cells : Should be 1. Contains the reset domain ID value used + by SCMI commands. + SRAM and Shared Memory for SCMI ------------------------------- @@ -93,6 +103,7 @@ Required sub-node properties: [2] Documentation/devicetree/bindings/power/power_domain.txt [3] Documentation/devicetree/bindings/thermal/thermal.txt [4] Documentation/devicetree/bindings/sram/sram.txt +[5] Documentation/devicetree/bindings/reset/reset.txt Example: @@ -152,6 +163,11 @@ firmware { reg = <0x15>; #thermal-sensor-cells = <1>; }; + + scmi_reset: protocol@16 { + reg = <0x16>; + #reset-cells = <1>; + }; }; }; @@ -166,6 +182,7 @@ hdlcd@7ff60000 { reg = <0 0x7ff60000 0 0x1000>; clocks = <&scmi_clk 4>; power-domains = <&scmi_devpd 1>; + resets = <&scmi_reset 10>; }; thermal-zones { diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards index 6758ece324b1..b2a9f9f8430b 100644 --- a/Documentation/devicetree/bindings/arm/arm-boards +++ b/Documentation/devicetree/bindings/arm/arm-boards @@ -199,7 +199,7 @@ The description for the board must include: A detailed description of the bindings used for "psci" nodes is present in the psci.yaml file. - a "cpus" node describing the available cores and their associated - "enable-method"s. For more details see cpus.txt file. + "enable-method"s. For more details see cpus.yaml file. Example: diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index aa40b074b864..cb30895e3b67 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -124,6 +124,7 @@ properties: - arm,cortex-a15 - arm,cortex-a17 - arm,cortex-a53 + - arm,cortex-a55 - arm,cortex-a57 - arm,cortex-a72 - arm,cortex-a73 @@ -155,6 +156,7 @@ properties: - qcom,krait - qcom,kryo - qcom,kryo385 + - qcom,kryo485 - qcom,scorpion enable-method: @@ -175,6 +177,7 @@ properties: - amlogic,meson8-smp - amlogic,meson8b-smp - arm,realview-smp + - aspeed,ast2600-smp - brcm,bcm11351-cpu-method - brcm,bcm23550 - brcm,bcm2836-smp diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt index a575e42f7fec..c149fadc6f47 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt @@ -136,7 +136,9 @@ Required properties: OCOTP bindings based on SCU Message Protocol ------------------------------------------------------------ Required properties: -- compatible: Should be "fsl,imx8qxp-scu-ocotp" +- compatible: Should be one of: + "fsl,imx8qm-scu-ocotp", + "fsl,imx8qxp-scu-ocotp". - #address-cells: Must be 1. Contains byte index - #size-cells: Must be 1. Contains byte length diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 7294ac36f4c0..1b4b4e6573b5 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -161,6 +161,20 @@ properties: items: - enum: - fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board + - kontron,imx6ul-n6310-som # Kontron N6310 SOM + - const: fsl,imx6ul + + - description: Kontron N6310 S Board + items: + - const: kontron,imx6ul-n6310-s + - const: kontron,imx6ul-n6310-som + - const: fsl,imx6ul + + - description: Kontron N6310 S 43 Board + items: + - const: kontron,imx6ul-n6310-s-43 + - const: kontron,imx6ul-n6310-s + - const: kontron,imx6ul-n6310-som - const: fsl,imx6ul - description: i.MX6ULL based Boards @@ -188,6 +202,7 @@ properties: - fsl,imx7d-sdb # i.MX7 SabreSD Board - novtech,imx7d-meerkat96 # i.MX7 Meerkat96 Board - tq,imx7d-mba7 # i.MX7D TQ MBa7 with TQMa7D SoM + - zii,imx7d-rmu2 # ZII RMU2 Board - zii,imx7d-rpu2 # ZII RPU2 Board - const: fsl,imx7d @@ -214,16 +229,26 @@ properties: - fsl,imx8mm-evk # i.MX8MM EVK Board - const: fsl,imx8mm + - description: i.MX8MN based Boards + items: + - enum: + - fsl,imx8mn-ddr4-evk # i.MX8MN DDR4 EVK Board + - const: fsl,imx8mn + - description: i.MX8MQ based Boards items: - enum: + - boundary,imx8mq-nitrogen8m # i.MX8MQ NITROGEN Board - fsl,imx8mq-evk # i.MX8MQ EVK Board - purism,librem5-devkit # Purism Librem5 devkit + - solidrun,hummingboard-pulse # SolidRun Hummingboard Pulse + - technexion,pico-pi-imx8m # TechNexion PICO-PI-8M evk - const: fsl,imx8mq - description: i.MX8QXP based Boards items: - enum: + - einfochips,imx8qxp-ai_ml # i.MX8QXP AI_ML Board - fsl,imx8qxp-mek # i.MX8QXP MEK Board - const: fsl,imx8qxp @@ -283,6 +308,7 @@ properties: - description: LS1046A based Boards items: - enum: + - fsl,ls1046a-frwy - fsl,ls1046a-qds - fsl,ls1046a-rdb - const: fsl,ls1046a diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt b/Documentation/devicetree/bindings/arm/idle-states.txt index 2d325bed37e5..771f5d20ae18 100644 --- a/Documentation/devicetree/bindings/arm/idle-states.txt +++ b/Documentation/devicetree/bindings/arm/idle-states.txt @@ -28,7 +28,7 @@ PM implementation to put the processor in different idle states (which include states listed above; "off" state is not an idle state since it does not have wake-up capabilities, hence it is not considered in this document). -Idle state parameters (eg entry latency) are platform specific and need to be +Idle state parameters (e.g. entry latency) are platform specific and need to be characterized with bindings that provide the required information to OS PM code so that it can build the required tables and use them at runtime. @@ -90,24 +90,24 @@ These timing parameters can be used by an OS in different circumstances. An idle CPU requires the expected min-residency time to select the most appropriate idle state based on the expected expiry time of the next IRQ -(ie wake-up) that causes the CPU to return to the EXEC phase. +(i.e. wake-up) that causes the CPU to return to the EXEC phase. An operating system scheduler may need to compute the shortest wake-up delay for CPUs in the system by detecting how long will it take to get a CPU out -of an idle state, eg: +of an idle state, e.g.: wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0) In other words, the scheduler can make its scheduling decision by selecting -(eg waking-up) the CPU with the shortest wake-up latency. -The wake-up latency must take into account the entry latency if that period +(e.g. waking-up) the CPU with the shortest wake-up delay. +The wake-up delay must take into account the entry latency if that period has not expired. The abortable nature of the PREP period can be ignored if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than -the worst case since it depends on the CPU operating conditions, ie caches +the worst case since it depends on the CPU operating conditions, i.e. caches state). An OS has to reliably probe the wakeup-latency since some devices can enforce -latency constraints guarantees to work properly, so the OS has to detect the +latency constraint guarantees to work properly, so the OS has to detect the worst case wake-up latency it can incur if a CPU is allowed to enter an idle state, and possibly to prevent that to guarantee reliable device functioning. @@ -183,15 +183,15 @@ and IDLE2: Graph 2: idle states min-residency example In graph 2 above, that takes into account idle states entry/exit energy -costs, it is clear that if the idle state residency time (ie time till next +costs, it is clear that if the idle state residency time (i.e. time till next wake-up IRQ) is less than IDLE2-min-residency, IDLE1 is the better idle state choice energywise. This is mainly down to the fact that IDLE1 entry/exit energy costs are lower than IDLE2. -However, the lower power consumption (ie shallower energy curve slope) of idle -state IDLE2 implies that after a suitable time, IDLE2 becomes more energy +However, the lower power consumption (i.e. shallower energy curve slope) of +idle state IDLE2 implies that after a suitable time, IDLE2 becomes more energy efficient. The time at which IDLE2 becomes more energy efficient than IDLE1 (and other @@ -214,8 +214,8 @@ processor idle states, defined as device tree nodes, are listed. Usage: Optional - On ARM systems, it is a container of processor idle states nodes. If the system does not provide CPU - power management capabilities or the processor just - supports idle_standby an idle-states node is not + power management capabilities, or the processor just + supports idle_standby, an idle-states node is not required. Description: idle-states node is a container node, where its @@ -287,14 +287,14 @@ follows: Value type: Definition: u32 value representing worst case latency in microseconds required to enter the idle state. - The exit-latency-us duration may be guaranteed - only after entry-latency-us has passed. - exit-latency-us Usage: Required Value type: Definition: u32 value representing worst case latency in microseconds required to exit the idle state. + The exit-latency-us duration may be guaranteed + only after entry-latency-us has passed. - min-residency-us Usage: Required @@ -342,8 +342,8 @@ follows: state. In addition to the properties listed above, a state node may require - additional properties specifics to the entry-method defined in the - idle-states node, please refer to the entry-method bindings + additional properties specific to the entry-method defined in the + idle-states node. Please refer to the entry-method bindings documentation for properties definitions. =========================================== diff --git a/Documentation/devicetree/bindings/arm/l2c2x0.yaml b/Documentation/devicetree/bindings/arm/l2c2x0.yaml index bfc5c185561c..913a8cd8b2c0 100644 --- a/Documentation/devicetree/bindings/arm/l2c2x0.yaml +++ b/Documentation/devicetree/bindings/arm/l2c2x0.yaml @@ -176,6 +176,10 @@ properties: description: disable parity checking on the L2 cache (L220 or PL310). type: boolean + marvell,ecc-enable: + description: enable ECC protection on the L2 cache + type: boolean + arm,outer-sync-disable: description: disable the outer sync operation on the L2 cache. Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that diff --git a/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt index 7b8b8eb0191f..26410fbb85be 100644 --- a/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt +++ b/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt @@ -18,17 +18,19 @@ Clocks: ------- -The Device Tree node representing the AP806 system controller provides -a number of clocks: +The Device Tree node representing the AP806/AP807 system controller +provides a number of clocks: - - 0: clock of CPU cluster 0 - - 1: clock of CPU cluster 1 + - 0: reference clock of CPU cluster 0 + - 1: reference clock of CPU cluster 1 - 2: fixed PLL at 1200 Mhz - 3: MSS clock, derived from the fixed PLL Required properties: - - compatible: must be: "marvell,ap806-clock" + - compatible: must be one of: + * "marvell,ap806-clock" + * "marvell,ap807-clock" - #clock-cells: must be set to 1 Pinctrl: @@ -143,3 +145,33 @@ ap_syscon1: system-controller@6f8000 { #thermal-sensor-cells = <1>; }; }; + +Cluster clocks: +--------------- + +Device Tree Clock bindings for cluster clock of Marvell +AP806/AP807. Each cluster contain up to 2 CPUs running at the same +frequency. + +Required properties: + - compatible: must be one of: + * "marvell,ap806-cpu-clock" + * "marvell,ap807-cpu-clock" +- #clock-cells : should be set to 1. + +- clocks : shall be the input parent clock(s) phandle for the clock + (one per cluster) + +- reg: register range associated with the cluster clocks + +ap_syscon1: system-controller@6f8000 { + compatible = "marvell,armada-ap806-syscon1", "syscon", "simple-mfd"; + reg = <0x6f8000 0x1000>; + + cpu_clk: clock-cpu@278 { + compatible = "marvell,ap806-cpu-clock"; + clocks = <&ap_clk 0>, <&ap_clk 1>; + #clock-cells = <1>; + reg = <0x278 0xa30>; + }; +}; diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt index eddde4faef01..f6d6642d81c0 100644 --- a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt +++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt @@ -48,3 +48,11 @@ avs: avs@11500 { compatible = "marvell,armada-3700-avs", "syscon"; reg = <0x11500 0x40>; } + + +CZ.NIC's Turris Mox SOHO router Device Tree Bindings +---------------------------------------------------- + +Required root node property: + + - compatible: must contain "cznic,turris-mox" diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt index 4db4119a6d19..f982a8ed9396 100644 --- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt +++ b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt @@ -78,8 +78,8 @@ Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt. Required properties: -- compatible: "marvell,armada-7k-pinctrl", - "marvell,armada-8k-cpm-pinctrl" or "marvell,armada-8k-cps-pinctrl" +- compatible: "marvell,armada-7k-pinctrl", "marvell,armada-8k-cpm-pinctrl", + "marvell,armada-8k-cps-pinctrl" or "marvell,cp115-standalone-pinctrl" depending on the specific variant of the SoC being used. Available mpp pins/groups and functions: diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index a4ad2eb926f9..4043c5046441 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -46,6 +46,10 @@ properties: - enum: - mediatek,mt6765-evb - const: mediatek,mt6765 + - items: + - enum: + - mediatek,mt6779-evb + - const: mediatek,mt6779 - items: - enum: - mediatek,mt6795-evb diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt index 161e63a6c254..ff000ccade78 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt @@ -8,6 +8,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt2701-apmixedsys" - "mediatek,mt2712-apmixedsys", "syscon" + - "mediatek,mt6779-apmixedsys", "syscon" - "mediatek,mt6797-apmixedsys" - "mediatek,mt7622-apmixedsys" - "mediatek,mt7623-apmixedsys", "mediatek,mt2701-apmixedsys" diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt index 07c9d813465c..e4ca7b703123 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt @@ -7,6 +7,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt2701-audsys", "syscon" + - "mediatek,mt6779-audio", "syscon" - "mediatek,mt7622-audsys", "syscon" - "mediatek,mt7623-audsys", "mediatek,mt2701-audsys", "syscon" - "mediatek,mt8183-audiosys", "syscon" diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt index d8930f64aa98..1f4aaa15a37e 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt @@ -6,6 +6,7 @@ The MediaTek camsys controller provides various clocks to the system. Required Properties: - compatible: Should be one of: + - "mediatek,mt6779-camsys", "syscon" - "mediatek,mt8183-camsys", "syscon" - #clock-cells: Must be 1 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt index e3bc4a1e7a6e..2b693e343c56 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt @@ -8,6 +8,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt2701-imgsys", "syscon" - "mediatek,mt2712-imgsys", "syscon" + - "mediatek,mt6779-imgsys", "syscon" - "mediatek,mt6797-imgsys", "syscon" - "mediatek,mt7623-imgsys", "mediatek,mt2701-imgsys", "syscon" - "mediatek,mt8173-imgsys", "syscon" diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt index a90913988d7e..db2f4fd754e7 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt @@ -9,6 +9,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt2701-infracfg", "syscon" - "mediatek,mt2712-infracfg", "syscon" + - "mediatek,mt6779-infracfg_ao", "syscon" - "mediatek,mt6797-infracfg", "syscon" - "mediatek,mt7622-infracfg", "syscon" - "mediatek,mt7623-infracfg", "mediatek,mt2701-infracfg", "syscon" diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ipesys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ipesys.txt new file mode 100644 index 000000000000..2ce889b023d9 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ipesys.txt @@ -0,0 +1,22 @@ +Mediatek ipesys controller +============================ + +The Mediatek ipesys controller provides various clocks to the system. + +Required Properties: + +- compatible: Should be one of: + - "mediatek,mt6779-ipesys", "syscon" +- #clock-cells: Must be 1 + +The ipesys controller uses the common clk binding from +Documentation/devicetree/bindings/clock/clock-bindings.txt +The available clocks are defined in dt-bindings/clock/mt*-clk.h. + +Example: + +ipesys: clock-controller@1b000000 { + compatible = "mediatek,mt6779-ipesys", "syscon"; + reg = <0 0x1b000000 0 0x1000>; + #clock-cells = <1>; +}; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt index 72787e7dd227..ad5f9d2f6818 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt @@ -7,6 +7,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt2712-mfgcfg", "syscon" + - "mediatek,mt6779-mfgcfg", "syscon" - "mediatek,mt8183-mfgcfg", "syscon" - #clock-cells: Must be 1 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt index 545eab717c96..301eefbe1618 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt @@ -8,6 +8,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt2701-mmsys", "syscon" - "mediatek,mt2712-mmsys", "syscon" + - "mediatek,mt6779-mmsys", "syscon" - "mediatek,mt6797-mmsys", "syscon" - "mediatek,mt7623-mmsys", "mediatek,mt2701-mmsys", "syscon" - "mediatek,mt8173-mmsys", "syscon" diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt index 4c7e478117a0..ecf027a9003a 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt @@ -14,6 +14,7 @@ Required Properties: - "mediatek,mt7629-pericfg", "syscon" - "mediatek,mt8135-pericfg", "syscon" - "mediatek,mt8173-pericfg", "syscon" + - "mediatek,mt8183-pericfg", "syscon" - #clock-cells: Must be 1 - #reset-cells: Must be 1 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt index f5518f26a914..30cb645c0e54 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt @@ -9,8 +9,6 @@ Required Properties: - "mediatek,mt7622-sgmiisys", "syscon" - "mediatek,mt7629-sgmiisys", "syscon" - #clock-cells: Must be 1 -- mediatek,physpeed: Should be one of "auto", "1000" or "2500" to match up - the capability of the target PHY. The SGMIISYS controller uses the common clk binding from Documentation/devicetree/bindings/clock/clock-bindings.txt diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt index a023b8338960..0293d693ce0c 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt @@ -8,6 +8,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt2701-topckgen" - "mediatek,mt2712-topckgen", "syscon" + - "mediatek,mt6779-topckgen", "syscon" - "mediatek,mt6797-topckgen" - "mediatek,mt7622-topckgen" - "mediatek,mt7623-topckgen", "mediatek,mt2701-topckgen" diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt index 57176bb8dbb5..7894558b7a1c 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt @@ -8,6 +8,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt2701-vdecsys", "syscon" - "mediatek,mt2712-vdecsys", "syscon" + - "mediatek,mt6779-vdecsys", "syscon" - "mediatek,mt6797-vdecsys", "syscon" - "mediatek,mt7623-vdecsys", "mediatek,mt2701-vdecsys", "syscon" - "mediatek,mt8173-vdecsys", "syscon" diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt index c9faa6269087..6a6a14e15cd7 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt @@ -7,6 +7,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt2712-vencsys", "syscon" + - "mediatek,mt6779-vencsys", "syscon" - "mediatek,mt6797-vencsys", "syscon" - "mediatek,mt8173-vencsys", "syscon" - "mediatek,mt8183-vencsys", "syscon" diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 54ef6b6b9189..e39d8f02e33c 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -45,6 +45,7 @@ description: | mtp sbc hk01 + qrd The 'soc_version' and 'board_version' elements take the form of v. where the minor number may be omitted when it's zero, i.e. v1.0 is the same @@ -115,6 +116,13 @@ properties: - const: qcom,msm8916-mtp - const: qcom,msm8916 + - items: + - enum: + - longcheer,l8150 + - samsung,a3u-eur + - samsung,a5u-eur + - const: qcom,msm8916 + - items: - const: qcom,msm8996-mtp diff --git a/Documentation/devicetree/bindings/arm/realtek.txt b/Documentation/devicetree/bindings/arm/realtek.txt deleted file mode 100644 index 95839e19ae92..000000000000 --- a/Documentation/devicetree/bindings/arm/realtek.txt +++ /dev/null @@ -1,22 +0,0 @@ -Realtek platforms device tree bindings --------------------------------------- - - -RTD1295 SoC -=========== - -Required root node properties: - - - compatible : must contain "realtek,rtd1295" - - -Root node property compatible must contain, depending on board: - - - MeLE V9: "mele,v9" - - ProBox2 AVA: "probox2,ava" - - Zidoo X9S: "zidoo,x9s" - - -Example: - - compatible = "zidoo,x9s", "realtek,rtd1295"; diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml new file mode 100644 index 000000000000..3528b61963b4 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/realtek.yaml @@ -0,0 +1,23 @@ +# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/realtek.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Realtek platforms device tree bindings + +maintainers: + - Andreas Färber + +properties: + $nodename: + const: '/' + compatible: + # RTD1295 SoC based boards + items: + - enum: + - mele,v9 + - probox2,ava + - zidoo,x9s + - const: realtek,rtd1295 +... diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 34865042f4e4..c82c5e57d44c 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -128,6 +128,21 @@ properties: - const: google,veyron - const: rockchip,rk3288 + - description: Google Fievel (AOPEN Chromebox Mini) + items: + - const: google,veyron-fievel-rev8 + - const: google,veyron-fievel-rev7 + - const: google,veyron-fievel-rev6 + - const: google,veyron-fievel-rev5 + - const: google,veyron-fievel-rev4 + - const: google,veyron-fievel-rev3 + - const: google,veyron-fievel-rev2 + - const: google,veyron-fievel-rev1 + - const: google,veyron-fievel-rev0 + - const: google,veyron-fievel + - const: google,veyron + - const: rockchip,rk3288 + - description: Google Gru (dev-board) items: - const: google,gru-rev15 @@ -311,6 +326,21 @@ properties: - const: google,veyron - const: rockchip,rk3288 + - description: Google Tiger (AOpen Chromebase Mini) + items: + - const: google,veyron-tiger-rev8 + - const: google,veyron-tiger-rev7 + - const: google,veyron-tiger-rev6 + - const: google,veyron-tiger-rev5 + - const: google,veyron-tiger-rev4 + - const: google,veyron-tiger-rev3 + - const: google,veyron-tiger-rev2 + - const: google,veyron-tiger-rev1 + - const: google,veyron-tiger-rev0 + - const: google,veyron-tiger + - const: google,veyron + - const: rockchip,rk3288 + - description: Haoyu MarsBoard RK3066 items: - const: haoyu,marsboard-rk3066 @@ -329,6 +359,16 @@ properties: - khadas,edge-v - const: rockchip,rk3399 + - description: Mecer Xtreme Mini S6 + items: + - const: mecer,xms6 + - const: rockchip,rk3229 + + - description: Leez RK3399 P710 + items: + - const: leez,p710 + - const: rockchip,rk3399 + - description: mqmaker MiQi items: - const: mqmaker,miqi @@ -424,11 +464,6 @@ properties: - rockchip,rk3288-evb-rk808 - const: rockchip,rk3288 - - description: Rockchip RK3288 Fennec - items: - - const: rockchip,rk3288-fennec - - const: rockchip,rk3288 - - description: Rockchip RK3328 Evaluation board items: - const: rockchip,rk3328-evb diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 000a00d12d6a..972b1e9ee804 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -353,6 +353,12 @@ properties: - const: licheepi,licheepi-zero - const: allwinner,sun8i-v3s + - description: Lichee Zero Plus (with S3, without eMMC/SPI Flash) + items: + - const: sipeed,lichee-zero-plus + - const: sochip,s3 + - const: allwinner,sun8i-v3 + - description: Linksprite PCDuino items: - const: linksprite,a10-pcduino @@ -568,6 +574,11 @@ properties: - const: olimex,a64-olinuxino - const: allwinner,sun50i-a64 + - description: Olimex A64-OlinuXino (with eMMC) + items: + - const: olimex,a64-olinuxino-emmc + - const: allwinner,sun50i-a64 + - description: Olimex A64 Teres-I items: - const: olimex,a64-teres-i @@ -671,6 +682,11 @@ properties: - const: sinlinx,sina33 - const: allwinner,sun8i-a33 + - description: Tanix TX6 + items: + - const: oranth,tanix-tx6 + - const: allwinner,sun50i-h6 + - description: TBS A711 Tablet items: - const: tbs-biometrics,a711 diff --git a/Documentation/devicetree/bindings/arm/topology.txt b/Documentation/devicetree/bindings/arm/topology.txt deleted file mode 100644 index b0d80c0fb265..000000000000 --- a/Documentation/devicetree/bindings/arm/topology.txt +++ /dev/null @@ -1,475 +0,0 @@ -=========================================== -ARM topology binding description -=========================================== - -=========================================== -1 - Introduction -=========================================== - -In an ARM system, the hierarchy of CPUs is defined through three entities that -are used to describe the layout of physical CPUs in the system: - -- cluster -- core -- thread - -The cpu nodes (bindings defined in [1]) represent the devices that -correspond to physical CPUs and are to be mapped to the hierarchy levels. - -The bottom hierarchy level sits at core or thread level depending on whether -symmetric multi-threading (SMT) is supported or not. - -For instance in a system where CPUs support SMT, "cpu" nodes represent all -threads existing in the system and map to the hierarchy level "thread" above. -In systems where SMT is not supported "cpu" nodes represent all cores present -in the system and map to the hierarchy level "core" above. - -ARM topology bindings allow one to associate cpu nodes with hierarchical groups -corresponding to the system hierarchy; syntactically they are defined as device -tree nodes. - -The remainder of this document provides the topology bindings for ARM, based -on the Devicetree Specification, available from: - -https://www.devicetree.org/specifications/ - -If not stated otherwise, whenever a reference to a cpu node phandle is made its -value must point to a cpu node compliant with the cpu node bindings as -documented in [1]. -A topology description containing phandles to cpu nodes that are not compliant -with bindings standardized in [1] is therefore considered invalid. - -=========================================== -2 - cpu-map node -=========================================== - -The ARM CPU topology is defined within the cpu-map node, which is a direct -child of the cpus node and provides a container where the actual topology -nodes are listed. - -- cpu-map node - - Usage: Optional - On ARM SMP systems provide CPUs topology to the OS. - ARM uniprocessor systems do not require a topology - description and therefore should not define a - cpu-map node. - - Description: The cpu-map node is just a container node where its - subnodes describe the CPU topology. - - Node name must be "cpu-map". - - The cpu-map node's parent node must be the cpus node. - - The cpu-map node's child nodes can be: - - - one or more cluster nodes - - Any other configuration is considered invalid. - -The cpu-map node can only contain three types of child nodes: - -- cluster node -- core node -- thread node - -whose bindings are described in paragraph 3. - -The nodes describing the CPU topology (cluster/core/thread) can only -be defined within the cpu-map node and every core/thread in the system -must be defined within the topology. Any other configuration is -invalid and therefore must be ignored. - -=========================================== -2.1 - cpu-map child nodes naming convention -=========================================== - -cpu-map child nodes must follow a naming convention where the node name -must be "clusterN", "coreN", "threadN" depending on the node type (ie -cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which -are siblings within a single common parent node must be given a unique and -sequential N value, starting from 0). -cpu-map child nodes which do not share a common parent node can have the same -name (ie same number N as other cpu-map child nodes at different device tree -levels) since name uniqueness will be guaranteed by the device tree hierarchy. - -=========================================== -3 - cluster/core/thread node bindings -=========================================== - -Bindings for cluster/cpu/thread nodes are defined as follows: - -- cluster node - - Description: must be declared within a cpu-map node, one node - per cluster. A system can contain several layers of - clustering and cluster nodes can be contained in parent - cluster nodes. - - The cluster node name must be "clusterN" as described in 2.1 above. - A cluster node can not be a leaf node. - - A cluster node's child nodes must be: - - - one or more cluster nodes; or - - one or more core nodes - - Any other configuration is considered invalid. - -- core node - - Description: must be declared in a cluster node, one node per core in - the cluster. If the system does not support SMT, core - nodes are leaf nodes, otherwise they become containers of - thread nodes. - - The core node name must be "coreN" as described in 2.1 above. - - A core node must be a leaf node if SMT is not supported. - - Properties for core nodes that are leaf nodes: - - - cpu - Usage: required - Value type: - Definition: a phandle to the cpu node that corresponds to the - core node. - - If a core node is not a leaf node (CPUs supporting SMT) a core node's - child nodes can be: - - - one or more thread nodes - - Any other configuration is considered invalid. - -- thread node - - Description: must be declared in a core node, one node per thread - in the core if the system supports SMT. Thread nodes are - always leaf nodes in the device tree. - - The thread node name must be "threadN" as described in 2.1 above. - - A thread node must be a leaf node. - - A thread node must contain the following property: - - - cpu - Usage: required - Value type: - Definition: a phandle to the cpu node that corresponds to - the thread node. - -=========================================== -4 - Example dts -=========================================== - -Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters): - -cpus { - #size-cells = <0>; - #address-cells = <2>; - - cpu-map { - cluster0 { - cluster0 { - core0 { - thread0 { - cpu = <&CPU0>; - }; - thread1 { - cpu = <&CPU1>; - }; - }; - - core1 { - thread0 { - cpu = <&CPU2>; - }; - thread1 { - cpu = <&CPU3>; - }; - }; - }; - - cluster1 { - core0 { - thread0 { - cpu = <&CPU4>; - }; - thread1 { - cpu = <&CPU5>; - }; - }; - - core1 { - thread0 { - cpu = <&CPU6>; - }; - thread1 { - cpu = <&CPU7>; - }; - }; - }; - }; - - cluster1 { - cluster0 { - core0 { - thread0 { - cpu = <&CPU8>; - }; - thread1 { - cpu = <&CPU9>; - }; - }; - core1 { - thread0 { - cpu = <&CPU10>; - }; - thread1 { - cpu = <&CPU11>; - }; - }; - }; - - cluster1 { - core0 { - thread0 { - cpu = <&CPU12>; - }; - thread1 { - cpu = <&CPU13>; - }; - }; - core1 { - thread0 { - cpu = <&CPU14>; - }; - thread1 { - cpu = <&CPU15>; - }; - }; - }; - }; - }; - - CPU0: cpu@0 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x0 0x0>; - enable-method = "spin-table"; - cpu-release-addr = <0 0x20000000>; - }; - - CPU1: cpu@1 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x0 0x1>; - enable-method = "spin-table"; - cpu-release-addr = <0 0x20000000>; - }; - - CPU2: cpu@100 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x0 0x100>; - enable-method = "spin-table"; - cpu-release-addr = <0 0x20000000>; - }; - - CPU3: cpu@101 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x0 0x101>; - enable-method = "spin-table"; - cpu-release-addr = <0 0x20000000>; - }; - - CPU4: cpu@10000 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x0 0x10000>; - enable-method = "spin-table"; - cpu-release-addr = <0 0x20000000>; - }; - - CPU5: cpu@10001 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x0 0x10001>; - enable-method = "spin-table"; - cpu-release-addr = <0 0x20000000>; - }; - - CPU6: cpu@10100 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x0 0x10100>; - enable-method = "spin-table"; - cpu-release-addr = <0 0x20000000>; - }; - - CPU7: cpu@10101 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x0 0x10101>; - enable-method = "spin-table"; - cpu-release-addr = <0 0x20000000>; - }; - - CPU8: cpu@100000000 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x1 0x0>; - enable-method = "spin-table"; - cpu-release-addr = <0 0x20000000>; - }; - - CPU9: cpu@100000001 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x1 0x1>; - enable-method = "spin-table"; - cpu-release-addr = <0 0x20000000>; - }; - - CPU10: cpu@100000100 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x1 0x100>; - enable-method = "spin-table"; - cpu-release-addr = <0 0x20000000>; - }; - - CPU11: cpu@100000101 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x1 0x101>; - enable-method = "spin-table"; - cpu-release-addr = <0 0x20000000>; - }; - - CPU12: cpu@100010000 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x1 0x10000>; - enable-method = "spin-table"; - cpu-release-addr = <0 0x20000000>; - }; - - CPU13: cpu@100010001 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x1 0x10001>; - enable-method = "spin-table"; - cpu-release-addr = <0 0x20000000>; - }; - - CPU14: cpu@100010100 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x1 0x10100>; - enable-method = "spin-table"; - cpu-release-addr = <0 0x20000000>; - }; - - CPU15: cpu@100010101 { - device_type = "cpu"; - compatible = "arm,cortex-a57"; - reg = <0x1 0x10101>; - enable-method = "spin-table"; - cpu-release-addr = <0 0x20000000>; - }; -}; - -Example 2 (ARM 32-bit, dual-cluster, 8-cpu system, no SMT): - -cpus { - #size-cells = <0>; - #address-cells = <1>; - - cpu-map { - cluster0 { - core0 { - cpu = <&CPU0>; - }; - core1 { - cpu = <&CPU1>; - }; - core2 { - cpu = <&CPU2>; - }; - core3 { - cpu = <&CPU3>; - }; - }; - - cluster1 { - core0 { - cpu = <&CPU4>; - }; - core1 { - cpu = <&CPU5>; - }; - core2 { - cpu = <&CPU6>; - }; - core3 { - cpu = <&CPU7>; - }; - }; - }; - - CPU0: cpu@0 { - device_type = "cpu"; - compatible = "arm,cortex-a15"; - reg = <0x0>; - }; - - CPU1: cpu@1 { - device_type = "cpu"; - compatible = "arm,cortex-a15"; - reg = <0x1>; - }; - - CPU2: cpu@2 { - device_type = "cpu"; - compatible = "arm,cortex-a15"; - reg = <0x2>; - }; - - CPU3: cpu@3 { - device_type = "cpu"; - compatible = "arm,cortex-a15"; - reg = <0x3>; - }; - - CPU4: cpu@100 { - device_type = "cpu"; - compatible = "arm,cortex-a7"; - reg = <0x100>; - }; - - CPU5: cpu@101 { - device_type = "cpu"; - compatible = "arm,cortex-a7"; - reg = <0x101>; - }; - - CPU6: cpu@102 { - device_type = "cpu"; - compatible = "arm,cortex-a7"; - reg = <0x102>; - }; - - CPU7: cpu@103 { - device_type = "cpu"; - compatible = "arm,cortex-a7"; - reg = <0x103>; - }; -}; - -=============================================================================== -[1] ARM Linux kernel documentation - Documentation/devicetree/bindings/arm/cpus.yaml diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt index e30fd106df4f..55c6fab1b373 100644 --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt @@ -45,7 +45,7 @@ Required properties when using sub-nodes: - #address-cells : number of cells to encode an address - #size-cells : number of cells representing the size of an address -For allwinner,sun8i-r40-ahci, the reset propertie must be present. +For allwinner,sun8i-r40-ahci, the reset property must be present. Sub-nodes required properties: - reg : the port number diff --git a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml new file mode 100644 index 000000000000..d2a872286437 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/allwinner,sun50i-a64-de2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A64 Display Engine Bus Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +properties: + $nodename: + pattern: "^bus(@[0-9a-f]+)?$" + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + compatible: + oneOf: + - const: allwinner,sun50i-a64-de2 + - items: + - const: allwinner,sun50i-h6-de3 + - const: allwinner,sun50i-a64-de2 + + reg: + maxItems: 1 + + allwinner,sram: + allOf: + - $ref: /schemas/types.yaml#definitions/phandle-array + - maxItems: 1 + description: + The SRAM that needs to be claimed to access the display engine + bus. + + ranges: true + +patternProperties: + # All other properties should be child nodes with unit-address and 'reg' + "^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-fA-F]+$": + type: object + properties: + reg: + maxItems: 1 + + required: + - reg + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + - ranges + - allwinner,sram + +additionalProperties: false + +examples: + - | + bus@1000000 { + compatible = "allwinner,sun50i-a64-de2"; + reg = <0x1000000 0x400000>; + allwinner,sram = <&de2_sram 1>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x1000000 0x400000>; + + display_clocks: clock@0 { + compatible = "allwinner,sun50i-a64-de2-clk"; + reg = <0x0 0x100000>; + clocks = <&ccu 52>, <&ccu 99>; + clock-names = "bus", "mod"; + resets = <&ccu 30>; + #clock-cells = <1>; + #reset-cells = <1>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt b/Documentation/devicetree/bindings/bus/imx-weim.txt index dda7d6d66479..1b1d1c5c21ea 100644 --- a/Documentation/devicetree/bindings/bus/imx-weim.txt +++ b/Documentation/devicetree/bindings/bus/imx-weim.txt @@ -44,6 +44,10 @@ Optional properties: what bootloader sets up in IOMUXC_GPR1[11:0] will be used. + - fsl,burst-clk-enable For "fsl,imx50-weim" and "fsl,imx6q-weim" type of + devices, the presence of this property indicates that + the weim bus should operate in Burst Clock Mode. + Timing property for child nodes. It is mandatory, not optional. - fsl,weim-cs-timing: The timing array, contains timing values for the diff --git a/Documentation/devicetree/bindings/bus/moxtet.txt b/Documentation/devicetree/bindings/bus/moxtet.txt new file mode 100644 index 000000000000..fb50fc865336 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/moxtet.txt @@ -0,0 +1,46 @@ +Turris Mox module status and configuration bus (over SPI) + +Required properties: + - compatible : Should be "cznic,moxtet" + - #address-cells : Has to be 1 + - #size-cells : Has to be 0 + - spi-cpol : Required inverted clock polarity + - spi-cpha : Required shifted clock phase + - interrupts : Must contain reference to the shared interrupt line + - interrupt-controller : Required + - #interrupt-cells : Has to be 1 + +For other required and optional properties of SPI slave nodes please refer to +../spi/spi-bus.txt. + +Required properties of subnodes: + - reg : Should be position on the Moxtet bus (how many Moxtet + modules are between this module and CPU module, so + either 0 or a positive integer) + +The driver finds the devices connected to the bus by itself, but it may be +needed to reference some of them from other parts of the device tree. In that +case the devices can be defined as subnodes of the moxtet node. + +Example: + + moxtet@1 { + compatible = "cznic,moxtet"; + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + spi-max-frequency = <10000000>; + spi-cpol; + spi-cpha; + interrupt-controller; + #interrupt-cells = <1>; + interrupt-parent = <&gpiosb>; + interrupts = <5 IRQ_TYPE_EDGE_FALLING>; + + moxtet_sfp: gpio@0 { + compatible = "cznic,moxtet-gpio"; + gpio-controller; + #gpio-cells = <2>; + reg = <0>; + } + }; diff --git a/Documentation/devicetree/bindings/bus/qcom,ebi2.txt b/Documentation/devicetree/bindings/bus/qcom,ebi2.txt index 5a7d567f6833..5058aa2c63b2 100644 --- a/Documentation/devicetree/bindings/bus/qcom,ebi2.txt +++ b/Documentation/devicetree/bindings/bus/qcom,ebi2.txt @@ -71,7 +71,7 @@ Optional subnodes: The following optional properties are properties that can be tagged onto any device subnode. We are assuming that there can be only ONE device per -chipselect subnode, else the properties will become ambigous. +chipselect subnode, else the properties will become ambiguous. Optional properties arrays for SLOW chip selects: - qcom,xmem-recovery-cycles: recovery cycles is the time the memory continues to diff --git a/Documentation/devicetree/bindings/bus/sun50i-de2-bus.txt b/Documentation/devicetree/bindings/bus/sun50i-de2-bus.txt deleted file mode 100644 index b9d533717dff..000000000000 --- a/Documentation/devicetree/bindings/bus/sun50i-de2-bus.txt +++ /dev/null @@ -1,40 +0,0 @@ -Device tree bindings for Allwinner DE2/3 bus - -The Allwinner A64 DE2 is on a special bus, which needs a SRAM region (SRAM C) -to be claimed for enabling the access. The DE3 on Allwinner H6 is at the same -situation, and the binding also applies. - -Required properties: - - - compatible: Should be one of: - - "allwinner,sun50i-a64-de2" - - "allwinner,sun50i-h6-de3", "allwinner,sun50i-a64-de2" - - reg: A resource specifier for the register space - - #address-cells: Must be set to 1 - - #size-cells: Must be set to 1 - - ranges: Must be set up to map the address space inside the - DE2, for the sub-blocks of DE2. - - allwinner,sram: the SRAM that needs to be claimed - -Example: - - de2@1000000 { - compatible = "allwinner,sun50i-a64-de2"; - reg = <0x1000000 0x400000>; - allwinner,sram = <&de2_sram 1>; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x1000000 0x400000>; - - display_clocks: clock@0 { - compatible = "allwinner,sun50i-a64-de2-clk"; - reg = <0x0 0x100000>; - clocks = <&ccu CLK_DE>, - <&ccu CLK_BUS_DE>; - clock-names = "mod", - "bus"; - resets = <&ccu RST_BUS_DE>; - #clock-cells = <1>; - #reset-cells = <1>; - }; - }; diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml index fa4d143a73de..64938fdaea55 100644 --- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml +++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml @@ -31,6 +31,7 @@ properties: - allwinner,sun8i-h3-ccu - allwinner,sun8i-h3-r-ccu - allwinner,sun8i-r40-ccu + - allwinner,sun8i-v3-ccu - allwinner,sun8i-v3s-ccu - allwinner,sun9i-a80-ccu - allwinner,sun50i-a64-ccu diff --git a/Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.txt b/Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.txt index 0f777749f4f1..b3957d10d241 100644 --- a/Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.txt +++ b/Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.txt @@ -22,6 +22,7 @@ Required Properties: components. - resets : phandle of the internal reset line - #clock-cells : should be 1. +- #reset-cells : should be 1 on the g12a (and following) soc family Each clock is assigned an identifier and client nodes can use this identifier to specify the clock which they consume. All available clocks are defined as diff --git a/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt b/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt index 6eaa52092313..7ccecd5c02c1 100644 --- a/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt +++ b/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt @@ -11,6 +11,7 @@ Required Properties: "amlogic,axg-clkc" for AXG SoC. "amlogic,g12a-clkc" for G12A SoC. "amlogic,g12b-clkc" for G12B SoC. + "amlogic,sm1-clkc" for SM1 SoC. - clocks : list of clock phandle, one for each entry clock-names. - clock-names : should contain the following: * "xtal": the platform xtal diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt b/Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt index dd906db34b32..9e0b03a6519b 100644 --- a/Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt +++ b/Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt @@ -12,7 +12,9 @@ clock generators, but a few (like the ARM or HDMI) will source from the PLL dividers directly. Required properties: -- compatible: Should be "brcm,bcm2835-cprman" +- compatible: should be one of the following, + "brcm,bcm2711-cprman" + "brcm,bcm2835-cprman" - #clock-cells: Should be <1>. The permitted clock-specifier values can be found in include/dt-bindings/clock/bcm2835.h - reg: Specifies base physical address and size of the registers diff --git a/Documentation/devicetree/bindings/clock/imx8mn-clock.yaml b/Documentation/devicetree/bindings/clock/imx8mn-clock.yaml new file mode 100644 index 000000000000..622f3658bd9f --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx8mn-clock.yaml @@ -0,0 +1,112 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bindings/clock/imx8mn-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8M Nano Clock Control Module Binding + +maintainers: + - Anson Huang + +description: | + NXP i.MX8M Nano clock control module is an integrated clock controller, which + generates and supplies to all modules. + +properties: + compatible: + const: fsl,imx8mn-ccm + + reg: + maxItems: 1 + + clocks: + items: + - description: 32k osc + - description: 24m osc + - description: ext1 clock input + - description: ext2 clock input + - description: ext3 clock input + - description: ext4 clock input + + clock-names: + items: + - const: osc_32k + - const: osc_24m + - const: clk_ext1 + - const: clk_ext2 + - const: clk_ext3 + - const: clk_ext4 + + '#clock-cells': + const: 1 + description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mn-clock.h + for the full list of i.MX8M Nano clock IDs. + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + +examples: + # Clock Control Module node: + - | + clk: clock-controller@30380000 { + compatible = "fsl,imx8mn-ccm"; + reg = <0x0 0x30380000 0x0 0x10000>; + #clock-cells = <1>; + clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, + <&clk_ext2>, <&clk_ext3>, <&clk_ext4>; + clock-names = "osc_32k", "osc_24m", "clk_ext1", + "clk_ext2", "clk_ext3", "clk_ext4"; + }; + + # Required external clocks for Clock Control Module node: + - | + osc_32k: clock-osc-32k { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <32768>; + clock-output-names = "osc_32k"; + }; + + osc_24m: clock-osc-24m { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <24000000>; + clock-output-names = "osc_24m"; + }; + + clk_ext1: clock-ext1 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <133000000>; + clock-output-names = "clk_ext1"; + }; + + clk_ext2: clock-ext2 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <133000000>; + clock-output-names = "clk_ext2"; + }; + + clk_ext3: clock-ext3 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <133000000>; + clock-output-names = "clk_ext3"; + }; + + clk_ext4: clock-ext4 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency= <133000000>; + clock-output-names = "clk_ext4"; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt index 8661c3cd3ccf..d14362ad4132 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt @@ -23,6 +23,7 @@ Required properties : "qcom,gcc-sdm630" "qcom,gcc-sdm660" "qcom,gcc-sdm845" + "qcom,gcc-sm8150" - reg : shall contain base register location and length - #clock-cells : shall contain 1 @@ -38,6 +39,13 @@ Documentation/devicetree/bindings/thermal/qcom-tsens.txt - protected-clocks : Protected clock specifier list as per common clock binding. +For SM8150 only: + - clocks: a list of phandles and clock-specifier pairs, + one for each entry in clock-names. + - clock-names: "bi_tcxo" (required) + "sleep_clk" (optional) + "aud_ref_clock" (optional) + Example: clock-controller@900000 { compatible = "qcom,gcc-msm8960"; @@ -71,3 +79,16 @@ Example of GCC with protected-clocks properties: , ; }; + +Example of GCC with clocks + gcc: clock-controller@100000 { + compatible = "qcom,gcc-sm8150"; + reg = <0x00100000 0x1f0000>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + clock-names = "bi_tcxo", + "sleep_clk"; + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, + <&sleep_clk>; + }; diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt b/Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt index 3c007653da31..365bbde599b1 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt +++ b/Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt @@ -6,9 +6,14 @@ some Qualcomm Technologies Inc. SoCs. It accepts clock requests from other hardware subsystems via RSC to control clocks. Required properties : -- compatible : shall contain "qcom,sdm845-rpmh-clk" +- compatible : must be one of: + "qcom,sdm845-rpmh-clk" + "qcom,sm8150-rpmh-clk" - #clock-cells : must contain 1 +- clocks: a list of phandles and clock-specifier pairs, + one for each entry in clock-names. +- clock-names: Parent board clock: "xo". Example : diff --git a/Documentation/devicetree/bindings/clock/emev2-clock.txt b/Documentation/devicetree/bindings/clock/renesas,emev2-smu.txt similarity index 100% rename from Documentation/devicetree/bindings/clock/emev2-clock.txt rename to Documentation/devicetree/bindings/clock/renesas,emev2-smu.txt diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3308-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3308-cru.txt new file mode 100644 index 000000000000..9b151c5b0c90 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3308-cru.txt @@ -0,0 +1,60 @@ +* Rockchip RK3308 Clock and Reset Unit + +The RK3308 clock controller generates and supplies clock to various +controllers within the SoC and also implements a reset controller for SoC +peripherals. + +Required Properties: + +- compatible: CRU should be "rockchip,rk3308-cru" +- reg: physical base address of the controller and length of memory mapped + region. +- #clock-cells: should be 1. +- #reset-cells: should be 1. + +Optional Properties: + +- rockchip,grf: phandle to the syscon managing the "general register files" + If missing, pll rates are not changeable, due to the missing pll lock status. + +Each clock is assigned an identifier and client nodes can use this identifier +to specify the clock which they consume. All available clocks are defined as +preprocessor macros in the dt-bindings/clock/rk3308-cru.h headers and can be +used in device tree sources. Similar macros exist for the reset sources in +these files. + +External clocks: + +There are several clocks that are generated outside the SoC. It is expected +that they are defined using standard clock bindings with following +clock-output-names: + - "xin24m" - crystal input - required, + - "xin32k" - rtc clock - optional, + - "mclk_i2s0_8ch_in", "mclk_i2s1_8ch_in", "mclk_i2s2_8ch_in", + "mclk_i2s3_8ch_in", "mclk_i2s0_2ch_in", + "mclk_i2s1_2ch_in" - external I2S or SPDIF clock - optional, + - "mac_clkin" - external MAC clock - optional + +Example: Clock controller node: + + cru: clock-controller@ff500000 { + compatible = "rockchip,rk3308-cru"; + reg = <0x0 0xff500000 0x0 0x1000>; + rockchip,grf = <&grf>; + #clock-cells = <1>; + #reset-cells = <1>; + }; + +Example: UART controller node that consumes the clock generated by the clock + controller: + + uart0: serial@ff0a0000 { + compatible = "rockchip,rk3308-uart", "snps,dw-apb-uart"; + reg = <0x0 0xff0a0000 0x0 0x100>; + interrupts = ; + clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>; + clock-names = "baudclk", "apb_pclk"; + reg-shift = <2>; + reg-io-width = <4>; + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/clock/ti,cdce925.txt b/Documentation/devicetree/bindings/clock/ti,cdce925.txt index 0d01f2d5cc36..26544c85202a 100644 --- a/Documentation/devicetree/bindings/clock/ti,cdce925.txt +++ b/Documentation/devicetree/bindings/clock/ti,cdce925.txt @@ -24,6 +24,8 @@ Required properties: Optional properties: - xtal-load-pf: Crystal load-capacitor value to fine-tune performance on a board, or to compensate for external influences. +- vdd-supply: A regulator node for Vdd +- vddout-supply: A regulator node for Vddout For all PLL1, PLL2, ... an optional child node can be used to specify spread spectrum clocking parameters for a board. @@ -41,6 +43,8 @@ Example: clocks = <&xtal_27Mhz>; #clock-cells = <1>; xtal-load-pf = <5>; + vdd-supply = <&1v8-reg>; + vddout-supply = <&3v3-reg>; /* PLL options to get SSC 1% centered */ PLL2 { spread-spectrum = <4>; diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt b/Documentation/devicetree/bindings/connector/usb-connector.txt index cef556d4e5ee..d357987181ee 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.txt +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt @@ -17,6 +17,20 @@ Optional properties: - self-powered: Set this property if the usb device that has its own power source. +Optional properties for usb-b-connector: +- id-gpios: an input gpio for USB ID pin. +- vbus-gpios: an input gpio for USB VBUS pin, used to detect presence of + VBUS 5V. + see gpio/gpio.txt. +- vbus-supply: a phandle to the regulator for USB VBUS if needed when host + mode or dual role mode is supported. + Particularly, if use an output GPIO to control a VBUS regulator, should + model it as a regulator. + see regulator/fixed-regulator.yaml +- pinctrl-names : a pinctrl state named "default" is optional +- pinctrl-0 : pin control group + see pinctrl/pinctrl-bindings.txt + Optional properties for usb-c-connector: - power-role: should be one of "source", "sink" or "dual"(DRP) if typec connector has power support. diff --git a/Documentation/devicetree/bindings/cpu/cpu-topology.txt b/Documentation/devicetree/bindings/cpu/cpu-topology.txt new file mode 100644 index 000000000000..99918189403c --- /dev/null +++ b/Documentation/devicetree/bindings/cpu/cpu-topology.txt @@ -0,0 +1,553 @@ +=========================================== +CPU topology binding description +=========================================== + +=========================================== +1 - Introduction +=========================================== + +In a SMP system, the hierarchy of CPUs is defined through three entities that +are used to describe the layout of physical CPUs in the system: + +- socket +- cluster +- core +- thread + +The bottom hierarchy level sits at core or thread level depending on whether +symmetric multi-threading (SMT) is supported or not. + +For instance in a system where CPUs support SMT, "cpu" nodes represent all +threads existing in the system and map to the hierarchy level "thread" above. +In systems where SMT is not supported "cpu" nodes represent all cores present +in the system and map to the hierarchy level "core" above. + +CPU topology bindings allow one to associate cpu nodes with hierarchical groups +corresponding to the system hierarchy; syntactically they are defined as device +tree nodes. + +Currently, only ARM/RISC-V intend to use this cpu topology binding but it may be +used for any other architecture as well. + +The cpu nodes, as per bindings defined in [4], represent the devices that +correspond to physical CPUs and are to be mapped to the hierarchy levels. + +A topology description containing phandles to cpu nodes that are not compliant +with bindings standardized in [4] is therefore considered invalid. + +=========================================== +2 - cpu-map node +=========================================== + +The ARM/RISC-V CPU topology is defined within the cpu-map node, which is a direct +child of the cpus node and provides a container where the actual topology +nodes are listed. + +- cpu-map node + + Usage: Optional - On SMP systems provide CPUs topology to the OS. + Uniprocessor systems do not require a topology + description and therefore should not define a + cpu-map node. + + Description: The cpu-map node is just a container node where its + subnodes describe the CPU topology. + + Node name must be "cpu-map". + + The cpu-map node's parent node must be the cpus node. + + The cpu-map node's child nodes can be: + + - one or more cluster nodes or + - one or more socket nodes in a multi-socket system + + Any other configuration is considered invalid. + +The cpu-map node can only contain 4 types of child nodes: + +- socket node +- cluster node +- core node +- thread node + +whose bindings are described in paragraph 3. + +The nodes describing the CPU topology (socket/cluster/core/thread) can +only be defined within the cpu-map node and every core/thread in the +system must be defined within the topology. Any other configuration is +invalid and therefore must be ignored. + +=========================================== +2.1 - cpu-map child nodes naming convention +=========================================== + +cpu-map child nodes must follow a naming convention where the node name +must be "socketN", "clusterN", "coreN", "threadN" depending on the node type +(ie socket/cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes +which are siblings within a single common parent node must be given a unique and +sequential N value, starting from 0). +cpu-map child nodes which do not share a common parent node can have the same +name (ie same number N as other cpu-map child nodes at different device tree +levels) since name uniqueness will be guaranteed by the device tree hierarchy. + +=========================================== +3 - socket/cluster/core/thread node bindings +=========================================== + +Bindings for socket/cluster/cpu/thread nodes are defined as follows: + +- socket node + + Description: must be declared within a cpu-map node, one node + per physical socket in the system. A system can + contain single or multiple physical socket. + The association of sockets and NUMA nodes is beyond + the scope of this bindings, please refer [2] for + NUMA bindings. + + This node is optional for a single socket system. + + The socket node name must be "socketN" as described in 2.1 above. + A socket node can not be a leaf node. + + A socket node's child nodes must be one or more cluster nodes. + + Any other configuration is considered invalid. + +- cluster node + + Description: must be declared within a cpu-map node, one node + per cluster. A system can contain several layers of + clustering within a single physical socket and cluster + nodes can be contained in parent cluster nodes. + + The cluster node name must be "clusterN" as described in 2.1 above. + A cluster node can not be a leaf node. + + A cluster node's child nodes must be: + + - one or more cluster nodes; or + - one or more core nodes + + Any other configuration is considered invalid. + +- core node + + Description: must be declared in a cluster node, one node per core in + the cluster. If the system does not support SMT, core + nodes are leaf nodes, otherwise they become containers of + thread nodes. + + The core node name must be "coreN" as described in 2.1 above. + + A core node must be a leaf node if SMT is not supported. + + Properties for core nodes that are leaf nodes: + + - cpu + Usage: required + Value type: + Definition: a phandle to the cpu node that corresponds to the + core node. + + If a core node is not a leaf node (CPUs supporting SMT) a core node's + child nodes can be: + + - one or more thread nodes + + Any other configuration is considered invalid. + +- thread node + + Description: must be declared in a core node, one node per thread + in the core if the system supports SMT. Thread nodes are + always leaf nodes in the device tree. + + The thread node name must be "threadN" as described in 2.1 above. + + A thread node must be a leaf node. + + A thread node must contain the following property: + + - cpu + Usage: required + Value type: + Definition: a phandle to the cpu node that corresponds to + the thread node. + +=========================================== +4 - Example dts +=========================================== + +Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters in a single +physical socket): + +cpus { + #size-cells = <0>; + #address-cells = <2>; + + cpu-map { + socket0 { + cluster0 { + cluster0 { + core0 { + thread0 { + cpu = <&CPU0>; + }; + thread1 { + cpu = <&CPU1>; + }; + }; + + core1 { + thread0 { + cpu = <&CPU2>; + }; + thread1 { + cpu = <&CPU3>; + }; + }; + }; + + cluster1 { + core0 { + thread0 { + cpu = <&CPU4>; + }; + thread1 { + cpu = <&CPU5>; + }; + }; + + core1 { + thread0 { + cpu = <&CPU6>; + }; + thread1 { + cpu = <&CPU7>; + }; + }; + }; + }; + + cluster1 { + cluster0 { + core0 { + thread0 { + cpu = <&CPU8>; + }; + thread1 { + cpu = <&CPU9>; + }; + }; + core1 { + thread0 { + cpu = <&CPU10>; + }; + thread1 { + cpu = <&CPU11>; + }; + }; + }; + + cluster1 { + core0 { + thread0 { + cpu = <&CPU12>; + }; + thread1 { + cpu = <&CPU13>; + }; + }; + core1 { + thread0 { + cpu = <&CPU14>; + }; + thread1 { + cpu = <&CPU15>; + }; + }; + }; + }; + }; + }; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x0>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU1: cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x1>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU2: cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x100>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU3: cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x101>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU4: cpu@10000 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10000>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU5: cpu@10001 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10001>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU6: cpu@10100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10100>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU7: cpu@10101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10101>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU8: cpu@100000000 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x0>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU9: cpu@100000001 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x1>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU10: cpu@100000100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x100>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU11: cpu@100000101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x101>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU12: cpu@100010000 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x10000>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU13: cpu@100010001 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x10001>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU14: cpu@100010100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x10100>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU15: cpu@100010101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x10101>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; +}; + +Example 2 (ARM 32-bit, dual-cluster, 8-cpu system, no SMT): + +cpus { + #size-cells = <0>; + #address-cells = <1>; + + cpu-map { + cluster0 { + core0 { + cpu = <&CPU0>; + }; + core1 { + cpu = <&CPU1>; + }; + core2 { + cpu = <&CPU2>; + }; + core3 { + cpu = <&CPU3>; + }; + }; + + cluster1 { + core0 { + cpu = <&CPU4>; + }; + core1 { + cpu = <&CPU5>; + }; + core2 { + cpu = <&CPU6>; + }; + core3 { + cpu = <&CPU7>; + }; + }; + }; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x0>; + }; + + CPU1: cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x1>; + }; + + CPU2: cpu@2 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x2>; + }; + + CPU3: cpu@3 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x3>; + }; + + CPU4: cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x100>; + }; + + CPU5: cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x101>; + }; + + CPU6: cpu@102 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x102>; + }; + + CPU7: cpu@103 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x103>; + }; +}; + +Example 3: HiFive Unleashed (RISC-V 64 bit, 4 core system) + +{ + #address-cells = <2>; + #size-cells = <2>; + compatible = "sifive,fu540g", "sifive,fu500"; + model = "sifive,hifive-unleashed-a00"; + + ... + cpus { + #address-cells = <1>; + #size-cells = <0>; + cpu-map { + socket0 { + cluster0 { + core0 { + cpu = <&CPU1>; + }; + core1 { + cpu = <&CPU2>; + }; + core2 { + cpu0 = <&CPU2>; + }; + core3 { + cpu0 = <&CPU3>; + }; + }; + }; + }; + + CPU1: cpu@1 { + device_type = "cpu"; + compatible = "sifive,rocket0", "riscv"; + reg = <0x1>; + } + + CPU2: cpu@2 { + device_type = "cpu"; + compatible = "sifive,rocket0", "riscv"; + reg = <0x2>; + } + CPU3: cpu@3 { + device_type = "cpu"; + compatible = "sifive,rocket0", "riscv"; + reg = <0x3>; + } + CPU4: cpu@4 { + device_type = "cpu"; + compatible = "sifive,rocket0", "riscv"; + reg = <0x4>; + } + } +}; +=============================================================================== +[1] ARM Linux kernel documentation + Documentation/devicetree/bindings/arm/cpus.yaml +[2] Devicetree NUMA binding description + Documentation/devicetree/bindings/numa.txt +[3] RISC-V Linux kernel documentation + Documentation/devicetree/bindings/riscv/cpus.txt +[4] https://www.devicetree.org/specifications/ diff --git a/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml b/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml new file mode 100644 index 000000000000..80b3e7350a73 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/allwinner,sun4i-a10-crypto.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A10 Security System Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +properties: + compatible: + oneOf: + - const: allwinner,sun4i-a10-crypto + - items: + - const: allwinner,sun5i-a13-crypto + - const: allwinner,sun4i-a10-crypto + - items: + - const: allwinner,sun6i-a31-crypto + - const: allwinner,sun4i-a10-crypto + - items: + - const: allwinner,sun7i-a20-crypto + - const: allwinner,sun4i-a10-crypto + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Bus Clock + - description: Module Clock + + clock-names: + items: + - const: ahb + - const: mod + + resets: + maxItems: 1 + + reset-names: + const: ahb + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +if: + properties: + compatible: + contains: + const: allwinner,sun6i-a31-crypto + +then: + required: + - resets + - reset-names + +additionalProperties: false + +examples: + - | + crypto: crypto-engine@1c15000 { + compatible = "allwinner,sun4i-a10-crypto"; + reg = <0x01c15000 0x1000>; + interrupts = <86>; + clocks = <&ahb_gates 5>, <&ss_clk>; + clock-names = "ahb", "mod"; + }; + +... diff --git a/Documentation/devicetree/bindings/crypto/sun4i-ss.txt b/Documentation/devicetree/bindings/crypto/sun4i-ss.txt deleted file mode 100644 index f2dc3d9bca92..000000000000 --- a/Documentation/devicetree/bindings/crypto/sun4i-ss.txt +++ /dev/null @@ -1,23 +0,0 @@ -* Allwinner Security System found on A20 SoC - -Required properties: -- compatible : Should be "allwinner,sun4i-a10-crypto". -- reg: Should contain the Security System register location and length. -- interrupts: Should contain the IRQ line for the Security System. -- clocks : List of clock specifiers, corresponding to ahb and ss. -- clock-names : Name of the functional clock, should be - * "ahb" : AHB gating clock - * "mod" : SS controller clock - -Optional properties: - - resets : phandle + reset specifier pair - - reset-names : must contain "ahb" - -Example: - crypto: crypto-engine@1c15000 { - compatible = "allwinner,sun4i-a10-crypto"; - reg = <0x01c15000 0x1000>; - interrupts = ; - clocks = <&ahb_gates 5>, <&ss_clk>; - clock-names = "ahb", "mod"; - }; diff --git a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml index 47950fced28d..dafc0980c4fa 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml @@ -36,6 +36,9 @@ properties: resets: maxItems: 1 + vcc-dsi-supply: + description: VCC-DSI power supply of the DSI encoder + phys: maxItems: 1 @@ -64,6 +67,7 @@ required: - phys - phy-names - resets + - vcc-dsi-supply - port additionalProperties: false @@ -79,6 +83,7 @@ examples: resets = <&ccu 4>; phys = <&dphy0>; phy-names = "dphy"; + vcc-dsi-supply = <®_dcdc1>; #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/display/bridge/anx7814.txt b/Documentation/devicetree/bindings/display/bridge/anx7814.txt index dbd7c84ee584..17258747fff6 100644 --- a/Documentation/devicetree/bindings/display/bridge/anx7814.txt +++ b/Documentation/devicetree/bindings/display/bridge/anx7814.txt @@ -6,7 +6,11 @@ designed for portable devices. Required properties: - - compatible : "analogix,anx7814" + - compatible : Must be one of: + "analogix,anx7808" + "analogix,anx7812" + "analogix,anx7814" + "analogix,anx7818" - reg : I2C address of the device - interrupts : Should contain the INTP interrupt - hpd-gpios : Which GPIO to use for hpd diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 6bb59ab39f2f..ce4c1fc9116c 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -14,6 +14,8 @@ Required properties: - rockchip,grf: this soc should set GRF regs to mux vopl/vopb. - ports: contain a port node with endpoint definitions as defined in [2]. For vopb,set the reg = <0> and set the reg = <1> for vopl. +- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl +- video port 1 for either a panel or subsequent encoder Optional properties: - power-domains: a phandle to mipi dsi power domain node. @@ -40,11 +42,12 @@ Example: ports { #address-cells = <1>; #size-cells = <0>; - reg = <1>; - mipi_in: port { + mipi_in: port@0 { + reg = <0>; #address-cells = <1>; #size-cells = <0>; + mipi_in_vopb: endpoint@0 { reg = <0>; remote-endpoint = <&vopb_out_mipi>; @@ -54,6 +57,16 @@ Example: remote-endpoint = <&vopl_out_mipi>; }; }; + + mipi_out: port@1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + mipi_out_panel: endpoint { + remote-endpoint = <&panel_in_mipi>; + }; + }; }; panel { @@ -64,5 +77,11 @@ Example: pinctrl-names = "default"; pinctrl-0 = <&lcd_en>; backlight = <&backlight>; + + port { + panel_in_mipi: endpoint { + remote-endpoint = <&mipi_out_panel>; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml new file mode 100644 index 000000000000..15abc0f9429f --- /dev/null +++ b/Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/allwinner,sun4i-a10-dma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A10 DMA Controller Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + "#dma-cells": + const: 2 + description: + The first cell is either 0 or 1, the former to use the normal + DMA, 1 for dedicated DMA. The second cell is the request line + number. + + compatible: + const: allwinner,sun4i-a10-dma + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - "#dma-cells" + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + dma: dma-controller@1c02000 { + compatible = "allwinner,sun4i-a10-dma"; + reg = <0x01c02000 0x1000>; + interrupts = <27>; + clocks = <&ahb_gates 6>; + #dma-cells = <2>; + }; + +... diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml new file mode 100644 index 000000000000..4cb9d6b93138 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/allwinner,sun50i-a64-dma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A64 DMA Controller Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + "#dma-cells": + const: 1 + description: The cell is the request line number. + + compatible: + enum: + - allwinner,sun50i-a64-dma + - allwinner,sun50i-h6-dma + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + items: + - const: bus + - const: mbus + + resets: + maxItems: 1 + +required: + - "#dma-cells" + - compatible + - reg + - interrupts + - clocks + - resets + - dma-channels + +if: + properties: + compatible: + const: allwinner,sun50i-h6-dma + +then: + properties: + clocks: + maxItems: 2 + + required: + - clock-names + +else: + properties: + clocks: + maxItems: 1 + +# FIXME: We should set it, but it would report all the generic +# properties as additional properties. +# additionalProperties: false + +examples: + - | + dma: dma-controller@1c02000 { + compatible = "allwinner,sun50i-a64-dma"; + reg = <0x01c02000 0x1000>; + interrupts = <0 50 4>; + clocks = <&ccu 30>; + dma-channels = <8>; + dma-requests = <27>; + resets = <&ccu 7>; + #dma-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml new file mode 100644 index 000000000000..740b7f9b535b --- /dev/null +++ b/Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/allwinner,sun6i-a31-dma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A31 DMA Controller Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + "#dma-cells": + const: 1 + description: The cell is the request line number. + + compatible: + oneOf: + - const: allwinner,sun6i-a31-dma + - const: allwinner,sun8i-a23-dma + - const: allwinner,sun8i-a83t-dma + - const: allwinner,sun8i-h3-dma + - const: allwinner,sun8i-v3s-dma + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - "#dma-cells" + - compatible + - reg + - interrupts + - clocks + - resets + +additionalProperties: false + +examples: + - | + dma: dma-controller@1c02000 { + compatible = "allwinner,sun6i-a31-dma"; + reg = <0x01c02000 0x1000>; + interrupts = <0 50 4>; + clocks = <&ahb1_gates 6>; + resets = <&ahb1_rst 6>; + #dma-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/dma/dma-common.yaml b/Documentation/devicetree/bindings/dma/dma-common.yaml new file mode 100644 index 000000000000..ed0a49a6f020 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/dma-common.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/dma-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DMA Engine Generic Binding + +maintainers: + - Vinod Koul + +description: + Generic binding to provide a way for a driver using DMA Engine to + retrieve the DMA request or channel information that goes from a + hardware device to a DMA controller. + +select: false + +properties: + "#dma-cells": + minimum: 1 + # Should be enough + maximum: 255 + description: + Used to provide DMA controller specific information. + + dma-channel-mask: + $ref: /schemas/types.yaml#definitions/uint32 + description: + Bitmask of available DMA channels in ascending order that are + not reserved by firmware and are available to the + kernel. i.e. first channel corresponds to LSB. + + dma-channels: + $ref: /schemas/types.yaml#definitions/uint32 + description: + Number of DMA channels supported by the controller. + + dma-requests: + $ref: /schemas/types.yaml#definitions/uint32 + description: + Number of DMA request signals supported by the controller. + +required: + - "#dma-cells" diff --git a/Documentation/devicetree/bindings/dma/dma-controller.yaml b/Documentation/devicetree/bindings/dma/dma-controller.yaml new file mode 100644 index 000000000000..c39f6de76670 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/dma-controller.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/dma-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DMA Controller Generic Binding + +maintainers: + - Vinod Koul + +allOf: + - $ref: "dma-common.yaml#" + +# Everything else is described in the common file +properties: + $nodename: + pattern: "^dma-controller(@.*)?$" + +examples: + - | + dma: dma-controller@48000000 { + compatible = "ti,omap-sdma"; + reg = <0x48000000 0x1000>; + interrupts = <0 12 0x4 + 0 13 0x4 + 0 14 0x4 + 0 15 0x4>; + #dma-cells = <1>; + dma-channels = <32>; + dma-requests = <127>; + dma-channel-mask = <0xfffe>; + }; + +... diff --git a/Documentation/devicetree/bindings/dma/dma-router.yaml b/Documentation/devicetree/bindings/dma/dma-router.yaml new file mode 100644 index 000000000000..5b5f07393135 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/dma-router.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/dma-router.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DMA Router Generic Binding + +maintainers: + - Vinod Koul + +allOf: + - $ref: "dma-common.yaml#" + +description: + DMA routers are transparent IP blocks used to route DMA request + lines from devices to the DMA controller. Some SoCs (like TI DRA7x) + have more peripherals integrated with DMA requests than what the DMA + controller can handle directly. + +properties: + $nodename: + pattern: "^dma-router(@.*)?$" + + dma-masters: + $ref: /schemas/types.yaml#definitions/phandle-array + description: + Array of phandles to the DMA controllers the router can direct + the signal to. + + dma-requests: + description: + Number of incoming request lines the router can handle. + +required: + - "#dma-cells" + - dma-masters + +examples: + - | + sdma_xbar: dma-router@4a002b78 { + compatible = "ti,dra7-dma-crossbar"; + reg = <0x4a002b78 0xfc>; + #dma-cells = <1>; + dma-requests = <205>; + ti,dma-safe-map = <0>; + dma-masters = <&sdma>; + }; + +... diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt index eeb4e4d1771e..90a67a016a48 100644 --- a/Documentation/devicetree/bindings/dma/dma.txt +++ b/Documentation/devicetree/bindings/dma/dma.txt @@ -1,113 +1 @@ -* Generic DMA Controller and DMA request bindings - -Generic binding to provide a way for a driver using DMA Engine to retrieve the -DMA request or channel information that goes from a hardware device to a DMA -controller. - - -* DMA controller - -Required property: -- #dma-cells: Must be at least 1. Used to provide DMA controller - specific information. See DMA client binding below for - more details. - -Optional properties: -- dma-channels: Number of DMA channels supported by the controller. -- dma-requests: Number of DMA request signals supported by the - controller. -- dma-channel-mask: Bitmask of available DMA channels in ascending order - that are not reserved by firmware and are available to - the kernel. i.e. first channel corresponds to LSB. - -Example: - - dma: dma@48000000 { - compatible = "ti,omap-sdma"; - reg = <0x48000000 0x1000>; - interrupts = <0 12 0x4 - 0 13 0x4 - 0 14 0x4 - 0 15 0x4>; - #dma-cells = <1>; - dma-channels = <32>; - dma-requests = <127>; - dma-channel-mask = <0xfffe> - }; - -* DMA router - -DMA routers are transparent IP blocks used to route DMA request lines from -devices to the DMA controller. Some SoCs (like TI DRA7x) have more peripherals -integrated with DMA requests than what the DMA controller can handle directly. - -Required property: -- dma-masters: phandle of the DMA controller or list of phandles for - the DMA controllers the router can direct the signal to. -- #dma-cells: Must be at least 1. Used to provide DMA router specific - information. See DMA client binding below for more - details. - -Optional properties: -- dma-requests: Number of incoming request lines the router can handle. -- In the node pointed by the dma-masters: - - dma-requests: The router driver might need to look for this in order - to configure the routing. - -Example: - sdma_xbar: dma-router@4a002b78 { - compatible = "ti,dra7-dma-crossbar"; - reg = <0x4a002b78 0xfc>; - #dma-cells = <1>; - dma-requests = <205>; - ti,dma-safe-map = <0>; - dma-masters = <&sdma>; - }; - -* DMA client - -Client drivers should specify the DMA property using a phandle to the controller -followed by DMA controller specific data. - -Required property: -- dmas: List of one or more DMA specifiers, each consisting of - - A phandle pointing to DMA controller node - - A number of integer cells, as determined by the - #dma-cells property in the node referenced by phandle - containing DMA controller specific information. This - typically contains a DMA request line number or a - channel number, but can contain any data that is - required for configuring a channel. -- dma-names: Contains one identifier string for each DMA specifier in - the dmas property. The specific strings that can be used - are defined in the binding of the DMA client device. - Multiple DMA specifiers can be used to represent - alternatives and in this case the dma-names for those - DMA specifiers must be identical (see examples). - -Examples: - -1. A device with one DMA read channel, one DMA write channel: - - i2c1: i2c@1 { - ... - dmas = <&dma 2 /* read channel */ - &dma 3>; /* write channel */ - dma-names = "rx", "tx"; - ... - }; - -2. A single read-write channel with three alternative DMA controllers: - - dmas = <&dma1 5 - &dma2 7 - &dma3 2>; - dma-names = "rx-tx", "rx-tx", "rx-tx"; - -3. A device with three channels, one of which has two alternatives: - - dmas = <&dma1 2 /* read channel */ - &dma1 3 /* write channel */ - &dma2 0 /* error read */ - &dma3 0>; /* alternative error read */ - dma-names = "rx", "tx", "error", "error"; +This file has been moved to dma-controller.yaml. diff --git a/Documentation/devicetree/bindings/dma/nbpfaxi.txt b/Documentation/devicetree/bindings/dma/renesas,nbpfaxi.txt similarity index 100% rename from Documentation/devicetree/bindings/dma/nbpfaxi.txt rename to Documentation/devicetree/bindings/dma/renesas,nbpfaxi.txt diff --git a/Documentation/devicetree/bindings/dma/shdma.txt b/Documentation/devicetree/bindings/dma/renesas,shdma.txt similarity index 100% rename from Documentation/devicetree/bindings/dma/shdma.txt rename to Documentation/devicetree/bindings/dma/renesas,shdma.txt diff --git a/Documentation/devicetree/bindings/dma/sun4i-dma.txt b/Documentation/devicetree/bindings/dma/sun4i-dma.txt deleted file mode 100644 index 8ad556aca70b..000000000000 --- a/Documentation/devicetree/bindings/dma/sun4i-dma.txt +++ /dev/null @@ -1,45 +0,0 @@ -Allwinner A10 DMA Controller - -This driver follows the generic DMA bindings defined in dma.txt. - -Required properties: - -- compatible: Must be "allwinner,sun4i-a10-dma" -- reg: Should contain the registers base address and length -- interrupts: Should contain a reference to the interrupt used by this device -- clocks: Should contain a reference to the parent AHB clock -- #dma-cells : Should be 2, first cell denoting normal or dedicated dma, - second cell holding the request line number. - -Example: - dma: dma-controller@1c02000 { - compatible = "allwinner,sun4i-a10-dma"; - reg = <0x01c02000 0x1000>; - interrupts = <27>; - clocks = <&ahb_gates 6>; - #dma-cells = <2>; - }; - -Clients: - -DMA clients connected to the Allwinner A10 DMA controller must use the -format described in the dma.txt file, using a three-cell specifier for -each channel: a phandle plus two integer cells. -The three cells in order are: - -1. A phandle pointing to the DMA controller. -2. Whether it is using normal (0) or dedicated (1) channels -3. The port ID as specified in the datasheet - -Example: - spi2: spi@1c17000 { - compatible = "allwinner,sun4i-a10-spi"; - reg = <0x01c17000 0x1000>; - interrupts = <0 12 4>; - clocks = <&ahb_gates 22>, <&spi2_clk>; - clock-names = "ahb", "mod"; - dmas = <&dma 1 29>, <&dma 1 28>; - dma-names = "rx", "tx"; - #address-cells = <1>; - #size-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/dma/sun6i-dma.txt b/Documentation/devicetree/bindings/dma/sun6i-dma.txt deleted file mode 100644 index cae31f4e77ba..000000000000 --- a/Documentation/devicetree/bindings/dma/sun6i-dma.txt +++ /dev/null @@ -1,81 +0,0 @@ -Allwinner A31 DMA Controller - -This driver follows the generic DMA bindings defined in dma.txt. - -Required properties: - -- compatible: Must be one of - "allwinner,sun6i-a31-dma" - "allwinner,sun8i-a23-dma" - "allwinner,sun8i-a83t-dma" - "allwinner,sun8i-h3-dma" - "allwinner,sun8i-v3s-dma" -- reg: Should contain the registers base address and length -- interrupts: Should contain a reference to the interrupt used by this device -- clocks: Should contain a reference to the parent AHB clock -- resets: Should contain a reference to the reset controller asserting - this device in reset -- #dma-cells : Should be 1, a single cell holding a line request number - -Example: - dma: dma-controller@1c02000 { - compatible = "allwinner,sun6i-a31-dma"; - reg = <0x01c02000 0x1000>; - interrupts = <0 50 4>; - clocks = <&ahb1_gates 6>; - resets = <&ahb1_rst 6>; - #dma-cells = <1>; - }; - ------------------------------------------------------------------------------- -For A64 and H6 DMA controller: - -Required properties: -- compatible: Must be one of - "allwinner,sun50i-a64-dma" - "allwinner,sun50i-h6-dma" -- dma-channels: Number of DMA channels supported by the controller. - Refer to Documentation/devicetree/bindings/dma/dma.txt -- clocks: In addition to parent AHB clock, it should also contain mbus - clock (H6 only) -- clock-names: Should contain "bus" and "mbus" (H6 only) -- all properties above, i.e. reg, interrupts, clocks, resets and #dma-cells - -Optional properties: -- dma-requests: Number of DMA request signals supported by the controller. - Refer to Documentation/devicetree/bindings/dma/dma.txt - -Example: - dma: dma-controller@1c02000 { - compatible = "allwinner,sun50i-a64-dma"; - reg = <0x01c02000 0x1000>; - interrupts = ; - clocks = <&ccu CLK_BUS_DMA>; - dma-channels = <8>; - dma-requests = <27>; - resets = <&ccu RST_BUS_DMA>; - #dma-cells = <1>; - }; ------------------------------------------------------------------------------- - -Clients: - -DMA clients connected to the A31 DMA controller must use the format -described in the dma.txt file, using a two-cell specifier for each -channel: a phandle plus one integer cells. -The two cells in order are: - -1. A phandle pointing to the DMA controller. -2. The port ID as specified in the datasheet - -Example: -spi2: spi@1c6a000 { - compatible = "allwinner,sun6i-a31-spi"; - reg = <0x01c6a000 0x1000>; - interrupts = <0 67 4>; - clocks = <&ahb1_gates 22>, <&spi2_clk>; - clock-names = "ahb", "mod"; - dmas = <&dma 25>, <&dma 25>; - dma-names = "rx", "tx"; - resets = <&ahb1_rst 22>; -}; diff --git a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml new file mode 100644 index 000000000000..f04870d84542 --- /dev/null +++ b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dsp/fsl,dsp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8 DSP core + +maintainers: + - Daniel Baluta + +description: | + Some boards from i.MX8 family contain a DSP core used for + advanced pre- and post- audio processing. + +properties: + compatible: + enum: + - fsl,imx8qxp-dsp + + reg: + description: Should contain register location and length + + clocks: + items: + - description: ipg clock + - description: ocram clock + - description: core clock + + clock-names: + items: + - const: ipg + - const: ocram + - const: core + + power-domains: + description: + List of phandle and PM domain specifier as documented in + Documentation/devicetree/bindings/power/power_domain.txt + maxItems: 4 + + mboxes: + description: + List of <&phandle type channel> - 2 channels for TXDB, 2 channels for RXDB + (see mailbox/fsl,mu.txt) + maxItems: 4 + + mbox-names: + items: + - const: txdb0 + - const: txdb1 + - const: rxdb0 + - const: rxdb1 + + memory-region: + description: + phandle to a node describing reserved memory (System RAM memory) + used by DSP (see bindings/reserved-memory/reserved-memory.txt) + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - power-domains + - mboxes + - mbox-names + - memory-region + +examples: + - | + #include + #include + dsp@596e8000 { + compatible = "fsl,imx8qxp-dsp"; + reg = <0x596e8000 0x88000>; + clocks = <&adma_lpcg IMX_ADMA_LPCG_DSP_IPG_CLK>, + <&adma_lpcg IMX_ADMA_LPCG_OCRAM_IPG_CLK>, + <&adma_lpcg IMX_ADMA_LPCG_DSP_CORE_CLK>; + clock-names = "ipg", "ocram", "core"; + power-domains = <&pd IMX_SC_R_MU_13A>, + <&pd IMX_SC_R_MU_13B>, + <&pd IMX_SC_R_DSP>, + <&pd IMX_SC_R_DSP_RAM>; + mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1"; + mboxes = <&lsio_mu13 2 0>, <&lsio_mu13 2 1>, <&lsio_mu13 3 0>, <&lsio_mu13 3 1>; + memory-region = <&dsp_reserved>; + }; diff --git a/Documentation/devicetree/bindings/eeprom/at25.txt b/Documentation/devicetree/bindings/eeprom/at25.txt index b3bde97dc199..42577dd113dd 100644 --- a/Documentation/devicetree/bindings/eeprom/at25.txt +++ b/Documentation/devicetree/bindings/eeprom/at25.txt @@ -3,6 +3,7 @@ EEPROMs (SPI) compatible with Atmel at25. Required properties: - compatible : Should be ",", and generic value "atmel,at25". Example "," values: + "anvo,anv32e61w" "microchip,25lc040" "st,m95m02" "st,m95256" diff --git a/Documentation/devicetree/bindings/example-schema.yaml b/Documentation/devicetree/bindings/example-schema.yaml index 9175d67f355d..c43819c2783a 100644 --- a/Documentation/devicetree/bindings/example-schema.yaml +++ b/Documentation/devicetree/bindings/example-schema.yaml @@ -5,7 +5,7 @@ # All the top-level keys are standard json-schema keywords except for # 'maintainers' and 'select' -# $id is a unique idenifier based on the filename. There may or may not be a +# $id is a unique identifier based on the filename. There may or may not be a # file present at the URL. $id: "http://devicetree.org/schemas/example-schema.yaml#" # $schema is the meta-schema this schema should be validated with. diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt index 7f3d94ae81ff..208daaff0be4 100644 --- a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt +++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt @@ -72,5 +72,5 @@ codec: wm8280@0 { 1 2 1 /* MICDET2 MICBIAS2 GPIO=high */ >; - wlf,gpsw = <0>; + wlf,gpsw = ; }; diff --git a/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt b/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt index d592c21245f2..624bd76f468e 100644 --- a/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt +++ b/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt @@ -5,7 +5,9 @@ controlled using I2C and enables USB data, stereo and mono audio, video, microphone, and UART data to use a common connector port. Required properties: - - compatible : Must be "fcs,fsa9480" + - compatible : Must be one of + "fcs,fsa9480" + "fcs,fsa880" - reg : Specifies i2c slave address. Must be 0x25. - interrupts : Should contain one entry specifying interrupt signal of interrupt parent to which interrupt pin of the chip is connected. diff --git a/Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt b/Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt new file mode 100644 index 000000000000..338169dea7bb --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt @@ -0,0 +1,19 @@ +Turris Mox rWTM firmware driver + +Required properties: + - compatible : Should be "cznic,turris-mox-rwtm" + - mboxes : Must contain a reference to associated mailbox + +This device tree node should be used on Turris Mox, or potentially another A3700 +compatible device running the Mox's rWTM firmware in the secure processor (for +example it is possible to flash this firmware into EspressoBin). + +Example: + + firmware { + turris-mox-rwtm { + compatible = "cznic,turris-mox-rwtm"; + mboxes = <&rwtm 0>; + status = "okay"; + }; + }; diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt index 41f133a4e2fa..3f29ea04b5fe 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt @@ -9,14 +9,16 @@ Required properties: - compatible: must contain one of the following: * "qcom,scm-apq8064" * "qcom,scm-apq8084" + * "qcom,scm-ipq4019" * "qcom,scm-msm8660" * "qcom,scm-msm8916" * "qcom,scm-msm8960" * "qcom,scm-msm8974" * "qcom,scm-msm8996" * "qcom,scm-msm8998" - * "qcom,scm-ipq4019" + * "qcom,scm-sc7180" * "qcom,scm-sdm845" + * "qcom,scm-sm8150" and: * "qcom,scm" - clocks: Specifies clocks needed by the SCM interface, if any: diff --git a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt index 817a8d4bf903..5dd0ff0f7b4e 100644 --- a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt +++ b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt @@ -3,10 +3,7 @@ Altera FPGA To SDRAM Bridge Driver Required properties: - compatible : Should contain "altr,socfpga-fpga2sdram-bridge" -Optional properties: -- bridge-enable : 0 if driver should disable bridge at startup - 1 if driver should enable bridge at startup - Default is to leave bridge in current state. +See Documentation/devicetree/bindings/fpga/fpga-bridge.txt for generic bindings. Example: fpga_bridge3: fpga-bridge@ffc25080 { diff --git a/Documentation/devicetree/bindings/fpga/altera-freeze-bridge.txt b/Documentation/devicetree/bindings/fpga/altera-freeze-bridge.txt index f8e288c71b2d..8b26fbcff3c6 100644 --- a/Documentation/devicetree/bindings/fpga/altera-freeze-bridge.txt +++ b/Documentation/devicetree/bindings/fpga/altera-freeze-bridge.txt @@ -10,10 +10,7 @@ Required properties: - compatible : Should contain "altr,freeze-bridge-controller" - regs : base address and size for freeze bridge module -Optional properties: -- bridge-enable : 0 if driver should disable bridge at startup - 1 if driver should enable bridge at startup - Default is to leave bridge in current state. +See Documentation/devicetree/bindings/fpga/fpga-bridge.txt for generic bindings. Example: freeze-controller@100000450 { diff --git a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt index 6406f9337eeb..68cce3945b10 100644 --- a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt +++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt @@ -9,10 +9,7 @@ Required properties: - resets : Phandle and reset specifier for this bridge's reset - clocks : Clocks used by this module. -Optional properties: -- bridge-enable : 0 if driver should disable bridge at startup. - 1 if driver should enable bridge at startup. - Default is to leave bridge in its current state. +See Documentation/devicetree/bindings/fpga/fpga-bridge.txt for generic bindings. Example: fpga_bridge0: fpga-bridge@ff400000 { diff --git a/Documentation/devicetree/bindings/fpga/fpga-bridge.txt b/Documentation/devicetree/bindings/fpga/fpga-bridge.txt new file mode 100644 index 000000000000..72e06917288a --- /dev/null +++ b/Documentation/devicetree/bindings/fpga/fpga-bridge.txt @@ -0,0 +1,13 @@ +FPGA Bridge Device Tree Binding + +Optional properties: +- bridge-enable : 0 if driver should disable bridge at startup + 1 if driver should enable bridge at startup + Default is to leave bridge in current state. + +Example: + fpga_bridge3: fpga-bridge@ffc25080 { + compatible = "altr,socfpga-fpga2sdram-bridge"; + reg = <0xffc25080 0x4>; + bridge-enable = <0>; + }; diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt index 8dcfba926bc7..4284d293fa61 100644 --- a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt +++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt @@ -18,12 +18,8 @@ Required properties: - clocks : input clock to IP - clock-names : should contain "aclk" -Optional properties: -- bridge-enable : 0 if driver should disable bridge at startup - 1 if driver should enable bridge at startup - Default is to leave bridge in current state. - -See Documentation/devicetree/bindings/fpga/fpga-region.txt for generic bindings. +See Documentation/devicetree/bindings/fpga/fpga-region.txt and +Documentation/devicetree/bindings/fpga/fpga-bridge.txt for generic bindings. Example: fpga-bridge@100000450 { diff --git a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt index 7e9b586770b0..b2033fc3a71a 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt @@ -2,7 +2,8 @@ Aspeed GPIO controller Device Tree Bindings ------------------------------------------- Required properties: -- compatible : Either "aspeed,ast2400-gpio" or "aspeed,ast2500-gpio" +- compatible : Either "aspeed,ast2400-gpio", "aspeed,ast2500-gpio", + or "aspeed,ast2600-gpio". - #gpio-cells : Should be two - First cell is the GPIO line number @@ -17,7 +18,9 @@ Required properties: Optional properties: -- clocks : A phandle to the clock to use for debounce timings +- clocks : A phandle to the clock to use for debounce timings +- ngpios : Number of GPIOs controlled by this controller. Should be set + when there are multiple GPIO controllers on a SoC (ast2600). The gpio and interrupt properties are further described in their respective bindings documentation: diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt index bc6b4b62df83..cd91d61eac31 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt @@ -6,6 +6,7 @@ Required Properties: 66AK2E SoCs "ti,k2g-gpio", "ti,keystone-gpio": for 66AK2G "ti,am654-gpio", "ti,keystone-gpio": for TI K3 AM654 + "ti,j721e-gpio", "ti,keystone-gpio": for J721E SoCs - reg: Physical base address of the controller and the size of memory mapped registers. diff --git a/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt b/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt new file mode 100644 index 000000000000..410759de9f09 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt @@ -0,0 +1,18 @@ +Turris Mox Moxtet GPIO expander via Moxtet bus + +Required properties: + - compatible : Should be "cznic,moxtet-gpio". + - gpio-controller : Marks the device node as a GPIO controller. + - #gpio-cells : Should be two. For consumer use see gpio.txt. + +Other properties are required for a Moxtet bus device, please refer to +Documentation/devicetree/bindings/bus/moxtet.txt. + +Example: + + moxtet_sfp: gpio@0 { + compatible = "cznic,moxtet-gpio"; + gpio-controller; + #gpio-cells = <2>; + reg = <0>; + } diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt index 69d46162d0f5..cd28e932bf50 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt @@ -4,7 +4,7 @@ Required properties: - compatible : Should be "fsl,-gpio" The following s are known to be supported: mpc5121, mpc5125, mpc8349, mpc8572, mpc8610, pq3, qoriq, - ls1021a, ls1043a, ls2080a. + ls1021a, ls1043a, ls2080a, ls1028a, ls1088a. - reg : Address and length of the register set for the device - interrupts : Should be the port interrupt shared by all 32 pins. - #gpio-cells : Should be two. The first cell is the pin number and @@ -37,3 +37,17 @@ gpio0: gpio@2300000 { interrupt-controller; #interrupt-cells = <2>; }; + + +Example of gpio-controller node for a ls1028a/ls1088a SoC: + +gpio1: gpio@2300000 { + compatible = "fsl,ls1028a-gpio", "fsl,ls1088a-gpio", "fsl,qoriq-gpio"; + reg = <0x0 0x2300000 0x0 0x10000>; + interrupts = ; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + little-endian; +}; diff --git a/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt new file mode 100644 index 000000000000..d4d83916c09d --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt @@ -0,0 +1,45 @@ +Aspeed SGPIO controller Device Tree Bindings +-------------------------------------------- + +This SGPIO controller is for ASPEED AST2500 SoC, it supports up to 80 full +featured Serial GPIOs. Each of the Serial GPIO pins can be programmed to +support the following options: +- Support interrupt option for each input port and various interrupt + sensitivity option (level-high, level-low, edge-high, edge-low) +- Support reset tolerance option for each output port +- Directly connected to APB bus and its shift clock is from APB bus clock + divided by a programmable value. +- Co-work with external signal-chained TTL components (74LV165/74LV595) + +Required properties: + +- compatible : Should be one of + "aspeed,ast2400-sgpio", "aspeed,ast2500-sgpio" +- #gpio-cells : Should be 2, see gpio.txt +- reg : Address and length of the register set for the device +- gpio-controller : Marks the device node as a GPIO controller +- interrupts : Interrupt specifier, see interrupt-controller/interrupts.txt +- interrupt-controller : Mark the GPIO controller as an interrupt-controller +- ngpios : number of GPIO lines, see gpio.txt + (should be multiple of 8, up to 80 pins) +- clocks : A phandle to the APB clock for SGPM clock division +- bus-frequency : SGPM CLK frequency + +The sgpio and interrupt properties are further described in their respective +bindings documentation: + +- Documentation/devicetree/bindings/gpio/gpio.txt +- Documentation/devicetree/bindings/interrupt-controller/interrupts.txt + + Example: + sgpio: sgpio@1e780200 { + #gpio-cells = <2>; + compatible = "aspeed,ast2500-sgpio"; + gpio-controller; + interrupts = <40>; + reg = <0x1e780200 0x0100>; + clocks = <&syscon ASPEED_CLK_APB>; + interrupt-controller; + ngpios = <8>; + bus-frequency = <12000000>; + }; diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt deleted file mode 100644 index b8be9dbc68b4..000000000000 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt +++ /dev/null @@ -1,92 +0,0 @@ -ARM Mali Bifrost GPU -==================== - -Required properties: - -- compatible : - * Since Mali Bifrost GPU model/revision is fully discoverable by reading - some determined registers, must contain the following: - + "arm,mali-bifrost" - * which must be preceded by one of the following vendor specifics: - + "amlogic,meson-g12a-mali" - -- reg : Physical base address of the device and length of the register area. - -- interrupts : Contains the three IRQ lines required by Mali Bifrost devices, - in the following defined order. - -- interrupt-names : Contains the names of IRQ resources in this exact defined - order: "job", "mmu", "gpu". - -Optional properties: - -- clocks : Phandle to clock for the Mali Bifrost device. - -- mali-supply : Phandle to regulator for the Mali device. Refer to - Documentation/devicetree/bindings/regulator/regulator.txt for details. - -- operating-points-v2 : Refer to Documentation/devicetree/bindings/opp/opp.txt - for details. - -- resets : Phandle of the GPU reset line. - -Vendor-specific bindings ------------------------- - -The Mali GPU is integrated very differently from one SoC to -another. In order to accommodate those differences, you have the option -to specify one more vendor-specific compatible, among: - -- "amlogic,meson-g12a-mali" - Required properties: - - resets : Should contain phandles of : - + GPU reset line - + GPU APB glue reset line - -Example for a Mali-G31: - -gpu@ffa30000 { - compatible = "amlogic,meson-g12a-mali", "arm,mali-bifrost"; - reg = <0xffe40000 0x10000>; - interrupts = , - , - ; - interrupt-names = "job", "mmu", "gpu"; - clocks = <&clk CLKID_MALI>; - mali-supply = <&vdd_gpu>; - operating-points-v2 = <&gpu_opp_table>; - resets = <&reset RESET_DVALIN_CAPB3>, <&reset RESET_DVALIN>; -}; - -gpu_opp_table: opp_table0 { - compatible = "operating-points-v2"; - - opp@533000000 { - opp-hz = /bits/ 64 <533000000>; - opp-microvolt = <1250000>; - }; - opp@450000000 { - opp-hz = /bits/ 64 <450000000>; - opp-microvolt = <1150000>; - }; - opp@400000000 { - opp-hz = /bits/ 64 <400000000>; - opp-microvolt = <1125000>; - }; - opp@350000000 { - opp-hz = /bits/ 64 <350000000>; - opp-microvolt = <1075000>; - }; - opp@266000000 { - opp-hz = /bits/ 64 <266000000>; - opp-microvolt = <1025000>; - }; - opp@160000000 { - opp-hz = /bits/ 64 <160000000>; - opp-microvolt = <925000>; - }; - opp@100000000 { - opp-hz = /bits/ 64 <100000000>; - opp-microvolt = <912500>; - }; -}; diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml new file mode 100644 index 000000000000..5f1fd6d7ee0f --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -0,0 +1,116 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpu/arm,mali-bifrost.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Mali Bifrost GPU + +maintainers: + - Rob Herring + +properties: + $nodename: + pattern: '^gpu@[a-f0-9]+$' + + compatible: + items: + - enum: + - amlogic,meson-g12a-mali + - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable + + reg: + maxItems: 1 + + interrupts: + items: + - description: Job interrupt + - description: MMU interrupt + - description: GPU interrupt + + interrupt-names: + items: + - const: job + - const: mmu + - const: gpu + + clocks: + maxItems: 1 + + mali-supply: + maxItems: 1 + + operating-points-v2: true + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + +allOf: + - if: + properties: + compatible: + contains: + const: amlogic,meson-g12a-mali + then: + properties: + resets: + minItems: 2 + required: + - resets + +examples: + - | + #include + #include + + gpu@ffe40000 { + compatible = "amlogic,meson-g12a-mali", "arm,mali-bifrost"; + reg = <0xffe40000 0x10000>; + interrupts = , + , + ; + interrupt-names = "job", "mmu", "gpu"; + clocks = <&clk 1>; + mali-supply = <&vdd_gpu>; + operating-points-v2 = <&gpu_opp_table>; + resets = <&reset 0>, <&reset 1>; + }; + + gpu_opp_table: opp_table0 { + compatible = "operating-points-v2"; + + opp@533000000 { + opp-hz = /bits/ 64 <533000000>; + opp-microvolt = <1250000>; + }; + opp@450000000 { + opp-hz = /bits/ 64 <450000000>; + opp-microvolt = <1150000>; + }; + opp@400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <1125000>; + }; + opp@350000000 { + opp-hz = /bits/ 64 <350000000>; + opp-microvolt = <1075000>; + }; + opp@266000000 { + opp-hz = /bits/ 64 <266000000>; + opp-microvolt = <1025000>; + }; + opp@160000000 { + opp-hz = /bits/ 64 <160000000>; + opp-microvolt = <925000>; + }; + opp@100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <912500>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt deleted file mode 100644 index 9b298edec5b2..000000000000 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt +++ /dev/null @@ -1,119 +0,0 @@ -ARM Mali Midgard GPU -==================== - -Required properties: - -- compatible : - * Must contain one of the following: - + "arm,mali-t604" - + "arm,mali-t624" - + "arm,mali-t628" - + "arm,mali-t720" - + "arm,mali-t760" - + "arm,mali-t820" - + "arm,mali-t830" - + "arm,mali-t860" - + "arm,mali-t880" - * which must be preceded by one of the following vendor specifics: - + "allwinner,sun50i-h6-mali" - + "amlogic,meson-gxm-mali" - + "samsung,exynos5433-mali" - + "rockchip,rk3288-mali" - + "rockchip,rk3399-mali" - -- reg : Physical base address of the device and length of the register area. - -- interrupts : Contains the three IRQ lines required by Mali Midgard devices. - -- interrupt-names : Contains the names of IRQ resources in the order they were - provided in the interrupts property. Must contain: "job", "mmu", "gpu". - - -Optional properties: - -- clocks : Phandle to clock for the Mali Midgard device. - -- clock-names : Specify the names of the clocks specified in clocks - when multiple clocks are present. - * core: clock driving the GPU itself (When only one clock is present, - assume it's this clock.) - * bus: bus clock for the GPU - -- mali-supply : Phandle to regulator for the Mali device. Refer to - Documentation/devicetree/bindings/regulator/regulator.txt for details. - -- operating-points-v2 : Refer to Documentation/devicetree/bindings/opp/opp.txt - for details. - -- #cooling-cells: Refer to Documentation/devicetree/bindings/thermal/thermal.txt - for details. - -- resets : Phandle of the GPU reset line. - -Vendor-specific bindings ------------------------- - -The Mali GPU is integrated very differently from one SoC to -another. In order to accommodate those differences, you have the option -to specify one more vendor-specific compatible, among: - -- "allwinner,sun50i-h6-mali" - Required properties: - - clocks : phandles to core and bus clocks - - clock-names : must contain "core" and "bus" - - resets: phandle to GPU reset line - -- "amlogic,meson-gxm-mali" - Required properties: - - resets : Should contain phandles of : - + GPU reset line - + GPU APB glue reset line - -Example for a Mali-T760: - -gpu@ffa30000 { - compatible = "rockchip,rk3288-mali", "arm,mali-t760"; - reg = <0xffa30000 0x10000>; - interrupts = , - , - ; - interrupt-names = "job", "mmu", "gpu"; - clocks = <&cru ACLK_GPU>; - mali-supply = <&vdd_gpu>; - operating-points-v2 = <&gpu_opp_table>; - power-domains = <&power RK3288_PD_GPU>; - #cooling-cells = <2>; -}; - -gpu_opp_table: opp_table0 { - compatible = "operating-points-v2"; - - opp@533000000 { - opp-hz = /bits/ 64 <533000000>; - opp-microvolt = <1250000>; - }; - opp@450000000 { - opp-hz = /bits/ 64 <450000000>; - opp-microvolt = <1150000>; - }; - opp@400000000 { - opp-hz = /bits/ 64 <400000000>; - opp-microvolt = <1125000>; - }; - opp@350000000 { - opp-hz = /bits/ 64 <350000000>; - opp-microvolt = <1075000>; - }; - opp@266000000 { - opp-hz = /bits/ 64 <266000000>; - opp-microvolt = <1025000>; - }; - opp@160000000 { - opp-hz = /bits/ 64 <160000000>; - opp-microvolt = <925000>; - }; - opp@100000000 { - opp-hz = /bits/ 64 <100000000>; - opp-microvolt = <912500>; - }; -}; diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml new file mode 100644 index 000000000000..47bc1ac36426 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml @@ -0,0 +1,168 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpu/arm,mali-midgard.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Mali Midgard GPU + +maintainers: + - Rob Herring + +properties: + $nodename: + pattern: '^gpu@[a-f0-9]+$' + compatible: + oneOf: + - items: + - enum: + - allwinner,sun50i-h6-mali + - const: arm,mali-t720 + - items: + - enum: + - amlogic,meson-gxm-mali + - const: arm,mali-t820 + - items: + - enum: + - rockchip,rk3288-mali + - const: arm,mali-t760 + - items: + - enum: + - rockchip,rk3399-mali + - const: arm,mali-t860 + - items: + - enum: + - samsung,exynos5250-mali + - const: arm,mali-t604 + - items: + - enum: + - samsung,exynos5433-mali + - const: arm,mali-t760 + + # "arm,mali-t624" + # "arm,mali-t628" + # "arm,mali-t830" + # "arm,mali-t880" + + reg: + maxItems: 1 + + interrupts: + items: + - description: Job interrupt + - description: MMU interrupt + - description: GPU interrupt + + interrupt-names: + items: + - const: job + - const: mmu + - const: gpu + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + items: + - const: core + - const: bus + + mali-supply: + maxItems: 1 + + resets: + minItems: 1 + maxItems: 2 + + operating-points-v2: true + + "#cooling-cells": + const: 2 + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + +allOf: + - if: + properties: + compatible: + contains: + const: allwinner,sun50i-h6-mali + then: + properties: + clocks: + minItems: 2 + required: + - clock-names + - resets + - if: + properties: + compatible: + contains: + const: amlogic,meson-gxm-mali + then: + properties: + resets: + minItems: 2 + required: + - resets + +examples: + - | + #include + #include + + gpu@ffa30000 { + compatible = "rockchip,rk3288-mali", "arm,mali-t760"; + reg = <0xffa30000 0x10000>; + interrupts = , + , + ; + interrupt-names = "job", "mmu", "gpu"; + clocks = <&cru 0>; + mali-supply = <&vdd_gpu>; + operating-points-v2 = <&gpu_opp_table>; + power-domains = <&power 0>; + #cooling-cells = <2>; + }; + + gpu_opp_table: opp_table0 { + compatible = "operating-points-v2"; + + opp@533000000 { + opp-hz = /bits/ 64 <533000000>; + opp-microvolt = <1250000>; + }; + opp@450000000 { + opp-hz = /bits/ 64 <450000000>; + opp-microvolt = <1150000>; + }; + opp@400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <1125000>; + }; + opp@350000000 { + opp-hz = /bits/ 64 <350000000>; + opp-microvolt = <1075000>; + }; + opp@266000000 { + opp-hz = /bits/ 64 <266000000>; + opp-microvolt = <1025000>; + }; + opp@160000000 { + opp-hz = /bits/ 64 <160000000>; + opp-microvolt = <925000>; + }; + opp@100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <912500>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt deleted file mode 100644 index b352a6851a06..000000000000 --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt +++ /dev/null @@ -1,124 +0,0 @@ -ARM Mali Utgard GPU -=================== - -Required properties: - - compatible - * Must be one of the following: - + "arm,mali-300" - + "arm,mali-400" - + "arm,mali-450" - * And, optionally, one of the vendor specific compatible: - + allwinner,sun4i-a10-mali - + allwinner,sun7i-a20-mali - + allwinner,sun8i-h3-mali - + allwinner,sun50i-a64-mali - + allwinner,sun50i-h5-mali - + amlogic,meson8-mali - + amlogic,meson8b-mali - + amlogic,meson-gxbb-mali - + amlogic,meson-gxl-mali - + samsung,exynos4210-mali - + rockchip,rk3036-mali - + rockchip,rk3066-mali - + rockchip,rk3188-mali - + rockchip,rk3228-mali - + rockchip,rk3328-mali - + stericsson,db8500-mali - - - reg: Physical base address and length of the GPU registers - - - interrupts: an entry for each entry in interrupt-names. - See ../interrupt-controller/interrupts.txt for details. - - - interrupt-names: - * ppX: Pixel Processor X interrupt (X from 0 to 7) - * ppmmuX: Pixel Processor X MMU interrupt (X from 0 to 7) - * pp: Pixel Processor broadcast interrupt (mali-450 only) - * gp: Geometry Processor interrupt - * gpmmu: Geometry Processor MMU interrupt - - - clocks: an entry for each entry in clock-names - - clock-names: - * bus: bus clock for the GPU - * core: clock driving the GPU itself - -Optional properties: - - interrupt-names and interrupts: - * pmu: Power Management Unit interrupt, if implemented in hardware - - - memory-region: - Memory region to allocate from, as defined in - Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt - - - mali-supply: - Phandle to regulator for the Mali device, as defined in - Documentation/devicetree/bindings/regulator/regulator.txt for details. - - - operating-points-v2: - Operating Points for the GPU, as defined in - Documentation/devicetree/bindings/opp/opp.txt - - - power-domains: - A power domain consumer specifier as defined in - Documentation/devicetree/bindings/power/power_domain.txt - -Vendor-specific bindings ------------------------- - -The Mali GPU is integrated very differently from one SoC to -another. In order to accomodate those differences, you have the option -to specify one more vendor-specific compatible, among: - - - allwinner,sun4i-a10-mali - Required properties: - * resets: phandle to the reset line for the GPU - - - allwinner,sun7i-a20-mali - Required properties: - * resets: phandle to the reset line for the GPU - - - allwinner,sun50i-a64-mali - Required properties: - * resets: phandle to the reset line for the GPU - - - allwinner,sun50i-h5-mali - Required properties: - * resets: phandle to the reset line for the GPU - - - amlogic,meson8-mali and amlogic,meson8b-mali - Required properties: - * resets: phandle to the reset line for the GPU - - - Rockchip variants: - Required properties: - * resets: phandle to the reset line for the GPU - - - stericsson,db8500-mali - Required properties: - * interrupt-names and interrupts: - + combined: combined interrupt of all of the above lines - -Example: - -mali: gpu@1c40000 { - compatible = "allwinner,sun7i-a20-mali", "arm,mali-400"; - reg = <0x01c40000 0x10000>; - interrupts = , - , - , - , - , - , - ; - interrupt-names = "gp", - "gpmmu", - "pp0", - "ppmmu0", - "pp1", - "ppmmu1", - "pmu"; - clocks = <&ccu CLK_BUS_GPU>, <&ccu CLK_GPU>; - clock-names = "bus", "core"; - resets = <&ccu RST_BUS_GPU>; -}; - diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml new file mode 100644 index 000000000000..c5d93c5839d3 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml @@ -0,0 +1,168 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpu/arm,mali-utgard.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Mali Utgard GPU + +maintainers: + - Rob Herring + - Maxime Ripard + - Heiko Stuebner + +properties: + $nodename: + pattern: '^gpu@[a-f0-9]+$' + compatible: + oneOf: + - items: + - const: allwinner,sun8i-a23-mali + - const: allwinner,sun7i-a20-mali + - const: arm,mali-400 + - items: + - enum: + - allwinner,sun4i-a10-mali + - allwinner,sun7i-a20-mali + - allwinner,sun8i-h3-mali + - allwinner,sun50i-a64-mali + - rockchip,rk3036-mali + - rockchip,rk3066-mali + - rockchip,rk3188-mali + - rockchip,rk3228-mali + - samsung,exynos4210-mali + - stericsson,db8500-mali + - const: arm,mali-400 + - items: + - enum: + - allwinner,sun50i-h5-mali + - amlogic,meson8-mali + - amlogic,meson8b-mali + - amlogic,meson-gxbb-mali + - amlogic,meson-gxl-mali + - hisilicon,hi6220-mali + - rockchip,rk3328-mali + - const: arm,mali-450 + + # "arm,mali-300" + + reg: + maxItems: 1 + + interrupts: + minItems: 4 + maxItems: 20 + + interrupt-names: + allOf: + - additionalItems: true + minItems: 4 + maxItems: 20 + items: + # At least enforce the first 2 interrupts + - const: gp + - const: gpmmu + - items: + # Not ideal as any order and combination are allowed + enum: + - gp # Geometry Processor interrupt + - gpmmu # Geometry Processor MMU interrupt + - pp # Pixel Processor broadcast interrupt (mali-450 only) + - pp0 # Pixel Processor X interrupt (X from 0 to 7) + - ppmmu0 # Pixel Processor X MMU interrupt (X from 0 to 7) + - pp1 + - ppmmu1 + - pp2 + - ppmmu2 + - pp3 + - ppmmu3 + - pp4 + - ppmmu4 + - pp5 + - ppmmu5 + - pp6 + - ppmmu6 + - pp7 + - ppmmu7 + - pmu # Power Management Unit interrupt (optional) + - combined # stericsson,db8500-mali only + + clocks: + maxItems: 2 + + clock-names: + items: + - const: bus + - const: core + + memory-region: true + + mali-supply: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + operating-points-v2: true + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + +allOf: + - if: + properties: + compatible: + contains: + enum: + - allwinner,sun4i-a10-mali + - allwinner,sun7i-a20-mali + - allwinner,sun50i-a64-mali + - allwinner,sun50i-h5-mali + - amlogic,meson8-mali + - amlogic,meson8b-mali + - hisilicon,hi6220-mali + - rockchip,rk3036-mali + - rockchip,rk3066-mali + - rockchip,rk3188-mali + - rockchip,rk3228-mali + - rockchip,rk3328-mali + then: + required: + - resets + +examples: + - | + #include + #include + + mali: gpu@1c40000 { + compatible = "allwinner,sun7i-a20-mali", "arm,mali-400"; + reg = <0x01c40000 0x10000>; + interrupts = , + , + , + , + , + , + ; + interrupt-names = "gp", + "gpmmu", + "pp0", + "ppmmu0", + "pp1", + "ppmmu1", + "pmu"; + clocks = <&ccu 1>, <&ccu 2>; + clock-names = "bus", "core"; + resets = <&ccu 1>; + }; + +... diff --git a/Documentation/devicetree/bindings/hwmon/as370.txt b/Documentation/devicetree/bindings/hwmon/as370.txt new file mode 100644 index 000000000000..d102fe765124 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/as370.txt @@ -0,0 +1,11 @@ +Bindings for Synaptics AS370 PVT sensors + +Required properties: +- compatible : "syna,as370-hwmon" +- reg : address and length of the register set. + +Example: + hwmon@ea0810 { + compatible = "syna,as370-hwmon"; + reg = <0xea0810 0xc>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ibm,cffps1.txt b/Documentation/devicetree/bindings/hwmon/ibm,cffps1.txt index f68a0a68fc52..1036f65fb778 100644 --- a/Documentation/devicetree/bindings/hwmon/ibm,cffps1.txt +++ b/Documentation/devicetree/bindings/hwmon/ibm,cffps1.txt @@ -1,8 +1,10 @@ -Device-tree bindings for IBM Common Form Factor Power Supply Version 1 ----------------------------------------------------------------------- +Device-tree bindings for IBM Common Form Factor Power Supply Versions 1 and 2 +----------------------------------------------------------------------------- Required properties: - - compatible = "ibm,cffps1"; + - compatible : Must be one of the following: + "ibm,cffps1" + "ibm,cffps2" - reg = < I2C bus address >; : Address of the power supply on the I2C bus. diff --git a/Documentation/devicetree/bindings/hwmon/lm75.txt b/Documentation/devicetree/bindings/hwmon/lm75.txt index 586b5ed70be7..273616702c51 100644 --- a/Documentation/devicetree/bindings/hwmon/lm75.txt +++ b/Documentation/devicetree/bindings/hwmon/lm75.txt @@ -15,6 +15,7 @@ Required properties: "maxim,max31725", "maxim,max31726", "maxim,mcp980x", + "nxp,pct2075", "st,stds75", "st,stlm75", "microchip,tcn75", diff --git a/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt index e9de3756752b..c9a6587fe4bb 100644 --- a/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt @@ -1,7 +1,9 @@ Broadcom BCM2835 I2C controller Required properties: -- compatible : Should be "brcm,bcm2835-i2c". +- compatible : Should be one of: + "brcm,bcm2711-i2c" + "brcm,bcm2835-i2c" - reg: Should contain register location and length. - interrupts: Should contain interrupt. - clocks : The clock feeding the I2C controller. diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt index 2907dab56298..8b444b94e92f 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt @@ -42,7 +42,7 @@ Optional properties: This means that no unrelated I2C transactions are allowed on the parent I2C adapter for the complete multiplexed I2C transaction. The properties of mux-locked and parent-locked multiplexers are discussed - in more detail in Documentation/i2c/i2c-topology. + in more detail in Documentation/i2c/i2c-topology.rst. For each i2c child node, an I2C child bus will be created. They will be numbered based on their order in the device tree. diff --git a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml index 001f2b7abad0..c779000515d6 100644 --- a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml @@ -26,6 +26,9 @@ properties: - items: - const: allwinner,sun50i-a64-i2c - const: allwinner,sun6i-a31-i2c + - items: + - const: allwinner,sun50i-h6-i2c + - const: allwinner,sun6i-a31-i2c - const: marvell,mv64xxx-i2c - const: marvell,mv78230-i2c diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/renesas,i2c.txt similarity index 100% rename from Documentation/devicetree/bindings/i2c/i2c-rcar.txt rename to Documentation/devicetree/bindings/i2c/renesas,i2c.txt diff --git a/Documentation/devicetree/bindings/i2c/i2c-emev2.txt b/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.txt similarity index 100% rename from Documentation/devicetree/bindings/i2c/i2c-emev2.txt rename to Documentation/devicetree/bindings/i2c/renesas,iic-emev2.txt diff --git a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt b/Documentation/devicetree/bindings/i2c/renesas,iic.txt similarity index 100% rename from Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt rename to Documentation/devicetree/bindings/i2c/renesas,iic.txt diff --git a/Documentation/devicetree/bindings/i2c/i2c-riic.txt b/Documentation/devicetree/bindings/i2c/renesas,riic.txt similarity index 100% rename from Documentation/devicetree/bindings/i2c/i2c-riic.txt rename to Documentation/devicetree/bindings/i2c/renesas,riic.txt diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml new file mode 100644 index 000000000000..567a33a83dce --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml @@ -0,0 +1,120 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 Analog Devices Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bindings/iio/adc/adi,ad7192.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD7192 ADC device driver + +maintainers: + - Michael Hennerich + +description: | + Bindings for the Analog Devices AD7192 ADC device. Datasheet can be + found here: + https://www.analog.com/media/en/technical-documentation/data-sheets/AD7192.pdf + +properties: + compatible: + enum: + - adi,ad7190 + - adi,ad7192 + - adi,ad7193 + - adi,ad7195 + + reg: + maxItems: 1 + + spi-cpol: true + + spi-cpha: true + + clocks: + maxItems: 1 + description: phandle to the master clock (mclk) + + clock-names: + items: + - const: mclk + + interrupts: + maxItems: 1 + + dvdd-supply: + description: DVdd voltage supply + + avdd-supply: + description: AVdd voltage supply + + adi,rejection-60-Hz-enable: + description: | + This bit enables a notch at 60 Hz when the first notch of the sinc + filter is at 50 Hz. When REJ60 is set, a filter notch is placed at + 60 Hz when the sinc filter first notch is at 50 Hz. This allows + simultaneous 50 Hz/ 60 Hz rejection. + type: boolean + + adi,refin2-pins-enable: + description: | + External reference applied between the P1/REFIN2(+) and P0/REFIN2(−) pins. + type: boolean + + adi,buffer-enable: + description: | + Enables the buffer on the analog inputs. If cleared, the analog inputs + are unbuffered, lowering the power consumption of the device. If this + bit is set, the analog inputs are buffered, allowing the user to place + source impedances on the front end without contributing gain errors to + the system. + type: boolean + + adi,burnout-currents-enable: + description: | + When this bit is set to 1, the 500 nA current sources in the signal + path are enabled. When BURN = 0, the burnout currents are disabled. + The burnout currents can be enabled only when the buffer is active + and when chop is disabled. + type: boolean + + bipolar: + description: see Documentation/devicetree/bindings/iio/adc/adc.txt + type: boolean + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - dvdd-supply + - avdd-supply + - spi-cpol + - spi-cpha + +examples: + - | + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + adc@0 { + compatible = "adi,ad7192"; + reg = <0>; + spi-max-frequency = <1000000>; + spi-cpol; + spi-cpha; + clocks = <&ad7192_mclk>; + clock-names = "mclk"; + #interrupt-cells = <2>; + interrupts = <25 0x2>; + interrupt-parent = <&gpio>; + dvdd-supply = <&dvdd>; + avdd-supply = <&avdd>; + + adi,refin2-pins-enable; + adi,rejection-60-Hz-enable; + adi,buffer-enable; + adi,burnout-currents-enable; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt deleted file mode 100644 index d8652460198e..000000000000 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt +++ /dev/null @@ -1,66 +0,0 @@ -Analog Devices AD7606 Simultaneous Sampling ADC - -Required properties for the AD7606: - -- compatible: Must be one of - * "adi,ad7605-4" - * "adi,ad7606-8" - * "adi,ad7606-6" - * "adi,ad7606-4" - * "adi,ad7616" -- reg: SPI chip select number for the device -- spi-max-frequency: Max SPI frequency to use - see: Documentation/devicetree/bindings/spi/spi-bus.txt -- spi-cpha: See Documentation/devicetree/bindings/spi/spi-bus.txt -- avcc-supply: phandle to the Avcc power supply -- interrupts: IRQ line for the ADC - see: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt -- adi,conversion-start-gpios: must be the device tree identifier of the CONVST pin. - This logic input is used to initiate conversions on the analog - input channels. As the line is active high, it should be marked - GPIO_ACTIVE_HIGH. - -Optional properties: - -- reset-gpios: must be the device tree identifier of the RESET pin. If specified, - it will be asserted during driver probe. As the line is active high, - it should be marked GPIO_ACTIVE_HIGH. -- standby-gpios: must be the device tree identifier of the STBY pin. This pin is used - to place the AD7606 into one of two power-down modes, Standby mode or - Shutdown mode. As the line is active low, it should be marked - GPIO_ACTIVE_LOW. -- adi,first-data-gpios: must be the device tree identifier of the FRSTDATA pin. - The FRSTDATA output indicates when the first channel, V1, is - being read back on either the parallel, byte or serial interface. - As the line is active high, it should be marked GPIO_ACTIVE_HIGH. -- adi,range-gpios: must be the device tree identifier of the RANGE pin. The polarity on - this pin determines the input range of the analog input channels. If - this pin is tied to a logic high, the analog input range is ±10V for - all channels. If this pin is tied to a logic low, the analog input range - is ±5V for all channels. As the line is active high, it should be marked - GPIO_ACTIVE_HIGH. -- adi,oversampling-ratio-gpios: must be the device tree identifier of the over-sampling - mode pins. As the line is active high, it should be marked - GPIO_ACTIVE_HIGH. - -Example: - - adc@0 { - compatible = "adi,ad7606-8"; - reg = <0>; - spi-max-frequency = <1000000>; - spi-cpol; - - avcc-supply = <&adc_vref>; - - interrupts = <25 IRQ_TYPE_EDGE_FALLING>; - interrupt-parent = <&gpio>; - - adi,conversion-start-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>; - reset-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>; - adi,first-data-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>; - adi,oversampling-ratio-gpios = <&gpio 18 GPIO_ACTIVE_HIGH - &gpio 23 GPIO_ACTIVE_HIGH - &gpio 26 GPIO_ACTIVE_HIGH>; - standby-gpios = <&gpio 24 GPIO_ACTIVE_LOW>; - }; diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml new file mode 100644 index 000000000000..cc544fdc38be --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml @@ -0,0 +1,138 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/adi,ad7606.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD7606 Simultaneous Sampling ADC + +maintainers: + - Beniamin Bia + - Stefan Popa + +description: | + Analog Devices AD7606 Simultaneous Sampling ADC + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7606_7606-6_7606-4.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/AD7606B.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/AD7616.pdf + +properties: + compatible: + enum: + - adi,ad7605-4 + - adi,ad7606-8 + - adi,ad7606-6 + - adi,ad7606-4 + - adi,ad7606b + - adi,ad7616 + + reg: + maxItems: 1 + + spi-cpha: true + + avcc-supply: + description: + Phandle to the Avcc power supply + maxItems: 1 + + interrupts: + maxItems: 1 + + adi,conversion-start-gpios: + description: + Must be the device tree identifier of the CONVST pin. + This logic input is used to initiate conversions on the analog + input channels. As the line is active high, it should be marked + GPIO_ACTIVE_HIGH. + maxItems: 1 + + reset-gpios: + description: + Must be the device tree identifier of the RESET pin. If specified, + it will be asserted during driver probe. As the line is active high, + it should be marked GPIO_ACTIVE_HIGH. + maxItems: 1 + + standby-gpios: + description: + Must be the device tree identifier of the STBY pin. This pin is used + to place the AD7606 into one of two power-down modes, Standby mode or + Shutdown mode. As the line is active low, it should be marked + GPIO_ACTIVE_LOW. + maxItems: 1 + + adi,first-data-gpios: + description: + Must be the device tree identifier of the FRSTDATA pin. + The FRSTDATA output indicates when the first channel, V1, is + being read back on either the parallel, byte or serial interface. + As the line is active high, it should be marked GPIO_ACTIVE_HIGH. + maxItems: 1 + + adi,range-gpios: + description: + Must be the device tree identifier of the RANGE pin. The polarity on + this pin determines the input range of the analog input channels. If + this pin is tied to a logic high, the analog input range is ±10V for + all channels. If this pin is tied to a logic low, the analog input range + is ±5V for all channels. As the line is active high, it should be marked + GPIO_ACTIVE_HIGH. + maxItems: 1 + + adi,oversampling-ratio-gpios: + description: + Must be the device tree identifier of the over-sampling + mode pins. As the line is active high, it should be marked + GPIO_ACTIVE_HIGH. + maxItems: 1 + + adi,sw-mode: + description: + Software mode of operation, so far available only for ad7616 and ad7606b. + It is enabled when all three oversampling mode pins are connected to + high level. The device is configured by the corresponding registers. If the + adi,oversampling-ratio-gpios property is defined, then the driver will set the + oversampling gpios to high. Otherwise, it is assumed that the pins are hardwired + to VDD. + type: boolean + +required: + - compatible + - reg + - spi-cpha + - avcc-supply + - interrupts + - adi,conversion-start-gpios + +examples: + - | + #include + #include + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + adc@0 { + compatible = "adi,ad7606-8"; + reg = <0>; + spi-max-frequency = <1000000>; + spi-cpol; + spi-cpha; + + avcc-supply = <&adc_vref>; + + interrupts = <25 IRQ_TYPE_EDGE_FALLING>; + interrupt-parent = <&gpio>; + + adi,conversion-start-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>; + adi,first-data-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>; + adi,oversampling-ratio-gpios = <&gpio 18 GPIO_ACTIVE_HIGH + &gpio 23 GPIO_ACTIVE_HIGH + &gpio 26 GPIO_ACTIVE_HIGH>; + standby-gpios = <&gpio 24 GPIO_ACTIVE_LOW>; + adi,sw-mode; + }; + }; +... diff --git a/Documentation/devicetree/bindings/hwmon/ads1015.txt b/Documentation/devicetree/bindings/iio/adc/ads1015.txt similarity index 100% rename from Documentation/devicetree/bindings/hwmon/ads1015.txt rename to Documentation/devicetree/bindings/iio/adc/ads1015.txt diff --git a/Documentation/devicetree/bindings/iio/adc/allwinner,sun8i-a33-ths.yaml b/Documentation/devicetree/bindings/iio/adc/allwinner,sun8i-a33-ths.yaml new file mode 100644 index 000000000000..d74962c0f5ae --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/allwinner,sun8i-a33-ths.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/allwinner,sun8i-a33-ths.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A33 Thermal Sensor Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +properties: + "#io-channel-cells": + const: 0 + + "#thermal-sensor-cells": + const: 0 + + compatible: + const: allwinner,sun8i-a33-ths + + reg: + maxItems: 1 + +required: + - "#io-channel-cells" + - "#thermal-sensor-cells" + - compatible + - reg + +additionalProperties: false + +examples: + - | + ths: ths@1c25000 { + compatible = "allwinner,sun8i-a33-ths"; + reg = <0x01c25000 0x100>; + #thermal-sensor-cells = <0>; + #io-channel-cells = <0>; + }; + +... diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt index 93a0bd2efc05..4c0da8c74bb2 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt @@ -47,6 +47,12 @@ Required properties: Optional properties: - A pinctrl state named "default" for each ADC channel may be defined to set inX ADC pins in mode of operation for analog input on external pin. +- booster-supply: Phandle to the embedded booster regulator that can be used + to supply ADC analog input switches on stm32h7 and stm32mp1. +- vdd-supply: Phandle to the vdd input voltage. It can be used to supply ADC + analog input switches on stm32mp1. +- st,syscfg: Phandle to system configuration controller. It can be used to + control the analog circuitry on stm32mp1. Contents of a stm32 adc child node: ----------------------------------- diff --git a/Documentation/devicetree/bindings/iio/chemical/plantower,pms7003.txt b/Documentation/devicetree/bindings/iio/chemical/plantower,pms7003.txt deleted file mode 100644 index c52ea2126eaa..000000000000 --- a/Documentation/devicetree/bindings/iio/chemical/plantower,pms7003.txt +++ /dev/null @@ -1,26 +0,0 @@ -* Plantower PMS7003 particulate matter sensor - -Required properties: -- compatible: must one of: - "plantower,pms1003" - "plantower,pms3003" - "plantower,pms5003" - "plantower,pms6003" - "plantower,pms7003" - "plantower,pmsa003" -- vcc-supply: phandle to the regulator that provides power to the sensor - -Optional properties: -- plantower,set-gpios: phandle to the GPIO connected to the SET line -- reset-gpios: phandle to the GPIO connected to the RESET line - -Refer to serial/slave-device.txt for generic serial attached device bindings. - -Example: - -&uart0 { - air-pollution-sensor { - compatible = "plantower,pms7003"; - vcc-supply = <®_vcc5v0>; - }; -}; diff --git a/Documentation/devicetree/bindings/iio/chemical/plantower,pms7003.yaml b/Documentation/devicetree/bindings/iio/chemical/plantower,pms7003.yaml new file mode 100644 index 000000000000..a551d3101f93 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/chemical/plantower,pms7003.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/chemical/plantower,pms7003.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Plantower PMS7003 air pollution sensor + +maintainers: + - Tomasz Duszynski + +description: | + Air pollution sensor capable of measuring mass concentration of dust + particles. + +properties: + compatible: + enum: + - plantower,pms1003 + - plantower,pms3003 + - plantower,pms5003 + - plantower,pms6003 + - plantower,pms7003 + - plantower,pmsa003 + + vcc-supply: + description: regulator that provides power to the sensor + maxItems: 1 + + plantower,set-gpios: + description: GPIO connected to the SET line + maxItems: 1 + + reset-gpios: + description: GPIO connected to the RESET line + maxItems: 1 + +required: + - compatible + - vcc-supply + +examples: + - | + serial { + air-pollution-sensor { + compatible = "plantower,pms7003"; + vcc-supply = <®_vcc5v0>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml b/Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml new file mode 100644 index 000000000000..0c53009ba7d6 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/imu/adi,adis16460.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADIS16460 and similar IMUs + +maintainers: + - Dragos Bogdan + +description: | + Analog Devices ADIS16460 and similar IMUs + https://www.analog.com/media/en/technical-documentation/data-sheets/ADIS16460.pdf + +properties: + compatible: + enum: + - adi,adis16460 + + reg: + maxItems: 1 + + spi-cpha: true + + spi-cpol: true + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +examples: + - | + #include + #include + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + imu@0 { + compatible = "adi,adis16460"; + reg = <0>; + spi-max-frequency = <5000000>; + spi-cpol; + spi-cpha; + interrupt-parent = <&gpio0>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt b/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt index efec9ece034a..6d0c050d89fe 100644 --- a/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt +++ b/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt @@ -11,6 +11,9 @@ Required properties: "st,asm330lhh" "st,lsm6dsox" "st,lsm6dsr" + "st,lsm6ds3tr-c" + "st,ism330dhcx" + "st,lsm9ds1-imu" - reg: i2c address of the sensor / spi cs line Optional properties: diff --git a/Documentation/devicetree/bindings/iio/light/noa1305.yaml b/Documentation/devicetree/bindings/iio/light/noa1305.yaml new file mode 100644 index 000000000000..17e7f140b69b --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/noa1305.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/light/noa1305.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ON Semiconductor NOA1305 Ambient Light Sensor + +maintainers: + - Martyn Welch + +description: | + Ambient sensing with an i2c interface. + + https://www.onsemi.com/pub/Collateral/NOA1305-D.PDF + +properties: + compatible: + enum: + - onnn,noa1305 + + reg: + maxItems: 1 + + vin-supply: + description: Regulator that provides power to the sensor + +required: + - compatible + - reg + +examples: + - | + i2c { + + #address-cells = <1>; + #size-cells = <0>; + + light@39 { + compatible = "onnn,noa1305"; + reg = <0x39>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/light/isl29501.txt b/Documentation/devicetree/bindings/iio/light/renesas,isl29501.txt similarity index 100% rename from Documentation/devicetree/bindings/iio/light/isl29501.txt rename to Documentation/devicetree/bindings/iio/light/renesas,isl29501.txt diff --git a/Documentation/devicetree/bindings/iio/light/stk33xx.yaml b/Documentation/devicetree/bindings/iio/light/stk33xx.yaml new file mode 100644 index 000000000000..aae8a6d627c9 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/stk33xx.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/light/stk33xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: | + Sensortek STK33xx I2C Ambient Light and Proximity sensor + +maintainers: + - Jonathan Cameron + +description: | + Ambient light and proximity sensor over an i2c interface. + +properties: + compatible: + enum: + - sensortek,stk3310 + - sensortek,stk3311 + - sensortek,stk3335 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + +examples: + - | + #include + + i2c { + + #address-cells = <1>; + #size-cells = <0>; + + stk3310@48 { + compatible = "sensortek,stk3310"; + reg = <0x48>; + interrupt-parent = <&gpio1>; + interrupts = <5 IRQ_TYPE_LEVEL_LOW>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/mount-matrix.txt b/Documentation/devicetree/bindings/iio/mount-matrix.txt new file mode 100644 index 000000000000..c3344ab509a3 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/mount-matrix.txt @@ -0,0 +1,203 @@ +For discussion. Unclear are: +* is the definition of +/- values practical or counterintuitive? +* are the definitions unambiguous and easy to follow? +* are the examples correct? +* should we have HOWTO engineer a correct matrix for a new device (without comparing to a different one)? + +==== + + +Mounting matrix + +The mounting matrix is a device tree property used to orient any device +that produce three-dimensional data in relation to the world where it is +deployed. + +The purpose of the mounting matrix is to translate the sensor frame of +reference into the device frame of reference using a translation matrix as +defined in linear algebra. + +The typical usecase is that where a component has an internal representation +of the (x,y,z) triplets, such as different registers to read these coordinates, +and thus implying that the component should be mounted in a certain orientation +relative to some specific device frame of reference. + +For example a device with some kind of screen, where the user is supposed to +interact with the environment using an accelerometer, gyroscope or magnetometer +mounted on the same chassis as this screen, will likely take the screen as +reference to (x,y,z) orientation, with (x,y) corresponding to these axes on the +screen and (z) being depth, the axis perpendicular to the screen. + +For a screen you probably want (x) coordinates to go from negative on the left +to positive on the right, (y) from negative on the bottom to positive on top +and (z) depth to be negative under the screen and positive in front of it, +toward the face of the user. + +A sensor can be mounted in any angle along the axes relative to the frame of +reference. This means that the sensor may be flipped upside-down, left-right, +or tilted at any angle relative to the frame of reference. + +Another frame of reference is how the device with its sensor relates to the +external world, the environment where the device is deployed. Usually the data +from the sensor is used to figure out how the device is oriented with respect +to this world. When using the mounting matrix, the sensor and device orientation +becomes identical and we can focus on the data as it relates to the surrounding +world. + +Device-to-world examples for some three-dimensional sensor types: + +- Accelerometers have their world frame of reference toward the center of + gravity, usually to the core of the planet. A reading of the (x,y,z) values + from the sensor will give a projection of the gravity vector through the + device relative to the center of the planet, i.e. relative to its surface at + this point. Up and down in the world relative to the device frame of + reference can thus be determined. and users would likely expect a value of + 9.81 m/s^2 upwards along the (z) axis, i.e. out of the screen when the device + is held with its screen flat on the planets surface and 0 on the other axes, + as the gravity vector is projected 1:1 onto the sensors (z)-axis. + + If you tilt the device, the g vector virtually coming out of the display + is projected onto the (x,y) plane of the display panel. + + Example: + + ^ z: +g ^ z: > 0 + ! /! + ! x=y=0 / ! x: > 0 + +--------+ +--------+ + ! ! ! ! + +--------+ +--------+ + ! / + ! / + v v + center of center of + gravity gravity + + + If the device is tilted to the left, you get a positive x value. If you point + its top towards surface, you get a negative y axis. + + (---------) + ! ! y: -g + ! ! ^ + ! ! ! + ! ! + ! ! x: +g <- z: +g -> x: -g + ! 1 2 3 ! + ! 4 5 6 ! ! + ! 7 8 9 ! v + ! * 0 # ! y: +g + (---------) + + +- Magnetometers (compasses) have their world frame of reference relative to the + geomagnetic field. The system orientation vis-a-vis the world is defined with + respect to the local earth geomagnetic reference frame where (y) is in the + ground plane and positive towards magnetic North, (x) is in the ground plane, + perpendicular to the North axis and positive towards the East and (z) is + perpendicular to the ground plane and positive upwards. + + + ^^^ North: y > 0 + + (---------) + ! ! + ! ! + ! ! + ! ! > + ! ! > North: x > 0 + ! 1 2 3 ! > + ! 4 5 6 ! + ! 7 8 9 ! + ! * 0 # ! + (---------) + + Since the geomagnetic field is not uniform this definition fails if we come + closer to the poles. + + Sensors and driver can not and should not take care of this because there + are complex calculations and empirical data to be taken care of. We leave + this up to user space. + + The definition we take: + + If the device is placed at the equator and the top is pointing north, the + display is readable by a person standing upright on the earth surface, this + defines a positive y value. + + +- Gyroscopes detects the movement relative the device itself. The angular + velocity is defined as orthogonal to the plane of rotation, so if you put the + device on a flat surface and spin it around the z axis (such as rotating a + device with a screen lying flat on a table), you should get a negative value + along the (z) axis if rotated clockwise, and a positive value if rotated + counter-clockwise according to the right-hand rule. + + + (---------) y > 0 + ! ! v---\ + ! ! + ! ! + ! ! <--\ + ! ! ! z > 0 + ! 1 2 3 ! --/ + ! 4 5 6 ! + ! 7 8 9 ! + ! * 0 # ! + (---------) + + +So unless the sensor is ideally mounted, we need a means to indicate the +relative orientation of any given sensor of this type with respect to the +frame of reference. + +To achieve this, use the device tree property "mount-matrix" for the sensor. + +This supplies a 3x3 rotation matrix in the strict linear algebraic sense, +to orient the senor axes relative to a desired point of reference. This means +the resulting values from the sensor, after scaling to proper units, should be +multiplied by this matrix to give the proper vectors values in three-dimensional +space, relative to the device or world point of reference. + +For more information, consult: +https://en.wikipedia.org/wiki/Rotation_matrix + +The mounting matrix has the layout: + + (mxx, myx, mzx) + (mxy, myy, mzy) + (mxz, myz, mzz) + +Values are intended to be multiplied as: + + x' = mxx * x + myx * y + mzx * z + y' = mxy * x + myy * y + mzy * z + z' = mxz * x + myz * y + mzz * z + +It is represented as an array of strings containing the real values for +producing the transformation matrix. + +Examples: + +Identity matrix (nothing happens to the coordinates, which means the device was +mechanically mounted in an ideal way and we need no transformation): + +mount-matrix = "1", "0", "0", + "0", "1", "0", + "0", "0", "1"; + +The sensor is mounted 30 degrees (Pi/6 radians) tilted along the X axis, so we +compensate by performing a -30 degrees rotation around the X axis: + +mount-matrix = "1", "0", "0", + "0", "0.866", "0.5", + "0", "-0.5", "0.866"; + +The sensor is flipped 180 degrees (Pi radians) around the Z axis, i.e. mounted +upside-down: + +mount-matrix = "0.998", "0.054", "0", + "-0.054", "0.998", "0", + "0", "0", "1"; + +???: this does not match "180 degrees" - factors indicate ca. 3 degrees compensation diff --git a/Documentation/devicetree/bindings/iio/potentiometer/max5432.yaml b/Documentation/devicetree/bindings/iio/potentiometer/max5432.yaml new file mode 100644 index 000000000000..5082f919df2a --- /dev/null +++ b/Documentation/devicetree/bindings/iio/potentiometer/max5432.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/potentiometer/max5432.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim Integrated MAX5432-MAX5435 Digital Potentiometers + +maintainers: + - Martin Kaiser + +description: | + Maxim Integrated MAX5432-MAX5435 Digital Potentiometers connected via I2C + + Datasheet: + https://datasheets.maximintegrated.com/en/ds/MAX5432-MAX5435.pdf + +properties: + compatible: + enum: + - maxim,max5432 + - maxim,max5433 + - maxim,max5434 + - maxim,max5435 + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + max5434@28 { + compatible = "maxim,max5434"; + reg = <0x28>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml b/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml new file mode 100644 index 000000000000..b3bd8ef7fbd6 --- /dev/null +++ b/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/allwinner,sun4i-a10-lradc-keys.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A10 LRADC Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +properties: + compatible: + oneOf: + - const: allwinner,sun4i-a10-lradc-keys + - const: allwinner,sun8i-a83t-r-lradc + - items: + - const: allwinner,sun50i-a64-lradc + - const: allwinner,sun8i-a83t-r-lradc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + vref-supply: + description: + Regulator for the LRADC reference voltage + +patternProperties: + "^button-[0-9]+$": + type: object + properties: + label: + $ref: /schemas/types.yaml#/definitions/string + description: Descriptive name of the key + + linux,code: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Keycode to emit + + channel: + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - enum: [0, 1] + description: ADC Channel this key is attached to + + voltage: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Voltage in microvolts at LRADC input when this key is + pressed + + required: + - label + - linux,code + - channel + - voltage + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - vref-supply + +additionalProperties: false + +examples: + - | + lradc: lradc@1c22800 { + compatible = "allwinner,sun4i-a10-lradc-keys"; + reg = <0x01c22800 0x100>; + interrupts = <31>; + vref-supply = <®_vcc3v0>; + + button-191 { + label = "Volume Up"; + linux,code = <115>; + channel = <0>; + voltage = <191274>; + }; + + button-392 { + label = "Volume Down"; + linux,code = <114>; + channel = <0>; + voltage = <392644>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt deleted file mode 100644 index 507b737612ea..000000000000 --- a/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt +++ /dev/null @@ -1,65 +0,0 @@ -Allwinner sun4i low res adc attached tablet keys ------------------------------------------------- - -Required properties: - - compatible: should be one of the following string: - "allwinner,sun4i-a10-lradc-keys" - "allwinner,sun8i-a83t-r-lradc" - "allwinner,sun50i-a64-lradc", "allwinner,sun8i-a83t-r-lradc" - - reg: mmio address range of the chip - - interrupts: interrupt to which the chip is connected - - vref-supply: powersupply for the lradc reference voltage - -Each key is represented as a sub-node of the compatible mentioned above: - -Required subnode-properties: - - label: Descriptive name of the key. - - linux,code: Keycode to emit. - - channel: Channel this key is attached to, must be 0 or 1. - - voltage: Voltage in µV at lradc input when this key is pressed. - -Example: - -#include - - lradc: lradc@1c22800 { - compatible = "allwinner,sun4i-a10-lradc-keys"; - reg = <0x01c22800 0x100>; - interrupts = <31>; - vref-supply = <®_vcc3v0>; - - button@191 { - label = "Volume Up"; - linux,code = ; - channel = <0>; - voltage = <191274>; - }; - - button@392 { - label = "Volume Down"; - linux,code = ; - channel = <0>; - voltage = <392644>; - }; - - button@601 { - label = "Menu"; - linux,code = ; - channel = <0>; - voltage = <601151>; - }; - - button@795 { - label = "Enter"; - linux,code = ; - channel = <0>; - voltage = <795090>; - }; - - button@987 { - label = "Home"; - linux,code = ; - channel = <0>; - voltage = <987387>; - }; - }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt b/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt index 04413da51391..81f6bda97d3c 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt @@ -32,7 +32,6 @@ Optional properties: (ADS7846). ti,keep-vref-on set to keep vref on for differential measurements as well - ti,swap-xy swap x and y axis ti,settle-delay-usec Settling time of the analog signals; a function of Vcc and the capacitance on the X/Y drivers. If set to non-zero, @@ -51,13 +50,6 @@ Optional properties: in Ohms (u16). ti,x-min Minimum value on the X axis (u16). ti,y-min Minimum value on the Y axis (u16). - ti,x-max Maximum value on the X axis (u16). - ti,y-max Minimum value on the Y axis (u16). - ti,pressure-min Minimum reported pressure value - (threshold) - u16. - ti,pressure-max Maximum reported pressure value (u16). - ti,debounce-max Max number of additional readings per - sample (u16). ti,debounce-tol Tolerance used for filtering (u16). ti,debounce-rep Additional consecutive good readings required after the first two (u16). @@ -67,7 +59,28 @@ Optional properties: line is connected to. wakeup-source use any event on touchscreen as wakeup event. (Legacy property support: "linux,wakeup") + touchscreen-size-x General touchscreen binding, see [1]. + touchscreen-size-y General touchscreen binding, see [1]. + touchscreen-max-pressure General touchscreen binding, see [1]. + touchscreen-min-pressure General touchscreen binding, see [1]. + touchscreen-average-samples General touchscreen binding, see [1]. + touchscreen-inverted-x General touchscreen binding, see [1]. + touchscreen-inverted-y General touchscreen binding, see [1]. + touchscreen-swapped-x-y General touchscreen binding, see [1]. +[1] All general touchscreen properties are described in + Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt. + +Deprecated properties: + + ti,swap-xy swap x and y axis + ti,x-max Maximum value on the X axis (u16). + ti,y-max Maximum value on the Y axis (u16). + ti,pressure-min Minimum reported pressure value + (threshold) - u16. + ti,pressure-max Maximum reported pressure value (u16). + ti,debounce-max Max number of additional readings per + sample (u16). Example for a TSC2046 chip connected to an McSPI controller of an OMAP SoC:: diff --git a/Documentation/devicetree/bindings/input/touchscreen/bu21013.txt b/Documentation/devicetree/bindings/input/touchscreen/bu21013.txt index 56d835242af2..da4c9d8b99b1 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/bu21013.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/bu21013.txt @@ -2,11 +2,24 @@ Required properties: - compatible : "rohm,bu21013_tp" - - reg : I2C device address + - reg : I2C device address + - reset-gpios : GPIO pin enabling (selecting) chip (CS) + - interrupt-parent : the phandle for the gpio controller + - interrupts : (gpio) interrupt to which the chip is connected Optional properties: - - touch-gpio : GPIO pin registering a touch event + - touch-gpios : GPIO pin registering a touch event - -supply : Phandle to a regulator supply + - touchscreen-size-x : General touchscreen binding, see [1]. + - touchscreen-size-y : General touchscreen binding, see [1]. + - touchscreen-inverted-x : General touchscreen binding, see [1]. + - touchscreen-inverted-y : General touchscreen binding, see [1]. + - touchscreen-swapped-x-y : General touchscreen binding, see [1]. + +[1] All general touchscreen properties are described in + Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt. + +Deprecated properties: - rohm,touch-max-x : Maximum outward permitted limit in the X axis - rohm,touch-max-y : Maximum outward permitted limit in the Y axis - rohm,flip-x : Flip touch coordinates on the X axis @@ -18,11 +31,13 @@ Example: bu21013_tp@5c { compatible = "rohm,bu21013_tp"; reg = <0x5c>; - touch-gpio = <&gpio2 20 0x4>; + interrupt-parent = <&gpio2>; + interrupts <&20 IRQ_TYPE_LEVEL_LOW>; + touch-gpio = <&gpio2 20 GPIO_ACTIVE_LOW>; avdd-supply = <&ab8500_ldo_aux1_reg>; - rohm,touch-max-x = <384>; - rohm,touch-max-y = <704>; - rohm,flip-y; + touchscreen-size-x = <384>; + touchscreen-size-y = <704>; + touchscreen-inverted-y; }; }; diff --git a/Documentation/devicetree/bindings/interconnect/qcom,qcs404.txt b/Documentation/devicetree/bindings/interconnect/qcom,qcs404.txt new file mode 100644 index 000000000000..c07d89812b73 --- /dev/null +++ b/Documentation/devicetree/bindings/interconnect/qcom,qcs404.txt @@ -0,0 +1,45 @@ +Qualcomm QCS404 Network-On-Chip interconnect driver binding +----------------------------------------------------------- + +Required properties : +- compatible : shall contain only one of the following: + "qcom,qcs404-bimc" + "qcom,qcs404-pcnoc" + "qcom,qcs404-snoc" +- #interconnect-cells : should contain 1 + +reg : specifies the physical base address and size of registers +clocks : list of phandles and specifiers to all interconnect bus clocks +clock-names : clock names should include both "bus" and "bus_a" + +Example: + +soc { + ... + bimc: interconnect@400000 { + reg = <0x00400000 0x80000>; + compatible = "qcom,qcs404-bimc"; + #interconnect-cells = <1>; + clock-names = "bus", "bus_a"; + clocks = <&rpmcc RPM_SMD_BIMC_CLK>, + <&rpmcc RPM_SMD_BIMC_A_CLK>; + }; + + pnoc: interconnect@500000 { + reg = <0x00500000 0x15080>; + compatible = "qcom,qcs404-pcnoc"; + #interconnect-cells = <1>; + clock-names = "bus", "bus_a"; + clocks = <&rpmcc RPM_SMD_PNOC_CLK>, + <&rpmcc RPM_SMD_PNOC_A_CLK>; + }; + + snoc: interconnect@580000 { + reg = <0x00580000 0x23080>; + compatible = "qcom,qcs404-snoc"; + #interconnect-cells = <1>; + clock-names = "bus", "bus_a"; + clocks = <&rpmcc RPM_SMD_SNOC_CLK>, + <&rpmcc RPM_SMD_SNOC_A_CLK>; + }; +}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-a10-ic.yaml b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-a10-ic.yaml new file mode 100644 index 000000000000..23a202d24e43 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-a10-ic.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/allwinner,sun4i-a10-ic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A10 Interrupt Controller Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + "#interrupt-cells": + const: 1 + + compatible: + enum: + - allwinner,sun4i-a10-ic + - allwinner,suniv-f1c100s-ic + + reg: + maxItems: 1 + + interrupt-controller: true + +required: + - "#interrupt-cells" + - compatible + - reg + - interrupt-controller + +additionalProperties: false + +examples: + - | + intc: interrupt-controller@1c20400 { + compatible = "allwinner,sun4i-a10-ic"; + reg = <0x01c20400 0x400>; + interrupt-controller; + #interrupt-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt deleted file mode 100644 index 404352524c3a..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt +++ /dev/null @@ -1,20 +0,0 @@ -Allwinner Sunxi Interrupt Controller - -Required properties: - -- compatible : should be one of the following: - "allwinner,sun4i-a10-ic" - "allwinner,suniv-f1c100s-ic" -- reg : Specifies base physical address and size of the registers. -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt source. The value shall be 1. - -Example: - -intc: interrupt-controller { - compatible = "allwinner,sun4i-a10-ic"; - reg = <0x01c20400 0x400>; - interrupt-controller; - #interrupt-cells = <1>; -}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml new file mode 100644 index 000000000000..0eccf5551786 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A20 Non-Maskable Interrupt Controller Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + "#interrupt-cells": + const: 2 + description: + The first cell is the IRQ number, the second cell the trigger + type as defined in interrupt.txt in this directory. + + compatible: + oneOf: + - const: allwinner,sun6i-a31-r-intc + - const: allwinner,sun6i-a31-sc-nmi + deprecated: true + - const: allwinner,sun7i-a20-sc-nmi + - items: + - const: allwinner,sun8i-a83t-r-intc + - const: allwinner,sun6i-a31-r-intc + - const: allwinner,sun9i-a80-sc-nmi + - items: + - const: allwinner,sun50i-a64-r-intc + - const: allwinner,sun6i-a31-r-intc + - items: + - const: allwinner,sun50i-h6-r-intc + - const: allwinner,sun6i-a31-r-intc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-controller: true + +required: + - "#interrupt-cells" + - compatible + - reg + - interrupts + - interrupt-controller + +# FIXME: We should set it, but it would report all the generic +# properties as additional properties. +# additionalProperties: false + +examples: + - | + interrupt-controller@1c00030 { + compatible = "allwinner,sun7i-a20-sc-nmi"; + interrupt-controller; + #interrupt-cells = <2>; + reg = <0x01c00030 0x0c>; + interrupt-parent = <&gic>; + interrupts = <0 0 4>; + }; + +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt deleted file mode 100644 index 24beadf7ba83..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt +++ /dev/null @@ -1,29 +0,0 @@ -Allwinner Sunxi NMI Controller -============================== - -Required properties: - -- compatible : should be one of the following: - - "allwinner,sun7i-a20-sc-nmi" - - "allwinner,sun6i-a31-sc-nmi" (deprecated) - - "allwinner,sun6i-a31-r-intc" - - "allwinner,sun9i-a80-nmi" -- reg : Specifies base physical address and size of the registers. -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt source. The value shall be 2. The first cell is the IRQ number, the - second cell the trigger type as defined in interrupt.txt in this directory. -- interrupts: Specifies the interrupt line (NMI) which is handled by - the interrupt controller in the parent controller's notation. This value - shall be the NMI. - -Example: - -sc-nmi-intc@1c00030 { - compatible = "allwinner,sun7i-a20-sc-nmi"; - interrupt-controller; - #interrupt-cells = <2>; - reg = <0x01c00030 0x0c>; - interrupt-parent = <&gic>; - interrupts = <0 0 4>; -}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt index 7d531d5fff29..684bb1cd75ec 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt @@ -16,6 +16,7 @@ Required properties: "amlogic,meson-gxl-gpio-intc" for GXL SoCs (S905X, S912) "amlogic,meson-axg-gpio-intc" for AXG SoCs (A113D, A113X) "amlogic,meson-g12a-gpio-intc" for G12A SoCs (S905D2, S905X2, S905Y2) + "amlogic,meson-sm1-gpio-intc" for SM1 SoCs (S905D3, S905X3, S905Y3) - reg : Specifies base physical address and size of the registers. - interrupt-controller : Identifies the node as an interrupt controller. - #interrupt-cells : Specifies the number of cells needed to encode an diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml index c34df35a25fc..1fe147daca4c 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml @@ -44,11 +44,13 @@ properties: be at least 4. The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI - interrupts. Other values are reserved for future use. + interrupts, 2 for interrupts in the Extended SPI range, 3 for the + Extended PPI range. Other values are reserved for future use. The 2nd cell contains the interrupt number for the interrupt type. SPI interrupts are in the range [0-987]. PPI interrupts are in the - range [0-15]. + range [0-15]. Extented SPI interrupts are in the range [0-1023]. + Extended PPI interrupts are in the range [0-127]. The 3rd cell is the flags, encoded as follows: bits[3:0] trigger type and level flags. diff --git a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt index 8a3c40829899..4a3ee253f7f0 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt @@ -22,10 +22,10 @@ controller node. This property is inherited, so it may be specified in an interrupt client node or in any of its parent nodes. Interrupts listed in the "interrupts" property are always in reference to the node's interrupt parent. -The "interrupts-extended" property is a special form for use when a node needs -to reference multiple interrupt parents. Each entry in this property contains -both the parent phandle and the interrupt specifier. "interrupts-extended" -should only be used when a device has multiple interrupt parents. +The "interrupts-extended" property is a special form; useful when a node needs +to reference multiple interrupt parents or a different interrupt parent than +the inherited one. Each entry in this property contains both the parent phandle +and the interrupt specifier. Example: interrupts-extended = <&intc1 5 1>, <&intc2 1 0>; diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt index 0e312fea2a5d..84ced3f4179b 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt @@ -15,6 +15,7 @@ Required properties: "mediatek,mt7629-sysirq", "mediatek,mt6577-sysirq": for MT7629 "mediatek,mt6795-sysirq", "mediatek,mt6577-sysirq": for MT6795 "mediatek,mt6797-sysirq", "mediatek,mt6577-sysirq": for MT6797 + "mediatek,mt6779-sysirq", "mediatek,mt6577-sysirq": for MT6779 "mediatek,mt6765-sysirq", "mediatek,mt6577-sysirq": for MT6765 "mediatek,mt6755-sysirq", "mediatek,mt6577-sysirq": for MT6755 "mediatek,mt6592-sysirq", "mediatek,mt6577-sysirq": for MT6592 diff --git a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.txt index 09fc02b99845..a5c1db95b3ec 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.txt @@ -1,20 +1,30 @@ * ARC-HS Interrupt Distribution Unit - This optional 2nd level interrupt controller can be used in SMP configurations for - dynamic IRQ routing, load balancing of common/external IRQs towards core intc. + This optional 2nd level interrupt controller can be used in SMP configurations + for dynamic IRQ routing, load balancing of common/external IRQs towards core + intc. Properties: - compatible: "snps,archs-idu-intc" - interrupt-controller: This is an interrupt controller. -- #interrupt-cells: Must be <1>. +- #interrupt-cells: Must be <1> or <2>. - Value of the cell specifies the "common" IRQ from peripheral to IDU. Number N - of the particular interrupt line of IDU corresponds to the line N+24 of the - core interrupt controller. + Value of the first cell specifies the "common" IRQ from peripheral to IDU. + Number N of the particular interrupt line of IDU corresponds to the line N+24 + of the core interrupt controller. - intc accessed via the special ARC AUX register interface, hence "reg" property - is not specified. + The (optional) second cell specifies any of the following flags: + - bits[3:0] trigger type and level flags + 1 = low-to-high edge triggered + 2 = NOT SUPPORTED (high-to-low edge triggered) + 4 = active high level-sensitive <<< DEFAULT + 8 = NOT SUPPORTED (active low level-sensitive) + When no second cell is specified, the interrupt is assumed to be level + sensitive. + + The interrupt controller is accessed via the special ARC AUX register + interface, hence "reg" property is not specified. Example: core_intc: core-interrupt-controller { diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt index 6922db598def..ce59a505f5a4 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt @@ -11,10 +11,23 @@ ARM Short-Descriptor translation table format for address translation. | m4u (Multimedia Memory Management Unit) | + +--------+ + | | + gals0-rx gals1-rx (Global Async Local Sync rx) + | | + | | + gals0-tx gals1-tx (Global Async Local Sync tx) + | | Some SoCs may have GALS. + +--------+ + | SMI Common(Smart Multimedia Interface Common) | +----------------+------- | | + | gals-rx There may be GALS in some larbs. + | | + | | + | gals-tx | | SMI larb0 SMI larb1 ... SoCs have several SMI local arbiter(larb). (display) (vdec) @@ -36,6 +49,10 @@ each local arbiter. like display, video decode, and camera. And there are different ports in each larb. Take a example, There are many ports like MC, PP, VLD in the video decode local arbiter, all these ports are according to the video HW. + In some SoCs, there may be a GALS(Global Async Local Sync) module between +smi-common and m4u, and additional GALS module between smi-larb and +smi-common. GALS can been seen as a "asynchronous fifo" which could help +synchronize for the modules in different clock frequency. Required properties: - compatible : must be one of the following string: @@ -44,18 +61,25 @@ Required properties: "mediatek,mt7623-m4u", "mediatek,mt2701-m4u" for mt7623 which uses generation one m4u HW. "mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW. + "mediatek,mt8183-m4u" for mt8183 which uses generation two m4u HW. - reg : m4u register base and size. - interrupts : the interrupt of m4u. - clocks : must contain one entry for each clock-names. -- clock-names : must be "bclk", It is the block clock of m4u. +- clock-names : Only 1 optional clock: + - "bclk": the block clock of m4u. + Here is the list which require this "bclk": + - mt2701, mt2712, mt7623 and mt8173. + Note that m4u use the EMI clock which always has been enabled before kernel + if there is no this "bclk". - mediatek,larbs : List of phandle to the local arbiters in the current Socs. Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort according to the local arbiter index, like larb0, larb1, larb2... - iommu-cells : must be 1. This is the mtk_m4u_id according to the HW. Specifies the mtk_m4u_id as defined in dt-binding/memory/mt2701-larb-port.h for mt2701, mt7623 - dt-binding/memory/mt2712-larb-port.h for mt2712, and - dt-binding/memory/mt8173-larb-port.h for mt8173. + dt-binding/memory/mt2712-larb-port.h for mt2712, + dt-binding/memory/mt8173-larb-port.h for mt8173, and + dt-binding/memory/mt8183-larb-port.h for mt8183. Example: iommu: iommu@10205000 { diff --git a/Documentation/devicetree/bindings/leds/ams,as3645a.txt b/Documentation/devicetree/bindings/leds/ams,as3645a.txt index fdc40e354a64..4af2987b25e9 100644 --- a/Documentation/devicetree/bindings/leds/ams,as3645a.txt +++ b/Documentation/devicetree/bindings/leds/ams,as3645a.txt @@ -39,7 +39,9 @@ ams,input-max-microamp: Maximum flash controller input current. The Optional properties of the flash child node =========================================== -label : The label of the flash LED. +function : See Documentation/devicetree/bindings/leds/common.txt. +color : See Documentation/devicetree/bindings/leds/common.txt. +label : See Documentation/devicetree/bindings/leds/common.txt (deprecated). Required properties of the indicator child node (1) @@ -52,28 +54,32 @@ led-max-microamp: Maximum indicator current. The allowed values are Optional properties of the indicator child node =============================================== -label : The label of the indicator LED. +function : See Documentation/devicetree/bindings/leds/common.txt. +color : See Documentation/devicetree/bindings/leds/common.txt. +label : See Documentation/devicetree/bindings/leds/common.txt (deprecated). Example ======= +#include + as3645a@30 { - #address-cells: 1 - #size-cells: 0 + #address-cells = <1>; + #size-cells = <0>; reg = <0x30>; compatible = "ams,as3645a"; - flash@0 { + led@0 { reg = <0x0>; flash-timeout-us = <150000>; flash-max-microamp = <320000>; led-max-microamp = <60000>; ams,input-max-microamp = <1750000>; - label = "as3645a:flash"; + function = LED_FUNCTION_FLASH; }; - indicator@1 { + led@1 { reg = <0x1>; led-max-microamp = <10000>; - label = "as3645a:indicator"; + function = LED_FUNCTION_INDICATOR; }; }; diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt index 70876ac11367..9fa6f9795d50 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -10,14 +10,30 @@ can influence the way of the LED device initialization, the LED components have to be tightly coupled with the LED device binding. They are represented by child nodes of the parent LED device binding. + Optional properties for child nodes: - led-sources : List of device current outputs the LED is connected to. The outputs are identified by the numbers that must be defined in the LED device binding documentation. + +- function: LED functon. Use one of the LED_FUNCTION_* prefixed definitions + from the header include/dt-bindings/leds/common.h. + If there is no matching LED_FUNCTION available, add a new one. + +- color : Color of the LED. Use one of the LED_COLOR_ID_* prefixed definitions + from the header include/dt-bindings/leds/common.h. + If there is no matching LED_COLOR_ID available, add a new one. + +- function-enumerator: Integer to be used when more than one instance + of the same function is needed, differing only with + an ordinal number. + - label : The label for this LED. If omitted, the label is taken from the node name (excluding the unit address). It has to uniquely identify a device, i.e. no other LED class device can be assigned the same - label. + label. This property is deprecated - use 'function' and 'color' + properties instead. function-enumerator has no effect when this + property is present. - default-state : The initial state of the LED. Valid values are "on", "off", and "keep". If the LED is already on or off and the default-state property is @@ -99,29 +115,59 @@ Required properties for trigger source: * Examples -gpio-leds { +#include + +led-controller@0 { compatible = "gpio-leds"; - system-status { - label = "Status"; + led0 { + function = LED_FUNCTION_STATUS; linux,default-trigger = "heartbeat"; gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>; }; - usb { + led1 { + function = LED_FUNCTION_USB; gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>; trigger-sources = <&ohci_port1>, <&ehci_port1>; }; }; -max77693-led { +led-controller@0 { compatible = "maxim,max77693-led"; - camera-flash { - label = "Flash"; + led { + function = LED_FUNCTION_FLASH; + color = ; led-sources = <0>, <1>; led-max-microamp = <50000>; flash-max-microamp = <320000>; flash-max-timeout-us = <500000>; }; }; + +led-controller@30 { + compatible = "panasonic,an30259a"; + reg = <0x30>; + #address-cells = <1>; + #size-cells = <0>; + + led@1 { + reg = <1>; + linux,default-trigger = "heartbeat"; + function = LED_FUNCTION_INDICATOR; + function-enumerator = <1>; + }; + + led@2 { + reg = <2>; + function = LED_FUNCTION_INDICATOR; + function-enumerator = <2>; + }; + + led@3 { + reg = <3>; + function = LED_FUNCTION_INDICATOR; + function-enumerator = <3>; + }; +}; diff --git a/Documentation/devicetree/bindings/leds/leds-aat1290.txt b/Documentation/devicetree/bindings/leds/leds-aat1290.txt index 85c0c58617f6..62ed17ec075b 100644 --- a/Documentation/devicetree/bindings/leds/leds-aat1290.txt +++ b/Documentation/devicetree/bindings/leds/leds-aat1290.txt @@ -32,15 +32,18 @@ Required properties of the LED child node: formula: T = 8.82 * 10^9 * Ct. Optional properties of the LED child node: -- label : see Documentation/devicetree/bindings/leds/common.txt +- function : see Documentation/devicetree/bindings/leds/common.txt +- color : see Documentation/devicetree/bindings/leds/common.txt +- label : see Documentation/devicetree/bindings/leds/common.txt (deprecated) Example (by Ct = 220nF, Rset = 160kohm and exynos4412-trats2 board with a switch that allows for routing strobe signal either from the host or from the camera sensor): #include "exynos4412.dtsi" +#include -aat1290 { +led-controller { compatible = "skyworks,aat1290"; flen-gpios = <&gpj1 1 GPIO_ACTIVE_HIGH>; enset-gpios = <&gpj1 2 GPIO_ACTIVE_HIGH>; @@ -50,8 +53,9 @@ aat1290 { pinctrl-1 = <&camera_flash_host>; pinctrl-2 = <&camera_flash_isp>; - camera_flash: flash-led { - label = "aat1290-flash"; + camera_flash: led { + function = LED_FUNCTION_FLASH; + color = ; led-max-microamp = <520833>; flash-max-microamp = <1012500>; flash-max-timeout-us = <1940000>; diff --git a/Documentation/devicetree/bindings/leds/leds-an30259a.txt b/Documentation/devicetree/bindings/leds/leds-an30259a.txt index 6ffb861083c0..cbd833906b2b 100644 --- a/Documentation/devicetree/bindings/leds/leds-an30259a.txt +++ b/Documentation/devicetree/bindings/leds/leds-an30259a.txt @@ -15,10 +15,19 @@ Required sub-node properties: - reg: Pin that the LED is connected to. Must be 1, 2, or 3. Optional sub-node properties: - - label: see Documentation/devicetree/bindings/leds/common.txt - - linux,default-trigger: see Documentation/devicetree/bindings/leds/common.txt + - function : + see Documentation/devicetree/bindings/leds/common.txt + - color : + see Documentation/devicetree/bindings/leds/common.txt + - label : + see Documentation/devicetree/bindings/leds/common.txt (deprecated) + - linux,default-trigger : + see Documentation/devicetree/bindings/leds/common.txt Example: + +#include + led-controller@30 { compatible = "panasonic,an30259a"; reg = <0x30>; @@ -28,16 +37,19 @@ led-controller@30 { led@1 { reg = <1>; linux,default-trigger = "heartbeat"; - label = "red:indicator"; + function = LED_FUNCTION_INDICATOR; + color = ; }; led@2 { reg = <2>; - label = "green:indicator"; + function = LED_FUNCTION_INDICATOR; + color = ; }; led@3 { reg = <3>; - label = "blue:indicator"; + function = LED_FUNCTION_INDICATOR; + color = ; }; }; diff --git a/Documentation/devicetree/bindings/leds/leds-cr0014114.txt b/Documentation/devicetree/bindings/leds/leds-cr0014114.txt index 4255b19ad25c..f8de7516a39b 100644 --- a/Documentation/devicetree/bindings/leds/leds-cr0014114.txt +++ b/Documentation/devicetree/bindings/leds/leds-cr0014114.txt @@ -11,14 +11,20 @@ Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt apply. In particular, "reg" and "spi-max-frequency" properties must be given. LED sub-node properties: -- label : +- function : see Documentation/devicetree/bindings/leds/common.txt +- color : + see Documentation/devicetree/bindings/leds/common.txt +- label : + see Documentation/devicetree/bindings/leds/common.txt (deprecated) - linux,default-trigger : (optional) see Documentation/devicetree/bindings/leds/common.txt Example ------- +#include + led-controller@0 { compatible = "crane,cr0014114"; reg = <0>; @@ -28,27 +34,33 @@ led-controller@0 { led@0 { reg = <0>; - label = "red:coin"; + function = "coin"; + color = ; }; led@1 { reg = <1>; - label = "green:coin"; + function = "coin"; + color = ; }; led@2 { reg = <2>; - label = "blue:coin"; + function = "coin"; + color = ; }; led@3 { reg = <3>; - label = "red:bill"; + function = "bill"; + color = ; }; led@4 { reg = <4>; - label = "green:bill"; + function = "bill"; + color = ; }; led@5 { reg = <5>; - label = "blue:bill"; + function = "bill"; + color = ; }; ... }; diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt b/Documentation/devicetree/bindings/leds/leds-gpio.txt index a48dda268f81..d21281b63d38 100644 --- a/Documentation/devicetree/bindings/leds/leds-gpio.txt +++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt @@ -10,8 +10,12 @@ LED sub-node properties: - gpios : Should specify the LED's GPIO, see "gpios property" in Documentation/devicetree/bindings/gpio/gpio.txt. Active low LEDs should be indicated using flags in the GPIO specifier. -- label : (optional) +- function : (optional) see Documentation/devicetree/bindings/leds/common.txt +- color : (optional) + see Documentation/devicetree/bindings/leds/common.txt +- label : (optional) + see Documentation/devicetree/bindings/leds/common.txt (deprecated) - linux,default-trigger : (optional) see Documentation/devicetree/bindings/leds/common.txt - default-state: (optional) The initial state of the LED. @@ -27,30 +31,34 @@ LED sub-node properties: Examples: #include +#include leds { compatible = "gpio-leds"; - hdd { - label = "Disk Activity"; + led0 { gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>; linux,default-trigger = "disk-activity"; + function = LED_FUNCTION_DISK; }; - fault { + led1 { gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>; /* Keep LED on if BIOS detected hardware fault */ default-state = "keep"; + function = LED_FUNCTION_FAULT; }; }; run-control { compatible = "gpio-leds"; - red { + led0 { gpios = <&mpc8572 6 GPIO_ACTIVE_HIGH>; + color = ; default-state = "off"; }; - green { + led1 { gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>; + color = ; default-state = "on"; }; }; @@ -58,9 +66,10 @@ run-control { leds { compatible = "gpio-leds"; - charger-led { + led0 { gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; linux,default-trigger = "max8903-charger-charging"; retain-state-suspended; + function = LED_FUNCTION_CHARGE; }; }; diff --git a/Documentation/devicetree/bindings/leds/leds-lm3532.txt b/Documentation/devicetree/bindings/leds/leds-lm3532.txt index c087f85ddddc..53793213dd52 100644 --- a/Documentation/devicetree/bindings/leds/leds-lm3532.txt +++ b/Documentation/devicetree/bindings/leds/leds-lm3532.txt @@ -62,6 +62,9 @@ Optional LED child properties: - label : see Documentation/devicetree/bindings/leds/common.txt - linux,default-trigger : see Documentation/devicetree/bindings/leds/common.txt + - led-max-microamp : Defines the full scale current value for each control + bank. The range is from 5000uA-29800uA in increments + of 800uA. Example: led-controller@38 { @@ -85,6 +88,7 @@ led-controller@38 { reg = <0>; led-sources = <2>; ti,led-mode = <1>; + led-max-microamp = <21800>; label = ":backlight"; linux,default-trigger = "backlight"; }; diff --git a/Documentation/devicetree/bindings/leds/leds-lm3601x.txt b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt index a88b2c41e75b..095dafb6ec7f 100644 --- a/Documentation/devicetree/bindings/leds/leds-lm3601x.txt +++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt @@ -22,9 +22,14 @@ Required properties for flash LED child nodes: - led-max-microamp : Range from 2.4mA - 376mA Optional child properties: - - label : see Documentation/devicetree/bindings/leds/common.txt + - function : see Documentation/devicetree/bindings/leds/common.txt + - color : see Documentation/devicetree/bindings/leds/common.txt + - label : see Documentation/devicetree/bindings/leds/common.txt (deprecated) Example: + +#include + led-controller@64 { compatible = "ti,lm36010"; #address-cells = <1>; @@ -33,7 +38,8 @@ led-controller@64 { led@0 { reg = <1>; - label = "white:torch"; + function = LED_FUNCTION_TORCH; + color = ; led-max-microamp = <376000>; flash-max-microamp = <1500000>; flash-max-timeout-us = <1600000>; diff --git a/Documentation/devicetree/bindings/leds/leds-lm3692x.txt b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt index 08b352840bd7..4c2d923f8758 100644 --- a/Documentation/devicetree/bindings/leds/leds-lm3692x.txt +++ b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt @@ -26,12 +26,16 @@ Required child properties: 3 - Will enable the LED3 sync (LM36923 only) Optional child properties: - - label : see Documentation/devicetree/bindings/leds/common.txt + - function : see Documentation/devicetree/bindings/leds/common.txt + - color : see Documentation/devicetree/bindings/leds/common.txt + - label : see Documentation/devicetree/bindings/leds/common.txt (deprecated) - linux,default-trigger : see Documentation/devicetree/bindings/leds/common.txt Example: +#include + led-controller@36 { compatible = "ti,lm3692x"; reg = <0x36>; @@ -43,7 +47,8 @@ led-controller@36 { led@0 { reg = <0>; - label = "white:backlight_cluster"; + function = LED_FUNCTION_BACKLIGHT; + color = ; linux,default-trigger = "backlight"; }; } diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt b/Documentation/devicetree/bindings/leds/leds-lp8860.txt index 5f0e892ad759..9863220db4ba 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt +++ b/Documentation/devicetree/bindings/leds/leds-lp8860.txt @@ -20,12 +20,16 @@ Required child properties: - reg : 0 Optional child properties: - - label : see Documentation/devicetree/bindings/leds/common.txt + - function : see Documentation/devicetree/bindings/leds/common.txt + - color : see Documentation/devicetree/bindings/leds/common.txt + - label : see Documentation/devicetree/bindings/leds/common.txt (deprecated) - linux,default-trigger : see Documentation/devicetree/bindings/leds/common.txt Example: +#include + led-controller@2d { compatible = "ti,lp8860"; #address-cells = <1>; @@ -36,7 +40,8 @@ led-controller@2d { led@0 { reg = <0>; - label = "white:backlight"; + function = LED_FUNCTION_BACKLIGHT; + color = ; linux,default-trigger = "backlight"; }; } diff --git a/Documentation/devicetree/bindings/leds/leds-lt3593.txt b/Documentation/devicetree/bindings/leds/leds-lt3593.txt index 6b2cabc36c0c..24eccdaa6322 100644 --- a/Documentation/devicetree/bindings/leds/leds-lt3593.txt +++ b/Documentation/devicetree/bindings/leds/leds-lt3593.txt @@ -9,8 +9,10 @@ The hardware supports only one LED. The properties of this LED are configured in a sub-node in the device node. Optional sub-node properties: -- label: A label for the LED. If none is given, the LED will be - named "lt3595::". +- function: See Documentation/devicetree/bindings/leds/common.txt +- color: See Documentation/devicetree/bindings/leds/common.txt +- label: A label for the LED. If none is given, the LED will be + named "lt3595::" (deprecated) - linux,default-trigger: The default trigger for the LED. See Documentation/devicetree/bindings/leds/common.txt - default-state: The initial state of the LED. @@ -21,12 +23,15 @@ be handled by its own device node. Example: +#include + led-controller { compatible = "lltc,lt3593"; lltc,ctrl-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>; led { - label = "white:backlight"; + function = LED_FUNCTION_BACKLIGHT; + color = ; default-state = "on"; }; }; diff --git a/Documentation/devicetree/bindings/leds/leds-sc27xx-bltc.txt b/Documentation/devicetree/bindings/leds/leds-sc27xx-bltc.txt index dddf84f9c7ea..df2b4e1c492b 100644 --- a/Documentation/devicetree/bindings/leds/leds-sc27xx-bltc.txt +++ b/Documentation/devicetree/bindings/leds/leds-sc27xx-bltc.txt @@ -14,7 +14,9 @@ Required child properties: - reg: Port this LED is connected to. Optional child properties: -- label: See Documentation/devicetree/bindings/leds/common.txt. +- function: See Documentation/devicetree/bindings/leds/common.txt. +- color: See Documentation/devicetree/bindings/leds/common.txt. +- label: See Documentation/devicetree/bindings/leds/common.txt (deprecated). Examples: @@ -25,17 +27,17 @@ led-controller@200 { reg = <0x200>; led@0 { - label = "red"; + color = ; reg = <0x0>; }; led@1 { - label = "green"; + color = ; reg = <0x1>; }; led@2 { - label = "blue"; + color = ; reg = <0x2>; }; }; diff --git a/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml b/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml new file mode 100644 index 000000000000..319280563648 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 BayLibre, SAS +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/mailbox/amlogic,meson-gxbb-mhu.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic Meson Message-Handling-Unit Controller + +maintainers: + - Neil Armstrong + +description: | + The Amlogic's Meson SoCs Message-Handling-Unit (MHU) is a mailbox controller + that has 3 independent channels/links to communicate with remote processor(s). + MHU links are hardwired on a platform. A link raises interrupt for any + received data. However, there is no specified way of knowing if the sent + data has been read by the remote. This driver assumes the sender polls + STAT register and the remote clears it after having read the data. + +properties: + compatible: + enum: + - amlogic,meson-gxbb-mhu + + reg: + maxItems: 1 + + interrupts: + minItems: 3 + description: + Contains the interrupt information corresponding to each of the 3 links + of MHU. + + "#mbox-cells": + const: 1 + +required: + - compatible + - reg + - interrupts + - "#mbox-cells" + +examples: + - | + mailbox@c883c404 { + compatible = "amlogic,meson-gxbb-mhu"; + reg = <0xc883c404 0x4c>; + interrupts = <208>, <209>, <210>; + #mbox-cells = <1>; + }; + diff --git a/Documentation/devicetree/bindings/mailbox/meson-mhu.txt b/Documentation/devicetree/bindings/mailbox/meson-mhu.txt deleted file mode 100644 index a530310772b9..000000000000 --- a/Documentation/devicetree/bindings/mailbox/meson-mhu.txt +++ /dev/null @@ -1,34 +0,0 @@ -Amlogic Meson MHU Mailbox Driver -================================ - -The Amlogic's Meson SoCs Message-Handling-Unit (MHU) is a mailbox controller -that has 3 independent channels/links to communicate with remote processor(s). -MHU links are hardwired on a platform. A link raises interrupt for any -received data. However, there is no specified way of knowing if the sent -data has been read by the remote. This driver assumes the sender polls -STAT register and the remote clears it after having read the data. - -Mailbox Device Node: -==================== - -Required properties: --------------------- -- compatible: Shall be "amlogic,meson-gxbb-mhu" -- reg: Contains the mailbox register address range (base - address and length) -- #mbox-cells Shall be 1 - the index of the channel needed. -- interrupts: Contains the interrupt information corresponding to - each of the 2 links of MHU. - -Example: --------- - - mailbox: mailbox@c883c404 { - #mbox-cells = <1>; - compatible = "amlogic,meson-gxbb-mhu"; - reg = <0 0xc883c404 0 0x4c>; - interrupts = <0 208 IRQ_TYPE_EDGE_RISING>, - <0 209 IRQ_TYPE_EDGE_RISING>, - <0 210 IRQ_TYPE_EDGE_RISING>; - #mbox-cells = <1>; - }; diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index 7d72b21c9e94..7b13787ab13d 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -9,7 +9,7 @@ CMDQ driver uses mailbox framework for communication. Please refer to mailbox.txt for generic information about mailbox device-tree bindings. Required properties: -- compatible: Must be "mediatek,mt8173-gce" +- compatible: can be "mediatek,mt8173-gce" or "mediatek,mt8183-gce" - reg: Address range of the GCE unit - interrupts: The interrupt signal from the GCE block - clock: Clocks according to the common clock binding @@ -25,11 +25,19 @@ Required properties: Required properties for a client device: - mboxes: Client use mailbox to communicate with GCE, it should have this property and list of phandle, mailbox specifiers. -- mediatek,gce-subsys: u32, specify the sub-system id which is corresponding - to the register address. +Optional properties for a client device: +- mediatek,gce-client-reg: Specify the sub-system id which is corresponding + to the register address, it should have this property and list of phandle, + sub-system specifiers. + <&phandle subsys_number start_offset size> + phandle: Label name of a gce node. + subsys_number: specify the sub-system id which is corresponding + to the register address. + start_offset: the start offset of register address that GCE can access. + size: the total size of register address that GCE can access. -Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h'. Such as -sub-system ids, thread priority, event ids. +Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h' +or 'dt-binding/gce/mt8183-gce.h'. Such as sub-system ids, thread priority, event ids. Example: @@ -39,7 +47,6 @@ Example: interrupts = ; clocks = <&infracfg CLK_INFRA_GCE>; clock-names = "gce"; - thread-num = CMDQ_THR_MAX_COUNT; #mbox-cells = <3>; }; @@ -49,9 +56,9 @@ Example for a client device: compatible = "mediatek,mt8173-mmsys"; mboxes = <&gce 0 CMDQ_THR_PRIO_LOWEST 1>, <&gce 1 CMDQ_THR_PRIO_LOWEST 1>; - mediatek,gce-subsys = ; mutex-event-eof = ; - + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x3000 0x1000>, + <&gce SUBSYS_1401XXXX 0x2000 0x100>; ... }; diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt index 1232fc9fc709..0278482af65c 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt @@ -12,7 +12,10 @@ platforms. "qcom,msm8996-apcs-hmss-global" "qcom,msm8998-apcs-hmss-global" "qcom,qcs404-apcs-apps-global" + "qcom,sc7180-apss-shared" "qcom,sdm845-apss-shared" + "qcom,sm8150-apss-shared" + "qcom,ipq8074-apcs-apps-global" - reg: Usage: required diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml new file mode 100644 index 000000000000..27f38eed389e --- /dev/null +++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml @@ -0,0 +1,109 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/allwinner,sun4i-a10-csi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A10 CMOS Sensor Interface (CSI) Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +description: |- + The Allwinner A10 and later has a CMOS Sensor Interface to retrieve + frames from a parallel or BT656 sensor. + +properties: + compatible: + const: allwinner,sun7i-a20-csi0 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: The CSI interface clock + - description: The CSI module clock + - description: The CSI ISP clock + - description: The CSI DRAM clock + + clock-names: + items: + - const: bus + - const: mod + - const: isp + - const: ram + + resets: + maxItems: 1 + + # See ./video-interfaces.txt for details + port: + type: object + additionalProperties: false + + properties: + endpoint: + type: object + + properties: + bus-width: + enum: [8, 16] + + data-active: true + hsync-active: true + pclk-sample: true + remote-endpoint: true + vsync-active: true + + required: + - bus-width + - data-active + - hsync-active + - pclk-sample + - remote-endpoint + - vsync-active + + required: + - endpoint + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include + #include + #include + + csi0: csi@1c09000 { + compatible = "allwinner,sun7i-a20-csi0"; + reg = <0x01c09000 0x1000>; + interrupts = ; + clocks = <&ccu CLK_AHB_CSI0>, <&ccu CLK_CSI0>, + <&ccu CLK_CSI_SCLK>, <&ccu CLK_DRAM_CSI0>; + clock-names = "bus", "mod", "isp", "ram"; + resets = <&ccu RST_CSI0>; + + port { + csi_from_ov5640: endpoint { + remote-endpoint = <&ov5640_to_csi>; + bus-width = <8>; + hsync-active = <1>; /* Active high */ + vsync-active = <0>; /* Active low */ + data-active = <1>; /* Active high */ + pclk-sample = <1>; /* Rising */ + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml new file mode 100644 index 000000000000..98c1bdde9a86 --- /dev/null +++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/allwinner,sun4i-a10-ir.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A10 Infrared Controller Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +allOf: + - $ref: "rc.yaml#" + +properties: + compatible: + oneOf: + - const: allwinner,sun4i-a10-ir + - const: allwinner,sun5i-a13-ir + - items: + - const: allwinner,sun8i-a83t-ir + - const: allwinner,sun6i-a31-ir + - const: allwinner,sun6i-a31-ir + - items: + - const: allwinner,sun50i-a64-ir + - const: allwinner,sun6i-a31-ir + - items: + - const: allwinner,sun50i-h6-ir + - const: allwinner,sun6i-a31-ir + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Bus Clock + - description: Module Clock + + clock-names: + items: + - const: apb + - const: ir + + resets: + maxItems: 1 + + clock-frequency: + default: 8000000 + description: + IR Receiver clock frequency, in Hertz. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +# FIXME: We should set it, but it would report all the generic +# properties as additional properties. +# additionalProperties: false + +examples: + - | + ir0: ir@1c21800 { + compatible = "allwinner,sun4i-a10-ir"; + clocks = <&apb0_gates 6>, <&ir0_clk>; + clock-names = "apb", "ir"; + clock-frequency = <3000000>; + resets = <&apb0_rst 1>; + interrupts = <0 5 1>; + reg = <0x01C21800 0x40>; + linux,rc-map-name = "rc-rc6-mce"; + }; + +... diff --git a/Documentation/devicetree/bindings/media/amlogic,vdec.txt b/Documentation/devicetree/bindings/media/amlogic,vdec.txt index aabdd01bcf32..9b6aace86ca7 100644 --- a/Documentation/devicetree/bindings/media/amlogic,vdec.txt +++ b/Documentation/devicetree/bindings/media/amlogic,vdec.txt @@ -26,6 +26,7 @@ Required properties: - GXBB (S905) : "amlogic,gxbb-vdec" - GXL (S905X, S905D) : "amlogic,gxl-vdec" - GXM (S912) : "amlogic,gxm-vdec" + followed by the common "amlogic,gx-vdec" - reg: base address and size of he following memory-mapped regions : - dos - esparser @@ -47,8 +48,8 @@ Required properties: Example: -vdec: video-decoder@c8820000 { - compatible = "amlogic,gxbb-vdec"; +vdec: video-codec@c8820000 { + compatible = "amlogic,gxbb-vdec", "amlogic,gx-vdec"; reg = <0x0 0xc8820000 0x0 0x10000>, <0x0 0xc110a580 0x0 0xe4>; reg-names = "dos", "esparser"; diff --git a/Documentation/devicetree/bindings/media/cdns,csi2tx.txt b/Documentation/devicetree/bindings/media/cdns,csi2tx.txt index 459c6e332f52..751b9edf1247 100644 --- a/Documentation/devicetree/bindings/media/cdns,csi2tx.txt +++ b/Documentation/devicetree/bindings/media/cdns,csi2tx.txt @@ -5,7 +5,8 @@ The Cadence MIPI-CSI2 TX controller is a CSI-2 bridge supporting up to 4 CSI lanes in output, and up to 4 different pixel streams in input. Required properties: - - compatible: must be set to "cdns,csi2tx" + - compatible: must be set to "cdns,csi2tx" or "cdns,csi2tx-1.3" + for version 1.3 of the controller, "cdns,csi2tx-2.1" for v2.1 - reg: base address and size of the memory mapped region - clocks: phandles to the clocks driving the controller - clock-names: must contain: diff --git a/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt b/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt index 8ee7c7972ac7..c3c3479233c4 100644 --- a/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt +++ b/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt @@ -7,6 +7,9 @@ of that. These definitions are valid for both types of sensors. More detailed documentation can be found in Documentation/devicetree/bindings/media/video-interfaces.txt . +The device node should contain a "port" node which may contain one or more +endpoint nodes, in accordance with video interface bindings defined in +Documentation/devicetree/bindings/media/video-interfaces.txt . Mandatory properties -------------------- @@ -37,9 +40,7 @@ Optional properties Endpoint node mandatory properties ---------------------------------- -- clock-lanes: <0> - data-lanes: <1..n> -- remote-endpoint: A phandle to the bus receiver's endpoint node. Example @@ -48,7 +49,7 @@ Example &i2c2 { clock-frequency = <400000>; - smiapp_1: camera@10 { + camera-sensor@10 { compatible = "nokia,smia"; reg = <0x10>; reset-gpios = <&gpio3 20 0>; @@ -58,8 +59,7 @@ Example nokia,nvm-size = <512>; /* 8 * 64 */ link-frequencies = /bits/ 64 <199200000 210000000 499200000>; port { - smiapp_1_1: endpoint { - clock-lanes = <0>; + smiapp_ep: endpoint { data-lanes = <1 2>; remote-endpoint = <&csi2a_ep>; }; diff --git a/Documentation/devicetree/bindings/media/imx7-csi.txt b/Documentation/devicetree/bindings/media/imx7-csi.txt index 443aef07356e..d80ceefa0c00 100644 --- a/Documentation/devicetree/bindings/media/imx7-csi.txt +++ b/Documentation/devicetree/bindings/media/imx7-csi.txt @@ -9,7 +9,7 @@ to connect directly to external CMOS image sensors. Required properties: -- compatible : "fsl,imx7-csi"; +- compatible : "fsl,imx7-csi" or "fsl,imx6ul-csi"; - reg : base address and length of the register set for the device; - interrupts : should contain CSI interrupt; - clocks : list of clock specifiers, see diff --git a/Documentation/devicetree/bindings/media/meson-ao-cec.txt b/Documentation/devicetree/bindings/media/meson-ao-cec.txt index c67fc41d4aa2..ad92ee41c0dd 100644 --- a/Documentation/devicetree/bindings/media/meson-ao-cec.txt +++ b/Documentation/devicetree/bindings/media/meson-ao-cec.txt @@ -5,10 +5,12 @@ to handle communication between HDMI connected devices over the CEC bus. Required properties: - compatible : value should be following depending on the SoC : - For GXBB, GXL, GXM and G12A (AO_CEC_A module) : + For GXBB, GXL, GXM, G12A and SM1 (AO_CEC_A module) : "amlogic,meson-gx-ao-cec" For G12A (AO_CEC_B module) : "amlogic,meson-g12a-ao-cec" + For SM1 (AO_CEC_B module) : + "amlogic,meson-sm1-ao-cec" - reg : Physical base address of the IP registers and length of memory mapped region. @@ -16,9 +18,9 @@ Required properties: - interrupts : AO-CEC interrupt number to the CPU. - clocks : from common clock binding: handle to AO-CEC clock. - clock-names : from common clock binding, must contain : - For GXBB, GXL, GXM and G12A (AO_CEC_A module) : + For GXBB, GXL, GXM, G12A and SM1 (AO_CEC_A module) : - "core" - For G12A (AO_CEC_B module) : + For G12A, SM1 (AO_CEC_B module) : - "oscin" corresponding to entry in the clocks property. - hdmi-phandle: phandle to the HDMI controller diff --git a/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt b/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt index 7302e949e662..602169b8aa19 100644 --- a/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt +++ b/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt @@ -35,6 +35,7 @@ Optional properties: - resets : Must contain an entry for each entry in reset-names. - reset-names : Must include the following entries: - mc +- iommus: Must contain phandle to the IOMMU device node. Example: @@ -59,4 +60,5 @@ video-codec@6001a000 { clocks = <&tegra_car TEGRA20_CLK_VDE>; reset-names = "vde", "mc"; resets = <&tegra_car 61>, <&mc TEGRA20_MC_RESET_VDE>; + iommus = <&mc TEGRA_SWGROUP_VDE>; }; diff --git a/Documentation/devicetree/bindings/media/rc.txt b/Documentation/devicetree/bindings/media/rc.txt index d3e7a012bfda..be629f7fa77e 100644 --- a/Documentation/devicetree/bindings/media/rc.txt +++ b/Documentation/devicetree/bindings/media/rc.txt @@ -1,117 +1 @@ -The following properties are common to the infrared remote controllers: - -- linux,rc-map-name: string, specifies the scancode/key mapping table - defined in-kernel for the remote controller. Support values are: - * "rc-adstech-dvb-t-pci" - * "rc-alink-dtu-m" - * "rc-anysee" - * "rc-apac-viewcomp" - * "rc-asus-pc39" - * "rc-asus-ps3-100" - * "rc-ati-tv-wonder-hd-600" - * "rc-ati-x10" - * "rc-avermedia-a16d" - * "rc-avermedia-cardbus" - * "rc-avermedia-dvbt" - * "rc-avermedia-m135a" - * "rc-avermedia-m733a-rm-k6" - * "rc-avermedia-rm-ks" - * "rc-avermedia" - * "rc-avertv-303" - * "rc-azurewave-ad-tu700" - * "rc-behold-columbus" - * "rc-behold" - * "rc-budget-ci-old" - * "rc-cec" - * "rc-cinergy-1400" - * "rc-cinergy" - * "rc-delock-61959" - * "rc-dib0700-nec" - * "rc-dib0700-rc5" - * "rc-digitalnow-tinytwin" - * "rc-digittrade" - * "rc-dm1105-nec" - * "rc-dntv-live-dvbt-pro" - * "rc-dntv-live-dvb-t" - * "rc-dtt200u" - * "rc-dvbsky" - * "rc-empty" - * "rc-em-terratec" - * "rc-encore-enltv2" - * "rc-encore-enltv-fm53" - * "rc-encore-enltv" - * "rc-evga-indtube" - * "rc-eztv" - * "rc-flydvb" - * "rc-flyvideo" - * "rc-fusionhdtv-mce" - * "rc-gadmei-rm008z" - * "rc-geekbox" - * "rc-genius-tvgo-a11mce" - * "rc-gotview7135" - * "rc-hauppauge" - * "rc-imon-mce" - * "rc-imon-pad" - * "rc-iodata-bctv7e" - * "rc-it913x-v1" - * "rc-it913x-v2" - * "rc-kaiomy" - * "rc-kworld-315u" - * "rc-kworld-pc150u" - * "rc-kworld-plus-tv-analog" - * "rc-leadtek-y04g0051" - * "rc-lirc" - * "rc-lme2510" - * "rc-manli" - * "rc-medion-x10" - * "rc-medion-x10-digitainer" - * "rc-medion-x10-or2x" - * "rc-msi-digivox-ii" - * "rc-msi-digivox-iii" - * "rc-msi-tvanywhere-plus" - * "rc-msi-tvanywhere" - * "rc-nebula" - * "rc-nec-terratec-cinergy-xs" - * "rc-norwood" - * "rc-npgtech" - * "rc-pctv-sedna" - * "rc-pinnacle-color" - * "rc-pinnacle-grey" - * "rc-pinnacle-pctv-hd" - * "rc-pixelview-new" - * "rc-pixelview" - * "rc-pixelview-002t" - * "rc-pixelview-mk12" - * "rc-powercolor-real-angel" - * "rc-proteus-2309" - * "rc-purpletv" - * "rc-pv951" - * "rc-hauppauge" - * "rc-rc5-tv" - * "rc-rc6-mce" - * "rc-real-audio-220-32-keys" - * "rc-reddo" - * "rc-snapstream-firefly" - * "rc-streamzap" - * "rc-tbs-nec" - * "rc-technisat-ts35" - * "rc-technisat-usb2" - * "rc-terratec-cinergy-c-pci" - * "rc-terratec-cinergy-s2-hd" - * "rc-terratec-cinergy-xs" - * "rc-terratec-slim" - * "rc-terratec-slim-2" - * "rc-tevii-nec" - * "rc-tivo" - * "rc-total-media-in-hand" - * "rc-total-media-in-hand-02" - * "rc-trekstor" - * "rc-tt-1500" - * "rc-twinhan-dtv-cab-ci" - * "rc-twinhan1027" - * "rc-videomate-k100" - * "rc-videomate-s350" - * "rc-videomate-tv-pvr" - * "rc-winfast" - * "rc-winfast-usbii-deluxe" - * "rc-su3000" +This file has been moved to rc.yaml. diff --git a/Documentation/devicetree/bindings/media/rc.yaml b/Documentation/devicetree/bindings/media/rc.yaml new file mode 100644 index 000000000000..9054555e6608 --- /dev/null +++ b/Documentation/devicetree/bindings/media/rc.yaml @@ -0,0 +1,144 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/rc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic Infrared Remote Controller Device Tree Bindings + +maintainers: + - Mauro Carvalho Chehab + - Sean Young + +properties: + $nodename: + pattern: "^ir(@[a-f0-9]+)?$" + + linux,rc-map-name: + description: + Specifies the scancode/key mapping table defined in-kernel for + the remote controller. + allOf: + - $ref: '/schemas/types.yaml#/definitions/string' + - enum: + - rc-adstech-dvb-t-pci + - rc-alink-dtu-m + - rc-anysee + - rc-apac-viewcomp + - rc-astrometa-t2hybrid + - rc-asus-pc39 + - rc-asus-ps3-100 + - rc-ati-tv-wonder-hd-600 + - rc-ati-x10 + - rc-avermedia + - rc-avermedia-a16d + - rc-avermedia-cardbus + - rc-avermedia-dvbt + - rc-avermedia-m135a + - rc-avermedia-m733a-rm-k6 + - rc-avermedia-rm-ks + - rc-avertv-303 + - rc-azurewave-ad-tu700 + - rc-behold + - rc-behold-columbus + - rc-budget-ci-old + - rc-cec + - rc-cinergy + - rc-cinergy-1400 + - rc-d680-dmb + - rc-delock-61959 + - rc-dib0700-nec + - rc-dib0700-rc5 + - rc-digitalnow-tinytwin + - rc-digittrade + - rc-dm1105-nec + - rc-dntv-live-dvb-t + - rc-dntv-live-dvbt-pro + - rc-dtt200u + - rc-dvbsky + - rc-dvico-mce + - rc-dvico-portable + - rc-em-terratec + - rc-empty + - rc-encore-enltv + - rc-encore-enltv-fm53 + - rc-encore-enltv2 + - rc-evga-indtube + - rc-eztv + - rc-flydvb + - rc-flyvideo + - rc-fusionhdtv-mce + - rc-gadmei-rm008z + - rc-geekbox + - rc-genius-tvgo-a11mce + - rc-gotview7135 + - rc-hauppauge + - rc-hisi-poplar + - rc-hisi-tv-demo + - rc-imon-mce + - rc-imon-pad + - rc-imon-rsc + - rc-iodata-bctv7e + - rc-it913x-v1 + - rc-it913x-v2 + - rc-kaiomy + - rc-kworld-315u + - rc-kworld-pc150u + - rc-kworld-plus-tv-analog + - rc-leadtek-y04g0051 + - rc-lme2510 + - rc-manli + - rc-medion-x10 + - rc-medion-x10-digitainer + - rc-medion-x10-or2x + - rc-msi-digivox-ii + - rc-msi-digivox-iii + - rc-msi-tvanywhere + - rc-msi-tvanywhere-plus + - rc-nebula + - rc-nec-terratec-cinergy-xs + - rc-norwood + - rc-npgtech + - rc-pctv-sedna + - rc-pinnacle-color + - rc-pinnacle-grey + - rc-pinnacle-pctv-hd + - rc-pixelview + - rc-pixelview-002t + - rc-pixelview-mk12 + - rc-pixelview-new + - rc-powercolor-real-angel + - rc-proteus-2309 + - rc-purpletv + - rc-pv951 + - rc-rc5-tv + - rc-rc6-mce + - rc-real-audio-220-32-keys + - rc-reddo + - rc-snapstream-firefly + - rc-streamzap + - rc-su3000 + - rc-tango + - rc-tbs-nec + - rc-technisat-ts35 + - rc-technisat-usb2 + - rc-terratec-cinergy-c-pci + - rc-terratec-cinergy-s2-hd + - rc-terratec-cinergy-xs + - rc-terratec-slim + - rc-terratec-slim-2 + - rc-tevii-nec + - rc-tivo + - rc-total-media-in-hand + - rc-total-media-in-hand-02 + - rc-trekstor + - rc-tt-1500 + - rc-twinhan-dtv-cab-ci + - rc-twinhan1027 + - rc-videomate-k100 + - rc-videomate-s350 + - rc-videomate-tv-pvr + - rc-winfast + - rc-winfast-usbii-deluxe + - rc-xbox-dvd + - rc-zx-irdec diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt b/Documentation/devicetree/bindings/media/renesas,csi2.txt similarity index 100% rename from Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt rename to Documentation/devicetree/bindings/media/renesas,csi2.txt diff --git a/Documentation/devicetree/bindings/media/rcar_imr.txt b/Documentation/devicetree/bindings/media/renesas,imr.txt similarity index 100% rename from Documentation/devicetree/bindings/media/rcar_imr.txt rename to Documentation/devicetree/bindings/media/renesas,imr.txt diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/renesas,vin.txt similarity index 100% rename from Documentation/devicetree/bindings/media/rcar_vin.txt rename to Documentation/devicetree/bindings/media/renesas,vin.txt diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.txt b/Documentation/devicetree/bindings/media/rockchip-vpu.txt index 35dc464ad7c8..339252d9c515 100644 --- a/Documentation/devicetree/bindings/media/rockchip-vpu.txt +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.txt @@ -1,14 +1,17 @@ device-tree bindings for rockchip VPU codec Rockchip (Video Processing Unit) present in various Rockchip platforms, -such as RK3288 and RK3399. +such as RK3288, RK3328 and RK3399. Required properties: - compatible: value should be one of the following "rockchip,rk3288-vpu"; + "rockchip,rk3328-vpu"; "rockchip,rk3399-vpu"; - interrupts: encoding and decoding interrupt specifiers -- interrupt-names: should be "vepu" and "vdpu" +- interrupt-names: should be + "vepu", "vdpu" on RK3288 and RK3399, + "vdpu" on RK3328. - clocks: phandle to VPU aclk, hclk clocks - clock-names: should be "aclk" and "hclk" - power-domains: phandle to power domain node @@ -27,3 +30,14 @@ SoC-specific DT entry: power-domains = <&power RK3288_PD_VIDEO>; iommus = <&vpu_mmu>; }; + + vpu: video-codec@ff350000 { + compatible = "rockchip,rk3328-vpu"; + reg = <0x0 0xff350000 0x0 0x800>; + interrupts = ; + interrupt-names = "vdpu"; + clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>; + clock-names = "aclk", "hclk"; + power-domains = <&power RK3328_PD_VPU>; + iommus = <&vpu_mmu>; + }; diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt deleted file mode 100644 index 278098987edb..000000000000 --- a/Documentation/devicetree/bindings/media/sunxi-ir.txt +++ /dev/null @@ -1,28 +0,0 @@ -Device-Tree bindings for SUNXI IR controller found in sunXi SoC family - -Required properties: -- compatible : "allwinner,sun4i-a10-ir" or "allwinner,sun5i-a13-ir" -- clocks : list of clock specifiers, corresponding to - entries in clock-names property; -- clock-names : should contain "apb" and "ir" entries; -- interrupts : should contain IR IRQ number; -- reg : should contain IO map address for IR. - -Optional properties: -- linux,rc-map-name: see rc.txt file in the same directory. -- resets : phandle + reset specifier pair -- clock-frequency : IR Receiver clock frequency, in Hertz. Defaults to 8 MHz - if missing. - -Example: - -ir0: ir@1c21800 { - compatible = "allwinner,sun4i-a10-ir"; - clocks = <&apb0_gates 6>, <&ir0_clk>; - clock-names = "apb", "ir"; - clock-frequency = <3000000>; - resets = <&apb0_rst 1>; - interrupts = <0 5 1>; - reg = <0x01C21800 0x40>; - linux,rc-map-name = "rc-rc6-mce"; -}; diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt index e937ddd871a6..b478ade4da65 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt @@ -2,9 +2,10 @@ SMI (Smart Multimedia Interface) Common The hardware block diagram please check bindings/iommu/mediatek,iommu.txt -Mediatek SMI have two generations of HW architecture, mt2712 and mt8173 use -the second generation of SMI HW while mt2701 uses the first generation HW of -SMI. +Mediatek SMI have two generations of HW architecture, here is the list +which generation the SoCs use: +generation 1: mt2701 and mt7623. +generation 2: mt2712, mt8173 and mt8183. There's slight differences between the two SMI, for generation 2, the register which control the iommu port is at each larb's register base. But @@ -19,6 +20,7 @@ Required properties: "mediatek,mt2712-smi-common" "mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common" "mediatek,mt8173-smi-common" + "mediatek,mt8183-smi-common" - reg : the register and size of the SMI block. - power-domains : a phandle to the power domain of this local arbiter. - clocks : Must contain an entry for each entry in clock-names. @@ -30,6 +32,10 @@ Required properties: They may be the same if both source clocks are the same. - "async" : asynchronous clock, it help transform the smi clock into the emi clock domain, this clock is only needed by generation 1 smi HW. + and these 2 option clocks for generation 2 smi HW: + - "gals0": the path0 clock of GALS(Global Async Local Sync). + - "gals1": the path1 clock of GALS(Global Async Local Sync). + Here is the list which has this GALS: mt8183. Example: smi_common: smi@14022000 { diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt index 94eddcae77ab..4b369b3e1a69 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt @@ -8,6 +8,7 @@ Required properties: "mediatek,mt2712-smi-larb" "mediatek,mt7623-smi-larb", "mediatek,mt2701-smi-larb" "mediatek,mt8173-smi-larb" + "mediatek,mt8183-smi-larb" - reg : the register and size of this local arbiter. - mediatek,smi : a phandle to the smi_common node. - power-domains : a phandle to the power domain of this local arbiter. @@ -16,6 +17,9 @@ Required properties: - "apb" : Advanced Peripheral Bus clock, It's the clock for setting the register. - "smi" : It's the clock for transfer data and command. + and this optional clock name: + - "gals": the clock for GALS(Global Async Local Sync). + Here is the list which has this GALS: mt8183. Required property for mt2701, mt2712 and mt7623: - mediatek,larb-id :the hardware id of this larb. diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt b/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.txt similarity index 100% rename from Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt rename to Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.txt diff --git a/Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml b/Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml new file mode 100644 index 000000000000..4b1a09acb98b --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/allwinner,sun4i-a10-ts.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A10 Resistive Touchscreen Controller Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +properties: + "#thermal-sensor-cells": + const: 0 + + compatible: + enum: + - allwinner,sun4i-a10-ts + - allwinner,sun5i-a13-ts + - allwinner,sun6i-a31-ts + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + allwinner,ts-attached: + $ref: /schemas/types.yaml#/definitions/flag + description: A touchscreen is attached to the controller + + allwinner,tp-sensitive-adjust: + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - minimum: 0 + maximum: 15 + default: 15 + description: Sensitivity of pen down detection + + allwinner,filter-type: + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - minimum: 0 + maximum: 3 + default: 1 + description: | + Select median and averaging filter. Sample used for median / + averaging filter: + 0: 4/2 + 1: 5/3 + 2: 8/4 + 3: 16/8 + +required: + - "#thermal-sensor-cells" + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + rtp: rtp@1c25000 { + compatible = "allwinner,sun4i-a10-ts"; + reg = <0x01c25000 0x100>; + interrupts = <29>; + allwinner,ts-attached; + #thermal-sensor-cells = <0>; + /* sensitive/noisy touch panel */ + allwinner,tp-sensitive-adjust = <0>; + allwinner,filter-type = <3>; + }; + +... diff --git a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt index ce8cf0ec6279..4d92c0bb6687 100644 --- a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt +++ b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt @@ -4,9 +4,7 @@ configuring elements such as clocks, pinmux, and reset. Required properties: - compatible: One of: "aspeed,ast2400-scu", "syscon", "simple-mfd" - "aspeed,g4-scu", "syscon", "simple-mfd" "aspeed,ast2500-scu", "syscon", "simple-mfd" - "aspeed,g5-scu", "syscon", "simple-mfd" - reg: contains the offset and length of the SCU memory region - #clock-cells: should be set to <1> - the system controller is also a diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt index 0ebd08af777d..a9b105ac00a8 100644 --- a/Documentation/devicetree/bindings/mfd/mt6397.txt +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt @@ -8,11 +8,12 @@ MT6397/MT6323 is a multifunction device with the following sub modules: - Clock - LED - Keys +- Power controller It is interfaced to host controller using SPI interface by a proprietary hardware called PMIC wrapper or pwrap. MT6397/MT6323 MFD is a child device of pwrap. See the following for pwarp node definitions: -Documentation/devicetree/bindings/soc/mediatek/pwrap.txt +../soc/mediatek/pwrap.txt This document describes the binding for MFD device and its sub module. @@ -22,14 +23,16 @@ compatible: "mediatek,mt6397" or "mediatek,mt6323" Optional subnodes: - rtc - Required properties: + Required properties: Should be one of follows + - compatible: "mediatek,mt6323-rtc" - compatible: "mediatek,mt6397-rtc" + For details, see ../rtc/rtc-mt6397.txt - regulators Required properties: - compatible: "mediatek,mt6397-regulator" - see Documentation/devicetree/bindings/regulator/mt6397-regulator.txt + see ../regulator/mt6397-regulator.txt - compatible: "mediatek,mt6323-regulator" - see Documentation/devicetree/bindings/regulator/mt6323-regulator.txt + see ../regulator/mt6323-regulator.txt - codec Required properties: - compatible: "mediatek,mt6397-codec" @@ -39,12 +42,17 @@ Optional subnodes: - led Required properties: - compatible: "mediatek,mt6323-led" - see Documentation/devicetree/bindings/leds/leds-mt6323.txt + see ../leds/leds-mt6323.txt - keys Required properties: - compatible: "mediatek,mt6397-keys" or "mediatek,mt6323-keys" - see Documentation/devicetree/bindings/input/mtk-pmic-keys.txt + see ../input/mtk-pmic-keys.txt + +- power-controller + Required properties: + - compatible: "mediatek,mt6323-pwrc" + For details, see ../power/reset/mt6323-poweroff.txt Example: pwrap: pwrap@1000f000 { diff --git a/Documentation/devicetree/bindings/mfd/rn5t618.txt b/Documentation/devicetree/bindings/mfd/rn5t618.txt index 65c23263cc54..b74e5e94d1cb 100644 --- a/Documentation/devicetree/bindings/mfd/rn5t618.txt +++ b/Documentation/devicetree/bindings/mfd/rn5t618.txt @@ -14,6 +14,10 @@ Required properties: "ricoh,rc5t619" - reg: the I2C slave address of the device +Optional properties: + - system-power-controller: + See Documentation/devicetree/bindings/power/power-controller.txt + Sub-nodes: - regulators: the node is required if the regulator functionality is needed. The valid regulator names are: DCDC1, DCDC2, DCDC3, DCDC4 @@ -28,6 +32,7 @@ Example: pmic@32 { compatible = "ricoh,rn5t618"; reg = <0x32>; + system-power-controller; regulators { DCDC1 { diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt deleted file mode 100644 index 86dd8191b04c..000000000000 --- a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt +++ /dev/null @@ -1,59 +0,0 @@ -Allwinner SoCs' GPADC Device Tree bindings ------------------------------------------- -The Allwinner SoCs all have an ADC that can also act as a thermal sensor -and sometimes as a touchscreen controller. - -Required properties: - - compatible: "allwinner,sun8i-a33-ths", - - reg: mmio address range of the chip, - - #thermal-sensor-cells: shall be 0, - - #io-channel-cells: shall be 0, - -Example: - ths: ths@1c25000 { - compatible = "allwinner,sun8i-a33-ths"; - reg = <0x01c25000 0x100>; - #thermal-sensor-cells = <0>; - #io-channel-cells = <0>; - }; - -sun4i, sun5i and sun6i SoCs are also supported via the older binding: - -sun4i resistive touchscreen controller --------------------------------------- - -Required properties: - - compatible: "allwinner,sun4i-a10-ts", "allwinner,sun5i-a13-ts" or - "allwinner,sun6i-a31-ts" - - reg: mmio address range of the chip - - interrupts: interrupt to which the chip is connected - - #thermal-sensor-cells: shall be 0 - -Optional properties: - - allwinner,ts-attached : boolean indicating that an actual touchscreen - is attached to the controller - - allwinner,tp-sensitive-adjust : integer (4 bits) - adjust sensitivity of pen down detection - between 0 (least sensitive) and 15 - (defaults to 15) - - allwinner,filter-type : integer (2 bits) - select median and averaging filter - samples used for median / averaging filter - 0: 4/2 - 1: 5/3 - 2: 8/4 - 3: 16/8 - (defaults to 1) - -Example: - - rtp: rtp@1c25000 { - compatible = "allwinner,sun4i-a10-ts"; - reg = <0x01c25000 0x100>; - interrupts = <29>; - allwinner,ts-attached; - #thermal-sensor-cells = <0>; - /* sensitive/noisy touch panel */ - allwinner,tp-sensitive-adjust = <0>; - allwinner,filter-type = <3>; - }; diff --git a/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt b/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt index 854bd67ffec6..0e1fa5bc6a30 100644 --- a/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt +++ b/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt @@ -26,9 +26,7 @@ property: - compatible : Should be one of the following: "aspeed,ast2400-scu", "syscon", "simple-mfd" - "aspeed,g4-scu", "syscon", "simple-mfd" "aspeed,ast2500-scu", "syscon", "simple-mfd" - "aspeed,g5-scu", "syscon", "simple-mfd" Example =================== diff --git a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml index df0280edef97..d2d4308596b8 100644 --- a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml @@ -29,18 +29,24 @@ properties: - items: - const: allwinner,sun8i-a83t-mmc - const: allwinner,sun7i-a20-mmc - - items: - - const: allwinner,sun50i-h6-emmc - - const: allwinner,sun50i-a64-emmc - - items: - - const: allwinner,sun50i-h6-mmc - - const: allwinner,sun50i-a64-mmc - items: - const: allwinner,sun8i-r40-emmc - const: allwinner,sun50i-a64-emmc - items: - const: allwinner,sun8i-r40-mmc - const: allwinner,sun50i-a64-mmc + - items: + - const: allwinner,sun50i-h5-emmc + - const: allwinner,sun50i-a64-emmc + - items: + - const: allwinner,sun50i-h5-mmc + - const: allwinner,sun50i-a64-mmc + - items: + - const: allwinner,sun50i-h6-emmc + - const: allwinner,sun50i-a64-emmc + - items: + - const: allwinner,sun50i-h6-mmc + - const: allwinner,sun50i-a64-mmc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt index 1edbb049cccb..7ca0aa7ccc0b 100644 --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt @@ -17,6 +17,8 @@ Required Properties: For this device it is strongly suggested to include arasan,soc-ctl-syscon. - "ti,am654-sdhci-5.1", "arasan,sdhci-5.1": TI AM654 MMC PHY Note: This binding has been deprecated and moved to [5]. + - "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1": Intel LGM eMMC PHY + For this device it is strongly suggested to include arasan,soc-ctl-syscon. [5] Documentation/devicetree/bindings/mmc/sdhci-am654.txt @@ -80,3 +82,18 @@ Example: phy-names = "phy_arasan"; #clock-cells = <0>; }; + + emmc: sdhci@ec700000 { + compatible = "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1"; + reg = <0xec700000 0x300>; + interrupt-parent = <&ioapic1>; + interrupts = <44 1>; + clocks = <&cgu0 LGM_CLK_EMMC5>, <&cgu0 LGM_CLK_NGI>, + <&cgu0 LGM_GCLK_EMMC>; + clock-names = "clk_xin", "clk_ahb", "gate"; + clock-output-names = "emmc_cardclock"; + #clock-cells = <0>; + phys = <&emmc_phy>; + phy-names = "phy_arasan"; + arasan,soc-ctl-syscon = <&sysconf>; + }; diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml new file mode 100644 index 000000000000..200de9396036 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml @@ -0,0 +1,106 @@ +# SPDX-License-Identifier: GPL-2.0-or-later +# Copyright 2019 IBM Corp. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/aspeed,sdhci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ASPEED SD/SDIO/MMC Controller + +maintainers: + - Andrew Jeffery + - Ryan Chen + +description: |+ + The ASPEED SD/SDIO/eMMC controller exposes two slots implementing the SDIO + Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit data bus if + only a single slot is enabled. + + The two slots are supported by a common configuration area. As the SDHCIs for + the slots are dependent on the common configuration area, they are described + as child nodes. + +properties: + compatible: + enum: + - aspeed,ast2400-sd-controller + - aspeed,ast2500-sd-controller + - aspeed,ast2600-sd-controller + reg: + maxItems: 1 + description: Common configuration registers + "#address-cells": + const: 1 + "#size-cells": + const: 1 + ranges: true + clocks: + maxItems: 1 + description: The SD/SDIO controller clock gate + +patternProperties: + "^sdhci@[0-9a-f]+$": + type: object + allOf: + - $ref: mmc-controller.yaml + properties: + compatible: + enum: + - aspeed,ast2400-sdhci + - aspeed,ast2500-sdhci + - aspeed,ast2600-sdhci + reg: + maxItems: 1 + description: The SDHCI registers + clocks: + maxItems: 1 + description: The SD bus clock + interrupts: + maxItems: 1 + description: The SD interrupt shared between both slots + sdhci,auto-cmd12: + type: boolean + description: Specifies that controller should use auto CMD12 + required: + - compatible + - reg + - clocks + - interrupts + +additionalProperties: false + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + - ranges + - clocks + +examples: + - | + #include + sdc@1e740000 { + compatible = "aspeed,ast2500-sd-controller"; + reg = <0x1e740000 0x100>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x1e740000 0x20000>; + clocks = <&syscon ASPEED_CLK_GATE_SDCLK>; + + sdhci0: sdhci@100 { + compatible = "aspeed,ast2500-sdhci"; + reg = <0x100 0x100>; + interrupts = <26>; + sdhci,auto-cmd12; + clocks = <&syscon ASPEED_CLK_SDIO>; + }; + + sdhci1: sdhci@200 { + compatible = "aspeed,ast2500-sdhci"; + reg = <0x200 0x100>; + interrupts = <26>; + sdhci,auto-cmd12; + clocks = <&syscon ASPEED_CLK_SDIO>; + }; + }; diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt index fa90d253dc7e..09d87cc1182a 100644 --- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt +++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt @@ -6,10 +6,12 @@ by mmc.txt and the properties that represent the IPROC SDHCI controller. Required properties: - compatible : Should be one of the following "brcm,bcm2835-sdhci" + "brcm,bcm2711-emmc2" "brcm,sdhci-iproc-cygnus" "brcm,sdhci-iproc" -Use brcm2835-sdhci for Rasperry PI. +Use brcm2835-sdhci for the eMMC controller on the BCM2835 (Raspberry Pi) and +bcm2711-emmc2 for the additional eMMC2 controller on BCM2711. Use sdhci-iproc-cygnus for Broadcom SDHCI Controllers restricted to 32bit host accesses to SDHCI registers. diff --git a/Documentation/devicetree/bindings/mtd/mxic-nand.txt b/Documentation/devicetree/bindings/mtd/mxic-nand.txt new file mode 100644 index 000000000000..46c55295a3e6 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/mxic-nand.txt @@ -0,0 +1,36 @@ +Macronix Raw NAND Controller Device Tree Bindings +------------------------------------------------- + +Required properties: +- compatible: should be "mxic,multi-itfc-v009-nand-controller" +- reg: should contain 1 entry for the registers +- #address-cells: should be set to 1 +- #size-cells: should be set to 0 +- interrupts: interrupt line connected to this raw NAND controller +- clock-names: should contain "ps", "send" and "send_dly" +- clocks: should contain 3 phandles for the "ps", "send" and + "send_dly" clocks + +Children nodes: +- children nodes represent the available NAND chips. + +See Documentation/devicetree/bindings/mtd/nand-controller.yaml +for more details on generic bindings. + +Example: + + nand: nand-controller@43c30000 { + compatible = "mxic,multi-itfc-v009-nand-controller"; + reg = <0x43c30000 0x10000>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = ; + clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 15>; + clock-names = "send", "send_dly", "ps"; + + nand@0 { + reg = <0>; + nand-ecc-mode = "soft"; + nand-ecc-algo = "bch"; + }; + }; diff --git a/Documentation/devicetree/bindings/net/adi,adin.yaml b/Documentation/devicetree/bindings/net/adi,adin.yaml new file mode 100644 index 000000000000..d95cc691a65f --- /dev/null +++ b/Documentation/devicetree/bindings/net/adi,adin.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: GPL-2.0+ +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/adi,adin.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADIN1200/ADIN1300 PHY + +maintainers: + - Alexandru Ardelean + +description: | + Bindings for Analog Devices Industrial Ethernet PHYs + +allOf: + - $ref: ethernet-phy.yaml# + +properties: + adi,rx-internal-delay-ps: + description: | + RGMII RX Clock Delay used only when PHY operates in RGMII mode with + internal delay (phy-mode is 'rgmii-id' or 'rgmii-rxid') in pico-seconds. + enum: [ 1600, 1800, 2000, 2200, 2400 ] + default: 2000 + + adi,tx-internal-delay-ps: + description: | + RGMII TX Clock Delay used only when PHY operates in RGMII mode with + internal delay (phy-mode is 'rgmii-id' or 'rgmii-txid') in pico-seconds. + enum: [ 1600, 1800, 2000, 2200, 2400 ] + default: 2000 + + adi,fifo-depth-bits: + description: | + When operating in RMII mode, this option configures the FIFO depth. + enum: [ 4, 8, 12, 16, 20, 24 ] + default: 8 + +examples: + - | + ethernet { + #address-cells = <1>; + #size-cells = <0>; + + phy-mode = "rgmii-id"; + + ethernet-phy@0 { + reg = <0>; + + adi,rx-internal-delay-ps = <1800>; + adi,tx-internal-delay-ps = <2200>; + }; + }; + - | + ethernet { + #address-cells = <1>; + #size-cells = <0>; + + phy-mode = "rmii"; + + ethernet-phy@1 { + reg = <1>; + + adi,fifo-depth-bits = <16>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml index 06b1cc8bea14..ef446ae166f3 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml +++ b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml @@ -17,6 +17,9 @@ properties: compatible: const: allwinner,sun7i-a20-gmac + reg: + maxItems: 1 + interrupts: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml new file mode 100644 index 000000000000..ae91aa9d8616 --- /dev/null +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml @@ -0,0 +1,113 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 BayLibre, SAS +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/net/amlogic,meson-dwmac.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic Meson DWMAC Ethernet controller + +maintainers: + - Neil Armstrong + - Martin Blumenstingl + +# We need a select here so we don't match all nodes with 'snps,dwmac' +select: + properties: + compatible: + contains: + enum: + - amlogic,meson6-dwmac + - amlogic,meson8b-dwmac + - amlogic,meson8m2-dwmac + - amlogic,meson-gxbb-dwmac + - amlogic,meson-axg-dwmac + required: + - compatible + +allOf: + - $ref: "snps,dwmac.yaml#" + - if: + properties: + compatible: + contains: + enum: + - amlogic,meson8b-dwmac + - amlogic,meson8m2-dwmac + - amlogic,meson-gxbb-dwmac + - amlogic,meson-axg-dwmac + + then: + properties: + clocks: + items: + - description: GMAC main clock + - description: First parent clock of the internal mux + - description: Second parent clock of the internal mux + + clock-names: + minItems: 3 + maxItems: 3 + items: + - const: stmmaceth + - const: clkin0 + - const: clkin1 + + amlogic,tx-delay-ns: + $ref: /schemas/types.yaml#definitions/uint32 + description: + The internal RGMII TX clock delay (provided by this driver) in + nanoseconds. Allowed values are 0ns, 2ns, 4ns, 6ns. + When phy-mode is set to "rgmii" then the TX delay should be + explicitly configured. When not configured a fallback of 2ns is + used. When the phy-mode is set to either "rgmii-id" or "rgmii-txid" + the TX clock delay is already provided by the PHY. In that case + this property should be set to 0ns (which disables the TX clock + delay in the MAC to prevent the clock from going off because both + PHY and MAC are adding a delay). + Any configuration is ignored when the phy-mode is set to "rmii". + +properties: + compatible: + additionalItems: true + maxItems: 3 + items: + - enum: + - amlogic,meson6-dwmac + - amlogic,meson8b-dwmac + - amlogic,meson8m2-dwmac + - amlogic,meson-gxbb-dwmac + - amlogic,meson-axg-dwmac + contains: + enum: + - snps,dwmac-3.70a + - snps,dwmac + + reg: + items: + - description: + The first register range should be the one of the DWMAC controller + - description: + The second range is is for the Amlogic specific configuration + (for example the PRG_ETHERNET register range on Meson8b and newer) + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - phy-mode + +examples: + - | + ethmac: ethernet@c9410000 { + compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac"; + reg = <0xc9410000 0x10000>, <0xc8834540 0x8>; + interrupts = <8>; + interrupt-names = "macirq"; + clocks = <&clk_eth>, <&clkc_fclk_div2>, <&clk_mpll2>; + clock-names = "stmmaceth", "clkin0", "clkin1"; + phy-mode = "rgmii"; + }; diff --git a/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml new file mode 100644 index 000000000000..71808e78a495 --- /dev/null +++ b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0-or-later +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/aspeed,ast2600-mdio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ASPEED AST2600 MDIO Controller + +maintainers: + - Andrew Jeffery + +description: |+ + The ASPEED AST2600 MDIO controller is the third iteration of ASPEED's MDIO + bus register interface, this time also separating out the controller from the + MAC. + +allOf: + - $ref: "mdio.yaml#" + +properties: + compatible: + const: aspeed,ast2600-mdio + reg: + maxItems: 1 + description: The register range of the MDIO controller instance + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + +examples: + - | + mdio0: mdio@1e650000 { + compatible = "aspeed,ast2600-mdio"; + reg = <0x1e650000 0x8>; + #address-cells = <1>; + #size-cells = <0>; + + ethphy0: ethernet-phy@0 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt index c26f4e11037c..4fa00e2eafcf 100644 --- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt +++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt @@ -13,6 +13,7 @@ Required properties: * "brcm,bcm20702a1" * "brcm,bcm4330-bt" * "brcm,bcm43438-bt" + * "brcm,bcm4345c5" Optional properties: diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt index bc77477c6878..94c0f8bf4deb 100644 --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt +++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt @@ -32,6 +32,15 @@ Optional properties: ack_gpr is the gpr register offset of CAN stop acknowledge. ack_bit is the bit offset of CAN stop acknowledge. +- fsl,clk-source: Select the clock source to the CAN Protocol Engine (PE). + It's SoC Implementation dependent. Refer to RM for detailed + definition. If this property is not set in device tree node + then driver selects clock source 1 by default. + 0: clock source 0 (oscillator clock) + 1: clock source 1 (peripheral clock) + +- wakeup-source: enable CAN remote wakeup + Example: can@1c000 { @@ -40,4 +49,5 @@ Example: interrupts = <48 0x2>; interrupt-parent = <&mpic>; clock-frequency = <200000000>; // filled in by bootloader + fsl,clk-source = <0>; // select clock source 0 for PE }; diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt index b463e1268ac4..19e4a7d91511 100644 --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt @@ -5,6 +5,7 @@ Required properties: - compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC. "renesas,can-r8a7744" if CAN controller is a part of R8A7744 SoC. "renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC. + "renesas,can-r8a77470" if CAN controller is a part of R8A77470 SoC. "renesas,can-r8a774a1" if CAN controller is a part of R8A774A1 SoC. "renesas,can-r8a774c0" if CAN controller is a part of R8A774C0 SoC. "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC. @@ -17,6 +18,8 @@ Required properties: "renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC. "renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC. "renesas,can-r8a77965" if CAN controller is a part of R8A77965 SoC. + "renesas,can-r8a77990" if CAN controller is a part of R8A77990 SoC. + "renesas,can-r8a77995" if CAN controller is a part of R8A77995 SoC. "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device. "renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1 compatible device. @@ -33,7 +36,8 @@ Required properties: - pinctrl-0: pin control group to be used for this controller. - pinctrl-names: must be "default". -Required properties for R8A7795, R8A7796 and R8A77965: +Required properties for R8A774A1, R8A774C0, R8A7795, R8A7796, R8A77965, +R8A77990, and R8A77995: For the denoted SoCs, "clkp2" can be CANFD clock. This is a div6 clock and can be used by both CAN and CAN FD controller at the same time. It needs to be scaled to maximum frequency if any of these controllers use it. This is done diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt index 32f051f6d338..a901cd9be29e 100644 --- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt +++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt @@ -4,6 +4,7 @@ Renesas R-Car CAN FD controller Device Tree Bindings Required properties: - compatible: Must contain one or more of the following: - "renesas,rcar-gen3-canfd" for R-Car Gen3 and RZ/G2 compatible controllers. + - "renesas,r8a774a1-canfd" for R8A774A1 (RZ/G2M) compatible controller. - "renesas,r8a774c0-canfd" for R8A774C0 (RZ/G2E) compatible controller. - "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller. - "renesas,r8a7796-canfd" for R8A7796 (R-Car M3-W) compatible controller. @@ -11,6 +12,7 @@ Required properties: - "renesas,r8a77970-canfd" for R8A77970 (R-Car V3M) compatible controller. - "renesas,r8a77980-canfd" for R8A77980 (R-Car V3H) compatible controller. - "renesas,r8a77990-canfd" for R8A77990 (R-Car E3) compatible controller. + - "renesas,r8a77995-canfd" for R8A77995 (R-Car D3) compatible controller. When compatible with the generic version, nodes must list the SoC-specific version corresponding to the platform first, followed by the @@ -29,13 +31,12 @@ The name of the child nodes are "channel0" and "channel1" respectively. Each child node supports the "status" property only, which is used to enable/disable the respective channel. -Required properties for "renesas,r8a774c0-canfd", "renesas,r8a7795-canfd", -"renesas,r8a7796-canfd", "renesas,r8a77965-canfd", and "renesas,r8a77990-canfd" -compatible: -In R8A774C0, R8A7795, R8A7796, R8A77965, and R8A77990 SoCs, canfd clock is a -div6 clock and can be used by both CAN and CAN FD controller at the same time. -It needs to be scaled to maximum frequency if any of these controllers use it. -This is done using the below properties: +Required properties for R8A774A1, R8A774C0, R8A7795, R8A7796, R8A77965, +R8A77990, and R8A77995: +In the denoted SoCs, canfd clock is a div6 clock and can be used by both CAN +and CAN FD controller at the same time. It needs to be scaled to maximum +frequency if any of these controllers use it. This is done using the below +properties: - assigned-clocks: phandle of canfd clock. - assigned-clock-rates: maximum frequency of this clock. diff --git a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt b/Documentation/devicetree/bindings/net/can/tcan4x5x.txt new file mode 100644 index 000000000000..27e1b4cebfbd --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/tcan4x5x.txt @@ -0,0 +1,40 @@ +Texas Instruments TCAN4x5x CAN Controller +================================================ + +This file provides device node information for the TCAN4x5x interface contains. + +Required properties: + - compatible: "ti,tcan4x5x" + - reg: 0 + - #address-cells: 1 + - #size-cells: 0 + - spi-max-frequency: Maximum frequency of the SPI bus the chip can + operate at should be less than or equal to 18 MHz. + - device-wake-gpios: Wake up GPIO to wake up the TCAN device. + - interrupt-parent: the phandle to the interrupt controller which provides + the interrupt. + - interrupts: interrupt specification for data-ready. + +See Documentation/devicetree/bindings/net/can/m_can.txt for additional +required property details. + +Optional properties: + - reset-gpios: Hardwired output GPIO. If not defined then software + reset. + - device-state-gpios: Input GPIO that indicates if the device is in + a sleep state or if the device is active. + +Example: +tcan4x5x: tcan4x5x@0 { + compatible = "ti,tcan4x5x"; + reg = <0>; + #address-cells = <1>; + #size-cells = <1>; + spi-max-frequency = <10000000>; + bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>; + interrupt-parent = <&gpio1>; + interrupts = <14 GPIO_ACTIVE_LOW>; + device-state-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>; + device-wake-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio1 27 GPIO_ACTIVE_LOW>; +}; diff --git a/Documentation/devicetree/bindings/net/dsa/ksz.txt b/Documentation/devicetree/bindings/net/dsa/ksz.txt index 4ac21cef370e..95e91e84151c 100644 --- a/Documentation/devicetree/bindings/net/dsa/ksz.txt +++ b/Documentation/devicetree/bindings/net/dsa/ksz.txt @@ -5,6 +5,9 @@ Required properties: - compatible: For external switch chips, compatible string must be exactly one of the following: + - "microchip,ksz8765" + - "microchip,ksz8794" + - "microchip,ksz8795" - "microchip,ksz9477" - "microchip,ksz9897" - "microchip,ksz9896" @@ -12,6 +15,7 @@ Required properties: - "microchip,ksz8565" - "microchip,ksz9893" - "microchip,ksz9563" + - "microchip,ksz8563" Optional properties: diff --git a/Documentation/devicetree/bindings/net/dsa/marvell.txt b/Documentation/devicetree/bindings/net/dsa/marvell.txt index 6f9538974bb9..30c11fea491b 100644 --- a/Documentation/devicetree/bindings/net/dsa/marvell.txt +++ b/Documentation/devicetree/bindings/net/dsa/marvell.txt @@ -22,7 +22,7 @@ which is at a different MDIO base address in different switch families. - "marvell,mv88e6190" : Switch has base address 0x00. Use with models: 6190, 6190X, 6191, 6290, 6390, 6390X - "marvell,mv88e6250" : Switch has base address 0x08 or 0x18. Use with model: - 6250 + 6220, 6250 Required properties: - compatible : Should be one of "marvell,mv88e6085", diff --git a/Documentation/devicetree/bindings/net/dsa/mt7530.txt b/Documentation/devicetree/bindings/net/dsa/mt7530.txt index 47aa205ee0bd..c5ed5d25f642 100644 --- a/Documentation/devicetree/bindings/net/dsa/mt7530.txt +++ b/Documentation/devicetree/bindings/net/dsa/mt7530.txt @@ -35,6 +35,42 @@ Required properties for the child nodes within ports container: - phy-mode: String, must be either "trgmii" or "rgmii" for port labeled "cpu". +Port 5 of the switch is muxed between: +1. GMAC5: GMAC5 can interface with another external MAC or PHY. +2. PHY of port 0 or port 4: PHY interfaces with an external MAC like 2nd GMAC + of the SOC. Used in many setups where port 0/4 becomes the WAN port. + Note: On a MT7621 SOC with integrated switch: 2nd GMAC can only connected to + GMAC5 when the gpios for RGMII2 (GPIO 22-33) are not used and not + connected to external component! + +Port 5 modes/configurations: +1. Port 5 is disabled and isolated: An external phy can interface to the 2nd + GMAC of the SOC. + In the case of a build-in MT7530 switch, port 5 shares the RGMII bus with 2nd + GMAC and an optional external phy. Mind the GPIO/pinctl settings of the SOC! +2. Port 5 is muxed to PHY of port 0/4: Port 0/4 interfaces with 2nd GMAC. + It is a simple MAC to PHY interface, port 5 needs to be setup for xMII mode + and RGMII delay. +3. Port 5 is muxed to GMAC5 and can interface to an external phy. + Port 5 becomes an extra switch port. + Only works on platform where external phy TX<->RX lines are swapped. + Like in the Ubiquiti ER-X-SFP. +4. Port 5 is muxed to GMAC5 and interfaces with the 2nd GAMC as 2nd CPU port. + Currently a 2nd CPU port is not supported by DSA code. + +Depending on how the external PHY is wired: +1. normal: The PHY can only connect to 2nd GMAC but not to the switch +2. swapped: RGMII TX, RX are swapped; external phy interface with the switch as + a ethernet port. But can't interface to the 2nd GMAC. + +Based on the DT the port 5 mode is configured. + +Driver tries to lookup the phy-handle of the 2nd GMAC of the master device. +When phy-handle matches PHY of port 0 or 4 then port 5 set-up as mode 2. +phy-mode must be set, see also example 2 below! + * mt7621: phy-mode = "rgmii-txid"; + * mt7623: phy-mode = "rgmii"; + See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional required, optional properties and how the integrated switch subnodes must be specified. @@ -94,3 +130,181 @@ Example: }; }; }; + +Example 2: MT7621: Port 4 is WAN port: 2nd GMAC -> Port 5 -> PHY port 4. + +ð { + gmac0: mac@0 { + compatible = "mediatek,eth-mac"; + reg = <0>; + phy-mode = "rgmii"; + + fixed-link { + speed = <1000>; + full-duplex; + pause; + }; + }; + + gmac1: mac@1 { + compatible = "mediatek,eth-mac"; + reg = <1>; + phy-mode = "rgmii-txid"; + phy-handle = <&phy4>; + }; + + mdio: mdio-bus { + #address-cells = <1>; + #size-cells = <0>; + + /* Internal phy */ + phy4: ethernet-phy@4 { + reg = <4>; + }; + + mt7530: switch@1f { + compatible = "mediatek,mt7621"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x1f>; + pinctrl-names = "default"; + mediatek,mcm; + + resets = <&rstctrl 2>; + reset-names = "mcm"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + label = "lan0"; + }; + + port@1 { + reg = <1>; + label = "lan1"; + }; + + port@2 { + reg = <2>; + label = "lan2"; + }; + + port@3 { + reg = <3>; + label = "lan3"; + }; + +/* Commented out. Port 4 is handled by 2nd GMAC. + port@4 { + reg = <4>; + label = "lan4"; + }; +*/ + + cpu_port0: port@6 { + reg = <6>; + label = "cpu"; + ethernet = <&gmac0>; + phy-mode = "rgmii"; + + fixed-link { + speed = <1000>; + full-duplex; + pause; + }; + }; + }; + }; + }; +}; + +Example 3: MT7621: Port 5 is connected to external PHY: Port 5 -> external PHY. + +ð { + gmac0: mac@0 { + compatible = "mediatek,eth-mac"; + reg = <0>; + phy-mode = "rgmii"; + + fixed-link { + speed = <1000>; + full-duplex; + pause; + }; + }; + + mdio: mdio-bus { + #address-cells = <1>; + #size-cells = <0>; + + /* External phy */ + ephy5: ethernet-phy@7 { + reg = <7>; + }; + + mt7530: switch@1f { + compatible = "mediatek,mt7621"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x1f>; + pinctrl-names = "default"; + mediatek,mcm; + + resets = <&rstctrl 2>; + reset-names = "mcm"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + label = "lan0"; + }; + + port@1 { + reg = <1>; + label = "lan1"; + }; + + port@2 { + reg = <2>; + label = "lan2"; + }; + + port@3 { + reg = <3>; + label = "lan3"; + }; + + port@4 { + reg = <4>; + label = "lan4"; + }; + + port@5 { + reg = <5>; + label = "lan5"; + phy-mode = "rgmii"; + phy-handle = <&ephy5>; + }; + + cpu_port0: port@6 { + reg = <6>; + label = "cpu"; + ethernet = <&gmac0>; + phy-mode = "rgmii"; + + fixed-link { + speed = <1000>; + full-duplex; + pause; + }; + }; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/net/fsl-enetc.txt b/Documentation/devicetree/bindings/net/fsl-enetc.txt index 25fc687419db..b7034ccbc1bd 100644 --- a/Documentation/devicetree/bindings/net/fsl-enetc.txt +++ b/Documentation/devicetree/bindings/net/fsl-enetc.txt @@ -11,7 +11,9 @@ Required properties: to parent node bindings. - compatible : Should be "fsl,enetc". -1) The ENETC external port is connected to a MDIO configurable phy: +1. The ENETC external port is connected to a MDIO configurable phy + +1.1. Using the local ENETC Port MDIO interface In this case, the ENETC node should include a "mdio" sub-node that in turn should contain the "ethernet-phy" node describing the @@ -47,8 +49,42 @@ Example: }; }; -2) The ENETC port is an internal port or has a fixed-link external -connection: +1.2. Using the central MDIO PCIe endpoint device + +In this case, the mdio node should be defined as another PCIe +endpoint node, at the same level with the ENETC port nodes. + +Required properties: + +- reg : Specifies PCIe Device Number and Function + Number of the ENETC endpoint device, according + to parent node bindings. +- compatible : Should be "fsl,enetc-mdio". + +The remaining required mdio bus properties are standard, their bindings +already defined in Documentation/devicetree/bindings/net/mdio.txt. + +Example: + + ethernet@0,0 { + compatible = "fsl,enetc"; + reg = <0x000000 0 0 0 0>; + phy-handle = <&sgmii_phy0>; + phy-connection-type = "sgmii"; + }; + + mdio@0,3 { + compatible = "fsl,enetc-mdio"; + reg = <0x000300 0 0 0 0>; + #address-cells = <1>; + #size-cells = <0>; + sgmii_phy0: ethernet-phy@2 { + reg = <0x2>; + }; + }; + +2. The ENETC port is an internal port or has a fixed-link external +connection In this case, the ENETC port node defines a fixed link connection, as specified by Documentation/devicetree/bindings/net/fixed-link.txt. diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt index 2d41fb96ce0a..5b88fae0307d 100644 --- a/Documentation/devicetree/bindings/net/fsl-fec.txt +++ b/Documentation/devicetree/bindings/net/fsl-fec.txt @@ -7,18 +7,6 @@ Required properties: - phy-mode : See ethernet.txt file in the same directory Optional properties: -- phy-reset-gpios : Should specify the gpio for phy reset -- phy-reset-duration : Reset duration in milliseconds. Should present - only if property "phy-reset-gpios" is available. Missing the property - will have the duration be 1 millisecond. Numbers greater than 1000 are - invalid and 1 millisecond will be used instead. -- phy-reset-active-high : If present then the reset sequence using the GPIO - specified in the "phy-reset-gpios" property is reversed (H=reset state, - L=operation state). -- phy-reset-post-delay : Post reset delay in milliseconds. If present then - a delay of phy-reset-post-delay milliseconds will be observed after the - phy-reset-gpios has been toggled. Can be omitted thus no delay is - observed. Delay is in range of 1ms to 1000ms. Other delays are invalid. - phy-supply : regulator that powers the Ethernet PHY. - phy-handle : phandle to the PHY device connected to this device. - fixed-link : Assume a fixed link. See fixed-link.txt in the same directory. @@ -47,11 +35,27 @@ Optional properties: For imx6sx, "int0" handles all 3 queues and ENET_MII. "pps" is for the pulse per second interrupt associated with 1588 precision time protocol(PTP). - Optional subnodes: - mdio : specifies the mdio bus in the FEC, used as a container for phy nodes according to phy.txt in the same directory +Deprecated optional properties: + To avoid these, create a phy node according to phy.txt in the same + directory, and point the fec's "phy-handle" property to it. Then use + the phy's reset binding, again described by phy.txt. +- phy-reset-gpios : Should specify the gpio for phy reset +- phy-reset-duration : Reset duration in milliseconds. Should present + only if property "phy-reset-gpios" is available. Missing the property + will have the duration be 1 millisecond. Numbers greater than 1000 are + invalid and 1 millisecond will be used instead. +- phy-reset-active-high : If present then the reset sequence using the GPIO + specified in the "phy-reset-gpios" property is reversed (H=reset state, + L=operation state). +- phy-reset-post-delay : Post reset delay in milliseconds. If present then + a delay of phy-reset-post-delay milliseconds will be observed after the + phy-reset-gpios has been toggled. Can be omitted thus no delay is + observed. Delay is in range of 1ms to 1000ms. Other delays are invalid. + Example: ethernet@83fec000 { diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt index 63c73fafe26d..0b61a90f1592 100644 --- a/Documentation/devicetree/bindings/net/macb.txt +++ b/Documentation/devicetree/bindings/net/macb.txt @@ -15,10 +15,10 @@ Required properties: Use "atmel,sama5d4-gem" for the GEM IP (10/100) available on Atmel sama5d4 SoCs. Use "cdns,zynq-gem" Xilinx Zynq-7xxx SoC. Use "cdns,zynqmp-gem" for Zynq Ultrascale+ MPSoC. - Use "sifive,fu540-macb" for SiFive FU540-C000 SoC. + Use "sifive,fu540-c000-gem" for SiFive FU540-C000 SoC. Or the generic form: "cdns,emac". - reg: Address and length of the register set for the device - For "sifive,fu540-macb", second range is required to specify the + For "sifive,fu540-c000-gem", second range is required to specify the address and length of the registers for GEMGXL Management block. - interrupts: Should contain macb interrupt - phy-mode: See ethernet.txt file in the same directory. diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt index 770ff98d4524..72d03e07cf7c 100644 --- a/Documentation/devicetree/bindings/net/mediatek-net.txt +++ b/Documentation/devicetree/bindings/net/mediatek-net.txt @@ -12,6 +12,7 @@ Required properties: "mediatek,mt7623-eth", "mediatek,mt2701-eth": for MT7623 SoC "mediatek,mt7622-eth": for MT7622 SoC "mediatek,mt7629-eth": for MT7629 SoC + "ralink,rt5350-eth": for Ralink Rt5350F and MT7628/88 SoC - reg: Address and length of the register set for the device - interrupts: Should contain the three frame engines interrupts in numeric order. These are fe_int0, fe_int1 and fe_int2. diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt b/Documentation/devicetree/bindings/net/meson-dwmac.txt deleted file mode 100644 index 1321bb194ed9..000000000000 --- a/Documentation/devicetree/bindings/net/meson-dwmac.txt +++ /dev/null @@ -1,71 +0,0 @@ -* Amlogic Meson DWMAC Ethernet controller - -The device inherits all the properties of the dwmac/stmmac devices -described in the file stmmac.txt in the current directory with the -following changes. - -Required properties on all platforms: - -- compatible: Depending on the platform this should be one of: - - "amlogic,meson6-dwmac" - - "amlogic,meson8b-dwmac" - - "amlogic,meson8m2-dwmac" - - "amlogic,meson-gxbb-dwmac" - - "amlogic,meson-axg-dwmac" - Additionally "snps,dwmac" and any applicable more - detailed version number described in net/stmmac.txt - should be used. - -- reg: The first register range should be the one of the DWMAC - controller. The second range is is for the Amlogic specific - configuration (for example the PRG_ETHERNET register range - on Meson8b and newer) - -Required properties on Meson8b, Meson8m2, GXBB and newer: -- clock-names: Should contain the following: - - "stmmaceth" - see stmmac.txt - - "clkin0" - first parent clock of the internal mux - - "clkin1" - second parent clock of the internal mux - -Optional properties on Meson8b, Meson8m2, GXBB and newer: -- amlogic,tx-delay-ns: The internal RGMII TX clock delay (provided - by this driver) in nanoseconds. Allowed values - are: 0ns, 2ns, 4ns, 6ns. - When phy-mode is set to "rgmii" then the TX - delay should be explicitly configured. When - not configured a fallback of 2ns is used. - When the phy-mode is set to either "rgmii-id" - or "rgmii-txid" the TX clock delay is already - provided by the PHY. In that case this - property should be set to 0ns (which disables - the TX clock delay in the MAC to prevent the - clock from going off because both PHY and MAC - are adding a delay). - Any configuration is ignored when the phy-mode - is set to "rmii". - -Example for Meson6: - - ethmac: ethernet@c9410000 { - compatible = "amlogic,meson6-dwmac", "snps,dwmac"; - reg = <0xc9410000 0x10000 - 0xc1108108 0x4>; - interrupts = <0 8 1>; - interrupt-names = "macirq"; - clocks = <&clk81>; - clock-names = "stmmaceth"; - } - -Example for GXBB: - ethmac: ethernet@c9410000 { - compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac"; - reg = <0x0 0xc9410000 0x0 0x10000>, - <0x0 0xc8834540 0x0 0x8>; - interrupts = <0 8 1>; - interrupt-names = "macirq"; - clocks = <&clkc CLKID_ETH>, - <&clkc CLKID_FCLK_DIV2>, - <&clkc CLKID_MPLL2>; - clock-names = "stmmaceth", "clkin0", "clkin1"; - phy-mode = "rgmii"; - }; diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt index 5100358177c9..b921731cd970 100644 --- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt +++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt @@ -12,8 +12,36 @@ and therefore may overwrite them. KSZ9021: All skew control options are specified in picoseconds. The minimum - value is 0, the maximum value is 3000, and it is incremented by 200ps - steps. + value is 0, the maximum value is 3000, and it can be specified in 200ps + steps, *but* these values are in not fact what you get because this chip's + skew values actually increase in 120ps steps, starting from -840ps. The + incorrect values came from an error in the original KSZ9021 datasheet + before it was corrected in revision 1.2 (Feb 2014), but it is too late to + change the driver now because of the many existing device trees that have + been created using values that go up in increments of 200. + + The following table shows the actual skew delay you will get for each of the + possible devicetree values, and the number that will be programmed into the + corresponding pad skew register: + + Device Tree Value Delay Pad Skew Register Value + ----------------------------------------------------- + 0 -840ps 0000 + 200 -720ps 0001 + 400 -600ps 0010 + 600 -480ps 0011 + 800 -360ps 0100 + 1000 -240ps 0101 + 1200 -120ps 0110 + 1400 0ps 0111 + 1600 120ps 1000 + 1800 240ps 1001 + 2000 360ps 1010 + 2200 480ps 1011 + 2400 600ps 1100 + 2600 720ps 1101 + 2800 840ps 1110 + 3000 960ps 1111 Optional properties: diff --git a/Documentation/devicetree/bindings/net/mscc-ocelot.txt b/Documentation/devicetree/bindings/net/mscc-ocelot.txt index 9e5c17d426ce..3b6290b45ce5 100644 --- a/Documentation/devicetree/bindings/net/mscc-ocelot.txt +++ b/Documentation/devicetree/bindings/net/mscc-ocelot.txt @@ -12,13 +12,15 @@ Required properties: - "sys" - "rew" - "qs" + - "ptp" (optional due to backward compatibility) - "qsys" - "ana" - "portX" with X from 0 to the number of last port index available on that switch -- interrupts: Should contain the switch interrupts for frame extraction and - frame injection -- interrupt-names: should contain the interrupt names: "xtr", "inj" +- interrupts: Should contain the switch interrupts for frame extraction, + frame injection and PTP ready. +- interrupt-names: should contain the interrupt names: "xtr", "inj". Can contain + "ptp_rdy" which is optional due to backward compatibility. - ethernet-ports: A container for child nodes representing switch ports. The ethernet-ports container has the following properties @@ -44,6 +46,7 @@ Example: reg = <0x1010000 0x10000>, <0x1030000 0x10000>, <0x1080000 0x100>, + <0x10e0000 0x10000>, <0x11e0000 0x100>, <0x11f0000 0x100>, <0x1200000 0x100>, @@ -57,11 +60,12 @@ Example: <0x1280000 0x100>, <0x1800000 0x80000>, <0x1880000 0x10000>; - reg-names = "sys", "rew", "qs", "port0", "port1", "port2", - "port3", "port4", "port5", "port6", "port7", - "port8", "port9", "port10", "qsys", "ana"; - interrupts = <21 22>; - interrupt-names = "xtr", "inj"; + reg-names = "sys", "rew", "qs", "ptp", "port0", "port1", + "port2", "port3", "port4", "port5", "port6", + "port7", "port8", "port9", "port10", "qsys", + "ana"; + interrupts = <18 21 22>; + interrupt-names = "ptp_rdy", "xtr", "inj"; ethernet-ports { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt index 7ad36213093e..5df4aa7f6811 100644 --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt @@ -18,6 +18,7 @@ Required properties: R-Car Gen2 and RZ/G1 devices. - "renesas,etheravb-r8a774a1" for the R8A774A1 SoC. + - "renesas,etheravb-r8a774b1" for the R8A774B1 SoC. - "renesas,etheravb-r8a774c0" for the R8A774C0 SoC. - "renesas,etheravb-r8a7795" for the R8A7795 SoC. - "renesas,etheravb-r8a7796" for the R8A7796 SoC. diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 76fea2be66ac..4845e29411e4 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -50,6 +50,11 @@ properties: - allwinner,sun8i-r40-emac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac + - amlogic,meson6-dwmac + - amlogic,meson8b-dwmac + - amlogic,meson8m2-dwmac + - amlogic,meson-gxbb-dwmac + - amlogic,meson-axg-dwmac - snps,dwmac - snps,dwmac-3.50a - snps,dwmac-3.610 @@ -61,7 +66,8 @@ properties: - snps,dwxgmac-2.10 reg: - maxItems: 1 + minItems: 1 + maxItems: 2 interrupts: minItems: 1 @@ -106,6 +112,14 @@ properties: reset-names: const: stmmaceth + mac-mode: + $ref: ethernet-controller.yaml#/properties/phy-connection-type + description: + The property is identical to 'phy-mode', and assumes that there is mode + converter in-between the MAC & PHY (e.g. GMII-to-RGMII). This converter + can be passive (no SW requirement), and requires that the MAC operate + in a different mode than the PHY in order to function. + snps,axi-config: $ref: /schemas/types.yaml#definitions/phandle description: diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt index db6aa3f2215b..388ff48f53ae 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83867.txt +++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt @@ -37,6 +37,10 @@ Optional property: for applicable values. The CLK_OUT pin can also be disabled by this property. When omitted, the PHY's default will be left as is. + - ti,sgmii-ref-clock-output-enable - This denotes which + SGMII configuration is used (4 or 6-wire modes). + Some MACs work with differential SGMII clock. + See data manual for details. Note: ti,min-output-impedance and ti,max-output-impedance are mutually exclusive. When both properties are present ti,max-output-impedance diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt index 96ffd06d2ca8..904dadf3d07b 100644 --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt @@ -2,7 +2,7 @@ Freescale i.MX6 On-Chip OTP Controller (OCOTP) device tree bindings This binding represents the on-chip eFuse OTP controller found on i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX, i.MX6UL, i.MX6ULL/ULZ, i.MX6SLL, -i.MX7D/S, i.MX7ULP and i.MX8MQ SoCs. +i.MX7D/S, i.MX7ULP, i.MX8MQ, i.MX8MM and i.MX8MN SoCs. Required properties: - compatible: should be one of @@ -16,6 +16,7 @@ Required properties: "fsl,imx7ulp-ocotp" (i.MX7ULP), "fsl,imx8mq-ocotp" (i.MX8MQ), "fsl,imx8mm-ocotp" (i.MX8MM), + "fsl,imx8mn-ocotp" (i.MX8MN), followed by "syscon". - #address-cells : Should be 1 - #size-cells : Should be 1 diff --git a/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt b/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt deleted file mode 100644 index c2127b96805a..000000000000 --- a/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt +++ /dev/null @@ -1,680 +0,0 @@ -Qualcomm Technologies, Inc. KRYO CPUFreq and OPP bindings -=================================== - -In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996 -that have KRYO processors, the CPU ferequencies subset and voltage value -of each OPP varies based on the silicon variant in use. -Qualcomm Technologies, Inc. Process Voltage Scaling Tables -defines the voltage and frequency value based on the msm-id in SMEM -and speedbin blown in the efuse combination. -The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC -to provide the OPP framework with required information (existing HW bitmap). -This is used to determine the voltage and frequency value for each OPP of -operating-points-v2 table when it is parsed by the OPP framework. - -Required properties: --------------------- -In 'cpus' nodes: -- operating-points-v2: Phandle to the operating-points-v2 table to use. - -In 'operating-points-v2' table: -- compatible: Should be - - 'operating-points-v2-kryo-cpu' for apq8096 and msm8996. -- nvmem-cells: A phandle pointing to a nvmem-cells node representing the - efuse registers that has information about the - speedbin that is used to select the right frequency/voltage - value pair. - Please refer the for nvmem-cells - bindings Documentation/devicetree/bindings/nvmem/nvmem.txt - and also examples below. - -In every OPP node: -- opp-supported-hw: A single 32 bit bitmap value, representing compatible HW. - Bitmap: - 0: MSM8996 V3, speedbin 0 - 1: MSM8996 V3, speedbin 1 - 2: MSM8996 V3, speedbin 2 - 3: unused - 4: MSM8996 SG, speedbin 0 - 5: MSM8996 SG, speedbin 1 - 6: MSM8996 SG, speedbin 2 - 7-31: unused - -Example 1: ---------- - - cpus { - #address-cells = <2>; - #size-cells = <0>; - - CPU0: cpu@0 { - device_type = "cpu"; - compatible = "qcom,kryo"; - reg = <0x0 0x0>; - enable-method = "psci"; - clocks = <&kryocc 0>; - cpu-supply = <&pm8994_s11_saw>; - operating-points-v2 = <&cluster0_opp>; - #cooling-cells = <2>; - next-level-cache = <&L2_0>; - L2_0: l2-cache { - compatible = "cache"; - cache-level = <2>; - }; - }; - - CPU1: cpu@1 { - device_type = "cpu"; - compatible = "qcom,kryo"; - reg = <0x0 0x1>; - enable-method = "psci"; - clocks = <&kryocc 0>; - cpu-supply = <&pm8994_s11_saw>; - operating-points-v2 = <&cluster0_opp>; - #cooling-cells = <2>; - next-level-cache = <&L2_0>; - }; - - CPU2: cpu@100 { - device_type = "cpu"; - compatible = "qcom,kryo"; - reg = <0x0 0x100>; - enable-method = "psci"; - clocks = <&kryocc 1>; - cpu-supply = <&pm8994_s11_saw>; - operating-points-v2 = <&cluster1_opp>; - #cooling-cells = <2>; - next-level-cache = <&L2_1>; - L2_1: l2-cache { - compatible = "cache"; - cache-level = <2>; - }; - }; - - CPU3: cpu@101 { - device_type = "cpu"; - compatible = "qcom,kryo"; - reg = <0x0 0x101>; - enable-method = "psci"; - clocks = <&kryocc 1>; - cpu-supply = <&pm8994_s11_saw>; - operating-points-v2 = <&cluster1_opp>; - #cooling-cells = <2>; - next-level-cache = <&L2_1>; - }; - - cpu-map { - cluster0 { - core0 { - cpu = <&CPU0>; - }; - - core1 { - cpu = <&CPU1>; - }; - }; - - cluster1 { - core0 { - cpu = <&CPU2>; - }; - - core1 { - cpu = <&CPU3>; - }; - }; - }; - }; - - cluster0_opp: opp_table0 { - compatible = "operating-points-v2-kryo-cpu"; - nvmem-cells = <&speedbin_efuse>; - opp-shared; - - opp-307200000 { - opp-hz = /bits/ 64 <307200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x77>; - clock-latency-ns = <200000>; - }; - opp-384000000 { - opp-hz = /bits/ 64 <384000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-422400000 { - opp-hz = /bits/ 64 <422400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-460800000 { - opp-hz = /bits/ 64 <460800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-480000000 { - opp-hz = /bits/ 64 <480000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-537600000 { - opp-hz = /bits/ 64 <537600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-556800000 { - opp-hz = /bits/ 64 <556800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-614400000 { - opp-hz = /bits/ 64 <614400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-652800000 { - opp-hz = /bits/ 64 <652800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-691200000 { - opp-hz = /bits/ 64 <691200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-729600000 { - opp-hz = /bits/ 64 <729600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-768000000 { - opp-hz = /bits/ 64 <768000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-844800000 { - opp-hz = /bits/ 64 <844800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x77>; - clock-latency-ns = <200000>; - }; - opp-902400000 { - opp-hz = /bits/ 64 <902400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-960000000 { - opp-hz = /bits/ 64 <960000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-979200000 { - opp-hz = /bits/ 64 <979200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1036800000 { - opp-hz = /bits/ 64 <1036800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1056000000 { - opp-hz = /bits/ 64 <1056000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1113600000 { - opp-hz = /bits/ 64 <1113600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1132800000 { - opp-hz = /bits/ 64 <1132800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1190400000 { - opp-hz = /bits/ 64 <1190400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1209600000 { - opp-hz = /bits/ 64 <1209600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1228800000 { - opp-hz = /bits/ 64 <1228800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1286400000 { - opp-hz = /bits/ 64 <1286400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1324800000 { - opp-hz = /bits/ 64 <1324800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x5>; - clock-latency-ns = <200000>; - }; - opp-1363200000 { - opp-hz = /bits/ 64 <1363200000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x72>; - clock-latency-ns = <200000>; - }; - opp-1401600000 { - opp-hz = /bits/ 64 <1401600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x5>; - clock-latency-ns = <200000>; - }; - opp-1440000000 { - opp-hz = /bits/ 64 <1440000000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1478400000 { - opp-hz = /bits/ 64 <1478400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x1>; - clock-latency-ns = <200000>; - }; - opp-1497600000 { - opp-hz = /bits/ 64 <1497600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x4>; - clock-latency-ns = <200000>; - }; - opp-1516800000 { - opp-hz = /bits/ 64 <1516800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1593600000 { - opp-hz = /bits/ 64 <1593600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x71>; - clock-latency-ns = <200000>; - }; - opp-1996800000 { - opp-hz = /bits/ 64 <1996800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x20>; - clock-latency-ns = <200000>; - }; - opp-2188800000 { - opp-hz = /bits/ 64 <2188800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x10>; - clock-latency-ns = <200000>; - }; - }; - - cluster1_opp: opp_table1 { - compatible = "operating-points-v2-kryo-cpu"; - nvmem-cells = <&speedbin_efuse>; - opp-shared; - - opp-307200000 { - opp-hz = /bits/ 64 <307200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x77>; - clock-latency-ns = <200000>; - }; - opp-384000000 { - opp-hz = /bits/ 64 <384000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-403200000 { - opp-hz = /bits/ 64 <403200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-460800000 { - opp-hz = /bits/ 64 <460800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-480000000 { - opp-hz = /bits/ 64 <480000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-537600000 { - opp-hz = /bits/ 64 <537600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-556800000 { - opp-hz = /bits/ 64 <556800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-614400000 { - opp-hz = /bits/ 64 <614400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-652800000 { - opp-hz = /bits/ 64 <652800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-691200000 { - opp-hz = /bits/ 64 <691200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-729600000 { - opp-hz = /bits/ 64 <729600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-748800000 { - opp-hz = /bits/ 64 <748800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-806400000 { - opp-hz = /bits/ 64 <806400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-825600000 { - opp-hz = /bits/ 64 <825600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-883200000 { - opp-hz = /bits/ 64 <883200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-902400000 { - opp-hz = /bits/ 64 <902400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-940800000 { - opp-hz = /bits/ 64 <940800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-979200000 { - opp-hz = /bits/ 64 <979200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1036800000 { - opp-hz = /bits/ 64 <1036800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1056000000 { - opp-hz = /bits/ 64 <1056000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1113600000 { - opp-hz = /bits/ 64 <1113600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1132800000 { - opp-hz = /bits/ 64 <1132800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1190400000 { - opp-hz = /bits/ 64 <1190400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1209600000 { - opp-hz = /bits/ 64 <1209600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1248000000 { - opp-hz = /bits/ 64 <1248000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1286400000 { - opp-hz = /bits/ 64 <1286400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1324800000 { - opp-hz = /bits/ 64 <1324800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1363200000 { - opp-hz = /bits/ 64 <1363200000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1401600000 { - opp-hz = /bits/ 64 <1401600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1440000000 { - opp-hz = /bits/ 64 <1440000000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1478400000 { - opp-hz = /bits/ 64 <1478400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1516800000 { - opp-hz = /bits/ 64 <1516800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1555200000 { - opp-hz = /bits/ 64 <1555200000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1593600000 { - opp-hz = /bits/ 64 <1593600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1632000000 { - opp-hz = /bits/ 64 <1632000000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1670400000 { - opp-hz = /bits/ 64 <1670400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1708800000 { - opp-hz = /bits/ 64 <1708800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1747200000 { - opp-hz = /bits/ 64 <1747200000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1785600000 { - opp-hz = /bits/ 64 <1785600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1804800000 { - opp-hz = /bits/ 64 <1804800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x6>; - clock-latency-ns = <200000>; - }; - opp-1824000000 { - opp-hz = /bits/ 64 <1824000000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x71>; - clock-latency-ns = <200000>; - }; - opp-1900800000 { - opp-hz = /bits/ 64 <1900800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x74>; - clock-latency-ns = <200000>; - }; - opp-1920000000 { - opp-hz = /bits/ 64 <1920000000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x1>; - clock-latency-ns = <200000>; - }; - opp-1977600000 { - opp-hz = /bits/ 64 <1977600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x30>; - clock-latency-ns = <200000>; - }; - opp-1996800000 { - opp-hz = /bits/ 64 <1996800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x1>; - clock-latency-ns = <200000>; - }; - opp-2054400000 { - opp-hz = /bits/ 64 <2054400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x30>; - clock-latency-ns = <200000>; - }; - opp-2073600000 { - opp-hz = /bits/ 64 <2073600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x1>; - clock-latency-ns = <200000>; - }; - opp-2150400000 { - opp-hz = /bits/ 64 <2150400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x31>; - clock-latency-ns = <200000>; - }; - opp-2246400000 { - opp-hz = /bits/ 64 <2246400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x10>; - clock-latency-ns = <200000>; - }; - opp-2342400000 { - opp-hz = /bits/ 64 <2342400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x10>; - clock-latency-ns = <200000>; - }; - }; - -.... - -reserved-memory { - #address-cells = <2>; - #size-cells = <2>; - ranges; -.... - smem_mem: smem-mem@86000000 { - reg = <0x0 0x86000000 0x0 0x200000>; - no-map; - }; -.... -}; - -smem { - compatible = "qcom,smem"; - memory-region = <&smem_mem>; - hwlocks = <&tcsr_mutex 3>; -}; - -soc { -.... - qfprom: qfprom@74000 { - compatible = "qcom,qfprom"; - reg = <0x00074000 0x8ff>; - #address-cells = <1>; - #size-cells = <1>; - .... - speedbin_efuse: speedbin@133 { - reg = <0x133 0x1>; - bits = <5 3>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt index 76b6c79604a5..68592271461f 100644 --- a/Documentation/devicetree/bindings/opp/opp.txt +++ b/Documentation/devicetree/bindings/opp/opp.txt @@ -140,8 +140,8 @@ Optional properties: frequency for a short duration of time limited by the device's power, current and thermal limits. -- opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in - the table should have this. +- opp-suspend: Marks the OPP to be used during device suspend. If multiple OPPs + in the table have this, the OPP with highest opp-hz will be used. - opp-supported-hw: This enables us to select only a subset of OPPs from the larger OPP table, based on what version of the hardware we are running on. We diff --git a/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt new file mode 100644 index 000000000000..4751029b9b74 --- /dev/null +++ b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt @@ -0,0 +1,795 @@ +Qualcomm Technologies, Inc. NVMEM CPUFreq and OPP bindings +=================================== + +In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996, +the CPU frequencies subset and voltage value of each OPP varies based on +the silicon variant in use. +Qualcomm Technologies, Inc. Process Voltage Scaling Tables +defines the voltage and frequency value based on the msm-id in SMEM +and speedbin blown in the efuse combination. +The qcom-cpufreq-nvmem driver reads the msm-id and efuse value from the SoC +to provide the OPP framework with required information (existing HW bitmap). +This is used to determine the voltage and frequency value for each OPP of +operating-points-v2 table when it is parsed by the OPP framework. + +Required properties: +-------------------- +In 'cpu' nodes: +- operating-points-v2: Phandle to the operating-points-v2 table to use. + +In 'operating-points-v2' table: +- compatible: Should be + - 'operating-points-v2-kryo-cpu' for apq8096 and msm8996. + +Optional properties: +-------------------- +In 'cpu' nodes: +- power-domains: A phandle pointing to the PM domain specifier which provides + the performance states available for active state management. + Please refer to the power-domains bindings + Documentation/devicetree/bindings/power/power_domain.txt + and also examples below. +- power-domain-names: Should be + - 'cpr' for qcs404. + +In 'operating-points-v2' table: +- nvmem-cells: A phandle pointing to a nvmem-cells node representing the + efuse registers that has information about the + speedbin that is used to select the right frequency/voltage + value pair. + Please refer the for nvmem-cells + bindings Documentation/devicetree/bindings/nvmem/nvmem.txt + and also examples below. + +In every OPP node: +- opp-supported-hw: A single 32 bit bitmap value, representing compatible HW. + Bitmap: + 0: MSM8996 V3, speedbin 0 + 1: MSM8996 V3, speedbin 1 + 2: MSM8996 V3, speedbin 2 + 3: unused + 4: MSM8996 SG, speedbin 0 + 5: MSM8996 SG, speedbin 1 + 6: MSM8996 SG, speedbin 2 + 7-31: unused + +Example 1: +--------- + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "qcom,kryo"; + reg = <0x0 0x0>; + enable-method = "psci"; + clocks = <&kryocc 0>; + cpu-supply = <&pm8994_s11_saw>; + operating-points-v2 = <&cluster0_opp>; + #cooling-cells = <2>; + next-level-cache = <&L2_0>; + L2_0: l2-cache { + compatible = "cache"; + cache-level = <2>; + }; + }; + + CPU1: cpu@1 { + device_type = "cpu"; + compatible = "qcom,kryo"; + reg = <0x0 0x1>; + enable-method = "psci"; + clocks = <&kryocc 0>; + cpu-supply = <&pm8994_s11_saw>; + operating-points-v2 = <&cluster0_opp>; + #cooling-cells = <2>; + next-level-cache = <&L2_0>; + }; + + CPU2: cpu@100 { + device_type = "cpu"; + compatible = "qcom,kryo"; + reg = <0x0 0x100>; + enable-method = "psci"; + clocks = <&kryocc 1>; + cpu-supply = <&pm8994_s11_saw>; + operating-points-v2 = <&cluster1_opp>; + #cooling-cells = <2>; + next-level-cache = <&L2_1>; + L2_1: l2-cache { + compatible = "cache"; + cache-level = <2>; + }; + }; + + CPU3: cpu@101 { + device_type = "cpu"; + compatible = "qcom,kryo"; + reg = <0x0 0x101>; + enable-method = "psci"; + clocks = <&kryocc 1>; + cpu-supply = <&pm8994_s11_saw>; + operating-points-v2 = <&cluster1_opp>; + #cooling-cells = <2>; + next-level-cache = <&L2_1>; + }; + + cpu-map { + cluster0 { + core0 { + cpu = <&CPU0>; + }; + + core1 { + cpu = <&CPU1>; + }; + }; + + cluster1 { + core0 { + cpu = <&CPU2>; + }; + + core1 { + cpu = <&CPU3>; + }; + }; + }; + }; + + cluster0_opp: opp_table0 { + compatible = "operating-points-v2-kryo-cpu"; + nvmem-cells = <&speedbin_efuse>; + opp-shared; + + opp-307200000 { + opp-hz = /bits/ 64 <307200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x77>; + clock-latency-ns = <200000>; + }; + opp-384000000 { + opp-hz = /bits/ 64 <384000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-422400000 { + opp-hz = /bits/ 64 <422400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-460800000 { + opp-hz = /bits/ 64 <460800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-480000000 { + opp-hz = /bits/ 64 <480000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-537600000 { + opp-hz = /bits/ 64 <537600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-556800000 { + opp-hz = /bits/ 64 <556800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-614400000 { + opp-hz = /bits/ 64 <614400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-652800000 { + opp-hz = /bits/ 64 <652800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-691200000 { + opp-hz = /bits/ 64 <691200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-729600000 { + opp-hz = /bits/ 64 <729600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-768000000 { + opp-hz = /bits/ 64 <768000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-844800000 { + opp-hz = /bits/ 64 <844800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x77>; + clock-latency-ns = <200000>; + }; + opp-902400000 { + opp-hz = /bits/ 64 <902400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-960000000 { + opp-hz = /bits/ 64 <960000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-979200000 { + opp-hz = /bits/ 64 <979200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1036800000 { + opp-hz = /bits/ 64 <1036800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1056000000 { + opp-hz = /bits/ 64 <1056000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1113600000 { + opp-hz = /bits/ 64 <1113600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1132800000 { + opp-hz = /bits/ 64 <1132800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1190400000 { + opp-hz = /bits/ 64 <1190400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1209600000 { + opp-hz = /bits/ 64 <1209600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1228800000 { + opp-hz = /bits/ 64 <1228800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1286400000 { + opp-hz = /bits/ 64 <1286400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1324800000 { + opp-hz = /bits/ 64 <1324800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x5>; + clock-latency-ns = <200000>; + }; + opp-1363200000 { + opp-hz = /bits/ 64 <1363200000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x72>; + clock-latency-ns = <200000>; + }; + opp-1401600000 { + opp-hz = /bits/ 64 <1401600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x5>; + clock-latency-ns = <200000>; + }; + opp-1440000000 { + opp-hz = /bits/ 64 <1440000000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1478400000 { + opp-hz = /bits/ 64 <1478400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x1>; + clock-latency-ns = <200000>; + }; + opp-1497600000 { + opp-hz = /bits/ 64 <1497600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x4>; + clock-latency-ns = <200000>; + }; + opp-1516800000 { + opp-hz = /bits/ 64 <1516800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1593600000 { + opp-hz = /bits/ 64 <1593600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x71>; + clock-latency-ns = <200000>; + }; + opp-1996800000 { + opp-hz = /bits/ 64 <1996800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x20>; + clock-latency-ns = <200000>; + }; + opp-2188800000 { + opp-hz = /bits/ 64 <2188800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x10>; + clock-latency-ns = <200000>; + }; + }; + + cluster1_opp: opp_table1 { + compatible = "operating-points-v2-kryo-cpu"; + nvmem-cells = <&speedbin_efuse>; + opp-shared; + + opp-307200000 { + opp-hz = /bits/ 64 <307200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x77>; + clock-latency-ns = <200000>; + }; + opp-384000000 { + opp-hz = /bits/ 64 <384000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-403200000 { + opp-hz = /bits/ 64 <403200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-460800000 { + opp-hz = /bits/ 64 <460800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-480000000 { + opp-hz = /bits/ 64 <480000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-537600000 { + opp-hz = /bits/ 64 <537600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-556800000 { + opp-hz = /bits/ 64 <556800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-614400000 { + opp-hz = /bits/ 64 <614400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-652800000 { + opp-hz = /bits/ 64 <652800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-691200000 { + opp-hz = /bits/ 64 <691200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-729600000 { + opp-hz = /bits/ 64 <729600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-748800000 { + opp-hz = /bits/ 64 <748800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-806400000 { + opp-hz = /bits/ 64 <806400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-825600000 { + opp-hz = /bits/ 64 <825600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-883200000 { + opp-hz = /bits/ 64 <883200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-902400000 { + opp-hz = /bits/ 64 <902400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-940800000 { + opp-hz = /bits/ 64 <940800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-979200000 { + opp-hz = /bits/ 64 <979200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1036800000 { + opp-hz = /bits/ 64 <1036800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1056000000 { + opp-hz = /bits/ 64 <1056000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1113600000 { + opp-hz = /bits/ 64 <1113600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1132800000 { + opp-hz = /bits/ 64 <1132800000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1190400000 { + opp-hz = /bits/ 64 <1190400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1209600000 { + opp-hz = /bits/ 64 <1209600000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1248000000 { + opp-hz = /bits/ 64 <1248000000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1286400000 { + opp-hz = /bits/ 64 <1286400000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1324800000 { + opp-hz = /bits/ 64 <1324800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1363200000 { + opp-hz = /bits/ 64 <1363200000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1401600000 { + opp-hz = /bits/ 64 <1401600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1440000000 { + opp-hz = /bits/ 64 <1440000000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1478400000 { + opp-hz = /bits/ 64 <1478400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1516800000 { + opp-hz = /bits/ 64 <1516800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1555200000 { + opp-hz = /bits/ 64 <1555200000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1593600000 { + opp-hz = /bits/ 64 <1593600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1632000000 { + opp-hz = /bits/ 64 <1632000000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1670400000 { + opp-hz = /bits/ 64 <1670400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1708800000 { + opp-hz = /bits/ 64 <1708800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1747200000 { + opp-hz = /bits/ 64 <1747200000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-1785600000 { + opp-hz = /bits/ 64 <1785600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x7>; + clock-latency-ns = <200000>; + }; + opp-1804800000 { + opp-hz = /bits/ 64 <1804800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x6>; + clock-latency-ns = <200000>; + }; + opp-1824000000 { + opp-hz = /bits/ 64 <1824000000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x71>; + clock-latency-ns = <200000>; + }; + opp-1900800000 { + opp-hz = /bits/ 64 <1900800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x74>; + clock-latency-ns = <200000>; + }; + opp-1920000000 { + opp-hz = /bits/ 64 <1920000000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x1>; + clock-latency-ns = <200000>; + }; + opp-1977600000 { + opp-hz = /bits/ 64 <1977600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x30>; + clock-latency-ns = <200000>; + }; + opp-1996800000 { + opp-hz = /bits/ 64 <1996800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x1>; + clock-latency-ns = <200000>; + }; + opp-2054400000 { + opp-hz = /bits/ 64 <2054400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x30>; + clock-latency-ns = <200000>; + }; + opp-2073600000 { + opp-hz = /bits/ 64 <2073600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x1>; + clock-latency-ns = <200000>; + }; + opp-2150400000 { + opp-hz = /bits/ 64 <2150400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x31>; + clock-latency-ns = <200000>; + }; + opp-2246400000 { + opp-hz = /bits/ 64 <2246400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x10>; + clock-latency-ns = <200000>; + }; + opp-2342400000 { + opp-hz = /bits/ 64 <2342400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x10>; + clock-latency-ns = <200000>; + }; + }; + +.... + +reserved-memory { + #address-cells = <2>; + #size-cells = <2>; + ranges; +.... + smem_mem: smem-mem@86000000 { + reg = <0x0 0x86000000 0x0 0x200000>; + no-map; + }; +.... +}; + +smem { + compatible = "qcom,smem"; + memory-region = <&smem_mem>; + hwlocks = <&tcsr_mutex 3>; +}; + +soc { +.... + qfprom: qfprom@74000 { + compatible = "qcom,qfprom"; + reg = <0x00074000 0x8ff>; + #address-cells = <1>; + #size-cells = <1>; + .... + speedbin_efuse: speedbin@133 { + reg = <0x133 0x1>; + bits = <5 3>; + }; + }; +}; + +Example 2: +--------- + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + CPU0: cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x100>; + .... + clocks = <&apcs_glb>; + operating-points-v2 = <&cpu_opp_table>; + power-domains = <&cpr>; + power-domain-names = "cpr"; + }; + + CPU1: cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x101>; + .... + clocks = <&apcs_glb>; + operating-points-v2 = <&cpu_opp_table>; + power-domains = <&cpr>; + power-domain-names = "cpr"; + }; + + CPU2: cpu@102 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x102>; + .... + clocks = <&apcs_glb>; + operating-points-v2 = <&cpu_opp_table>; + power-domains = <&cpr>; + power-domain-names = "cpr"; + }; + + CPU3: cpu@103 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x103>; + .... + clocks = <&apcs_glb>; + operating-points-v2 = <&cpu_opp_table>; + power-domains = <&cpr>; + power-domain-names = "cpr"; + }; + }; + + cpu_opp_table: cpu-opp-table { + compatible = "operating-points-v2-kryo-cpu"; + opp-shared; + + opp-1094400000 { + opp-hz = /bits/ 64 <1094400000>; + required-opps = <&cpr_opp1>; + }; + opp-1248000000 { + opp-hz = /bits/ 64 <1248000000>; + required-opps = <&cpr_opp2>; + }; + opp-1401600000 { + opp-hz = /bits/ 64 <1401600000>; + required-opps = <&cpr_opp3>; + }; + }; + + cpr_opp_table: cpr-opp-table { + compatible = "operating-points-v2-qcom-level"; + + cpr_opp1: opp1 { + opp-level = <1>; + qcom,opp-fuse-level = <1>; + }; + cpr_opp2: opp2 { + opp-level = <2>; + qcom,opp-fuse-level = <2>; + }; + cpr_opp3: opp3 { + opp-level = <3>; + qcom,opp-fuse-level = <3>; + }; + }; + +.... + +soc { +.... + cpr: power-controller@b018000 { + compatible = "qcom,qcs404-cpr", "qcom,cpr"; + reg = <0x0b018000 0x1000>; + .... + vdd-apc-supply = <&pms405_s3>; + #power-domain-cells = <0>; + operating-points-v2 = <&cpr_opp_table>; + .... + }; +}; diff --git a/Documentation/devicetree/bindings/opp/qcom-opp.txt b/Documentation/devicetree/bindings/opp/qcom-opp.txt new file mode 100644 index 000000000000..32eb0793c7e6 --- /dev/null +++ b/Documentation/devicetree/bindings/opp/qcom-opp.txt @@ -0,0 +1,19 @@ +Qualcomm OPP bindings to describe OPP nodes + +The bindings are based on top of the operating-points-v2 bindings +described in Documentation/devicetree/bindings/opp/opp.txt +Additional properties are described below. + +* OPP Table Node + +Required properties: +- compatible: Allow OPPs to express their compatibility. It should be: + "operating-points-v2-qcom-level" + +* OPP Node + +Required properties: +- qcom,opp-fuse-level: A positive value representing the fuse corner/level + associated with this OPP node. Sometimes several corners/levels shares + a certain fuse corner/level. A fuse corner/level contains e.g. ref uV, + min uV, and max uV. diff --git a/Documentation/devicetree/bindings/opp/sun50i-nvmem-cpufreq.txt b/Documentation/devicetree/bindings/opp/sun50i-nvmem-cpufreq.txt new file mode 100644 index 000000000000..7deae57a587b --- /dev/null +++ b/Documentation/devicetree/bindings/opp/sun50i-nvmem-cpufreq.txt @@ -0,0 +1,167 @@ +Allwinner Technologies, Inc. NVMEM CPUFreq and OPP bindings +=================================== + +For some SoCs, the CPU frequency subset and voltage value of each OPP +varies based on the silicon variant in use. Allwinner Process Voltage +Scaling Tables defines the voltage and frequency value based on the +speedbin blown in the efuse combination. The sun50i-cpufreq-nvmem driver +reads the efuse value from the SoC to provide the OPP framework with +required information. + +Required properties: +-------------------- +In 'cpus' nodes: +- operating-points-v2: Phandle to the operating-points-v2 table to use. + +In 'operating-points-v2' table: +- compatible: Should be + - 'allwinner,sun50i-h6-operating-points'. +- nvmem-cells: A phandle pointing to a nvmem-cells node representing the + efuse registers that has information about the speedbin + that is used to select the right frequency/voltage value + pair. Please refer the for nvmem-cells bindings + Documentation/devicetree/bindings/nvmem/nvmem.txt and + also examples below. + +In every OPP node: +- opp-microvolt-: Voltage in micro Volts. + At runtime, the platform can pick a and + matching opp-microvolt- property. + [See: opp.txt] + HW: : + sun50i-h6 speed0 speed1 speed2 + +Example 1: +--------- + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu0: cpu@0 { + compatible = "arm,cortex-a53"; + device_type = "cpu"; + reg = <0>; + enable-method = "psci"; + clocks = <&ccu CLK_CPUX>; + clock-latency-ns = <244144>; /* 8 32k periods */ + operating-points-v2 = <&cpu_opp_table>; + #cooling-cells = <2>; + }; + + cpu1: cpu@1 { + compatible = "arm,cortex-a53"; + device_type = "cpu"; + reg = <1>; + enable-method = "psci"; + clocks = <&ccu CLK_CPUX>; + clock-latency-ns = <244144>; /* 8 32k periods */ + operating-points-v2 = <&cpu_opp_table>; + #cooling-cells = <2>; + }; + + cpu2: cpu@2 { + compatible = "arm,cortex-a53"; + device_type = "cpu"; + reg = <2>; + enable-method = "psci"; + clocks = <&ccu CLK_CPUX>; + clock-latency-ns = <244144>; /* 8 32k periods */ + operating-points-v2 = <&cpu_opp_table>; + #cooling-cells = <2>; + }; + + cpu3: cpu@3 { + compatible = "arm,cortex-a53"; + device_type = "cpu"; + reg = <3>; + enable-method = "psci"; + clocks = <&ccu CLK_CPUX>; + clock-latency-ns = <244144>; /* 8 32k periods */ + operating-points-v2 = <&cpu_opp_table>; + #cooling-cells = <2>; + }; + }; + + cpu_opp_table: opp_table { + compatible = "allwinner,sun50i-h6-operating-points"; + nvmem-cells = <&speedbin_efuse>; + opp-shared; + + opp@480000000 { + clock-latency-ns = <244144>; /* 8 32k periods */ + opp-hz = /bits/ 64 <480000000>; + + opp-microvolt-speed0 = <880000>; + opp-microvolt-speed1 = <820000>; + opp-microvolt-speed2 = <800000>; + }; + + opp@720000000 { + clock-latency-ns = <244144>; /* 8 32k periods */ + opp-hz = /bits/ 64 <720000000>; + + opp-microvolt-speed0 = <880000>; + opp-microvolt-speed1 = <820000>; + opp-microvolt-speed2 = <800000>; + }; + + opp@816000000 { + clock-latency-ns = <244144>; /* 8 32k periods */ + opp-hz = /bits/ 64 <816000000>; + + opp-microvolt-speed0 = <880000>; + opp-microvolt-speed1 = <820000>; + opp-microvolt-speed2 = <800000>; + }; + + opp@888000000 { + clock-latency-ns = <244144>; /* 8 32k periods */ + opp-hz = /bits/ 64 <888000000>; + + opp-microvolt-speed0 = <940000>; + opp-microvolt-speed1 = <820000>; + opp-microvolt-speed2 = <800000>; + }; + + opp@1080000000 { + clock-latency-ns = <244144>; /* 8 32k periods */ + opp-hz = /bits/ 64 <1080000000>; + + opp-microvolt-speed0 = <1060000>; + opp-microvolt-speed1 = <880000>; + opp-microvolt-speed2 = <840000>; + }; + + opp@1320000000 { + clock-latency-ns = <244144>; /* 8 32k periods */ + opp-hz = /bits/ 64 <1320000000>; + + opp-microvolt-speed0 = <1160000>; + opp-microvolt-speed1 = <940000>; + opp-microvolt-speed2 = <900000>; + }; + + opp@1488000000 { + clock-latency-ns = <244144>; /* 8 32k periods */ + opp-hz = /bits/ 64 <1488000000>; + + opp-microvolt-speed0 = <1160000>; + opp-microvolt-speed1 = <1000000>; + opp-microvolt-speed2 = <960000>; + }; + }; +.... +soc { +.... + sid: sid@3006000 { + compatible = "allwinner,sun50i-h6-sid"; + reg = <0x03006000 0x400>; + #address-cells = <1>; + #size-cells = <1>; + .... + speedbin_efuse: speed@1c { + reg = <0x1c 4>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt index 5561a1c060d0..78494c4050f7 100644 --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt @@ -11,7 +11,6 @@ Required properties: the ATU address space. (The old way of getting the configuration address space from "ranges" is deprecated and should be avoided.) -- num-lanes: number of lanes to use RC mode: - #address-cells: set to <3> - #size-cells: set to <2> @@ -34,6 +33,11 @@ Optional properties: - clock-names: Must include the following entries: - "pcie" - "pcie_bus" +- snps,enable-cdm-check: This is a boolean property and if present enables + automatic checking of CDM (Configuration Dependent Module) registers + for data corruption. CDM registers include standard PCIe configuration + space registers, Port Logic registers, DMA and iATU (internal Address + Translation Unit) registers. RC mode: - num-viewport: number of view ports configured in hardware. If a platform does not specify it, the driver assumes 2. diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt index a7f5f5afa0e6..de4b2baf91e8 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt @@ -50,7 +50,7 @@ Additional required properties for imx7d-pcie and imx8mq-pcie: - power-domains: Must be set to a phandle pointing to PCIE_PHY power domain - resets: Must contain phandles to PCIe-related reset lines exposed by SRC IP block -- reset-names: Must contain the following entires: +- reset-names: Must contain the following entries: - "pciephy" - "apps" - "turnoff" diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt index 92437a366e5f..7468d666763a 100644 --- a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt @@ -6,6 +6,7 @@ Required properties: "mediatek,mt2712-pcie" "mediatek,mt7622-pcie" "mediatek,mt7623-pcie" + "mediatek,mt7629-pcie" - device_type: Must be "pci" - reg: Base addresses and lengths of the PCIe subsys and root ports. - reg-names: Names of the above areas to use during resource lookup. diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt new file mode 100644 index 000000000000..b739f92da58e --- /dev/null +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt @@ -0,0 +1,171 @@ +NVIDIA Tegra PCIe controller (Synopsys DesignWare Core based) + +This PCIe host controller is based on the Synopsis Designware PCIe IP +and thus inherits all the common properties defined in designware-pcie.txt. + +Required properties: +- compatible: For Tegra19x, must contain "nvidia,tegra194-pcie". +- device_type: Must be "pci" +- power-domains: A phandle to the node that controls power to the respective + PCIe controller and a specifier name for the PCIe controller. Following are + the specifiers for the different PCIe controllers + TEGRA194_POWER_DOMAIN_PCIEX8B: C0 + TEGRA194_POWER_DOMAIN_PCIEX1A: C1 + TEGRA194_POWER_DOMAIN_PCIEX1A: C2 + TEGRA194_POWER_DOMAIN_PCIEX1A: C3 + TEGRA194_POWER_DOMAIN_PCIEX4A: C4 + TEGRA194_POWER_DOMAIN_PCIEX8A: C5 + these specifiers are defined in + "include/dt-bindings/power/tegra194-powergate.h" file. +- reg: A list of physical base address and length pairs for each set of + controller registers. Must contain an entry for each entry in the reg-names + property. +- reg-names: Must include the following entries: + "appl": Controller's application logic registers + "config": As per the definition in designware-pcie.txt + "atu_dma": iATU and DMA registers. This is where the iATU (internal Address + Translation Unit) registers of the PCIe core are made available + for SW access. + "dbi": The aperture where root port's own configuration registers are + available +- interrupts: A list of interrupt outputs of the controller. Must contain an + entry for each entry in the interrupt-names property. +- interrupt-names: Must include the following entries: + "intr": The Tegra interrupt that is asserted for controller interrupts + "msi": The Tegra interrupt that is asserted when an MSI is received +- bus-range: Range of bus numbers associated with this controller +- #address-cells: Address representation for root ports (must be 3) + - cell 0 specifies the bus and device numbers of the root port: + [23:16]: bus number + [15:11]: device number + - cell 1 denotes the upper 32 address bits and should be 0 + - cell 2 contains the lower 32 address bits and is used to translate to the + CPU address space +- #size-cells: Size representation for root ports (must be 2) +- ranges: Describes the translation of addresses for root ports and standard + PCI regions. The entries must be 7 cells each, where the first three cells + correspond to the address as described for the #address-cells property + above, the fourth and fifth cells are for the physical CPU address to + translate to and the sixth and seventh cells are as described for the + #size-cells property above. + - Entries setup the mapping for the standard I/O, memory and + prefetchable PCI regions. The first cell determines the type of region + that is setup: + - 0x81000000: I/O memory region + - 0x82000000: non-prefetchable memory region + - 0xc2000000: prefetchable memory region + Please refer to the standard PCI bus binding document for a more detailed + explanation. +- #interrupt-cells: Size representation for interrupts (must be 1) +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties + Please refer to the standard PCI bus binding document for a more detailed + explanation. +- clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. +- clock-names: Must include the following entries: + - core +- resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. +- reset-names: Must include the following entries: + - apb + - core +- phys: Must contain a phandle to P2U PHY for each entry in phy-names. +- phy-names: Must include an entry for each active lane. + "p2u-N": where N ranges from 0 to one less than the total number of lanes +- nvidia,bpmp: Must contain a pair of phandle to BPMP controller node followed + by controller-id. Following are the controller ids for each controller. + 0: C0 + 1: C1 + 2: C2 + 3: C3 + 4: C4 + 5: C5 +- vddio-pex-ctl-supply: Regulator supply for PCIe side band signals + +Optional properties: +- pinctrl-names: A list of pinctrl state names. + It is mandatory for C5 controller and optional for other controllers. + - "default": Configures PCIe I/O for proper operation. +- pinctrl-0: phandle for the 'default' state of pin configuration. + It is mandatory for C5 controller and optional for other controllers. +- supports-clkreq: Refer to Documentation/devicetree/bindings/pci/pci.txt +- nvidia,update-fc-fixup: This is a boolean property and needs to be present to + improve performance when a platform is designed in such a way that it + satisfies at least one of the following conditions thereby enabling root + port to exchange optimum number of FC (Flow Control) credits with + downstream devices + 1. If C0/C4/C5 run at x1/x2 link widths (irrespective of speed and MPS) + 2. If C0/C1/C2/C3/C4/C5 operate at their respective max link widths and + a) speed is Gen-2 and MPS is 256B + b) speed is >= Gen-3 with any MPS +- nvidia,aspm-cmrt-us: Common Mode Restore Time for proper operation of ASPM + to be specified in microseconds +- nvidia,aspm-pwr-on-t-us: Power On time for proper operation of ASPM to be + specified in microseconds +- nvidia,aspm-l0s-entrance-latency-us: ASPM L0s entrance latency to be + specified in microseconds +- vpcie3v3-supply: A phandle to the regulator node that supplies 3.3V to the slot + if the platform has one such slot. (Ex:- x16 slot owned by C5 controller + in p2972-0000 platform). +- vpcie12v-supply: A phandle to the regulator node that supplies 12V to the slot + if the platform has one such slot. (Ex:- x16 slot owned by C5 controller + in p2972-0000 platform). + +Examples: +========= + +Tegra194: +-------- + + pcie@14180000 { + compatible = "nvidia,tegra194-pcie", "snps,dw-pcie"; + power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX8B>; + reg = <0x00 0x14180000 0x0 0x00020000 /* appl registers (128K) */ + 0x00 0x38000000 0x0 0x00040000 /* configuration space (256K) */ + 0x00 0x38040000 0x0 0x00040000>; /* iATU_DMA reg space (256K) */ + reg-names = "appl", "config", "atu_dma"; + + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + num-lanes = <8>; + linux,pci-domain = <0>; + + pinctrl-names = "default"; + pinctrl-0 = <&pex_rst_c5_out_state>, <&clkreq_c5_bi_dir_state>; + + clocks = <&bpmp TEGRA194_CLK_PEX0_CORE_0>; + clock-names = "core"; + + resets = <&bpmp TEGRA194_RESET_PEX0_CORE_0_APB>, + <&bpmp TEGRA194_RESET_PEX0_CORE_0>; + reset-names = "apb", "core"; + + interrupts = , /* controller interrupt */ + ; /* MSI interrupt */ + interrupt-names = "intr", "msi"; + + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>; + + nvidia,bpmp = <&bpmp 0>; + + supports-clkreq; + nvidia,aspm-cmrt-us = <60>; + nvidia,aspm-pwr-on-t-us = <20>; + nvidia,aspm-l0s-entrance-latency-us = <3>; + + bus-range = <0x0 0xff>; + ranges = <0x81000000 0x0 0x38100000 0x0 0x38100000 0x0 0x00100000 /* downstream I/O (1MB) */ + 0x82000000 0x0 0x38200000 0x0 0x38200000 0x0 0x01E00000 /* non-prefetchable memory (30MB) */ + 0xc2000000 0x18 0x00000000 0x18 0x00000000 0x4 0x00000000>; /* prefetchable memory (16GB) */ + + vddio-pex-ctl-supply = <&vdd_1v8ao>; + vpcie3v3-supply = <&vdd_3v3_pcie>; + vpcie12v-supply = <&vdd_12v_pcie>; + + phys = <&p2u_hsio_2>, <&p2u_hsio_3>, <&p2u_hsio_4>, + <&p2u_hsio_5>; + phy-names = "p2u-0", "p2u-1", "p2u-2", "p2u-3"; + }; diff --git a/Documentation/devicetree/bindings/pci/pci-armada8k.txt b/Documentation/devicetree/bindings/pci/pci-armada8k.txt index 9e3fc15e1af8..7a813d0e6d63 100644 --- a/Documentation/devicetree/bindings/pci/pci-armada8k.txt +++ b/Documentation/devicetree/bindings/pci/pci-armada8k.txt @@ -11,12 +11,20 @@ Required properties: - reg-names: - "ctrl" for the control register region - "config" for the config space region -- interrupts: Interrupt specifier for the PCIe controler +- interrupts: Interrupt specifier for the PCIe controller - clocks: reference to the PCIe controller clocks - clock-names: mandatory if there is a second clock, in this case the name must be "core" for the first clock and "reg" for the second one +Optional properties: +- phys: phandle(s) to PHY node(s) following the generic PHY bindings. + Either 1, 2 or 4 PHYs might be needed depending on the number of + PCIe lanes. +- phy-names: names of the PHYs corresponding to the number of lanes. + Must be "cp0-pcie0-x4-lane0-phy", "cp0-pcie0-x4-lane1-phy" for + 2 PHYs. + Example: pcie@f2600000 { diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt b/Documentation/devicetree/bindings/pci/pci-msi.txt index 9b3cc817d181..b73d839657b6 100644 --- a/Documentation/devicetree/bindings/pci/pci-msi.txt +++ b/Documentation/devicetree/bindings/pci/pci-msi.txt @@ -201,7 +201,7 @@ Example (5) #msi-cells = <1>; }; - pci: pci@c { + pci: pci@f { reg = <0xf 0x1>; compatible = "vendor,pcie-root-complex"; device_type = "pci"; diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt index 2a5d91024059..29bcbd88f457 100644 --- a/Documentation/devicetree/bindings/pci/pci.txt +++ b/Documentation/devicetree/bindings/pci/pci.txt @@ -27,6 +27,11 @@ driver implementation may support the following properties: - reset-gpios: If present this property specifies PERST# GPIO. Host drivers can parse the GPIO and apply fundamental reset to endpoints. +- supports-clkreq: + If present this property specifies that CLKREQ signal routing exists from + root port to downstream device and host bridge drivers can do programming + which depends on CLKREQ signal existence. For example, programming root port + not to advertise ASPM L1 Sub-States support if there is no CLKREQ signal. PCI-PCI Bridge properties ------------------------- diff --git a/Documentation/devicetree/bindings/pci/pcie-al.txt b/Documentation/devicetree/bindings/pci/pcie-al.txt new file mode 100644 index 000000000000..557a5089229d --- /dev/null +++ b/Documentation/devicetree/bindings/pci/pcie-al.txt @@ -0,0 +1,46 @@ +* Amazon Annapurna Labs PCIe host bridge + +Amazon's Annapurna Labs PCIe Host Controller is based on the Synopsys DesignWare +PCI core. It inherits common properties defined in +Documentation/devicetree/bindings/pci/designware-pcie.txt. + +Properties of the host controller node that differ from it are: + +- compatible: + Usage: required + Value type: + Definition: Value should contain + - "amazon,al-alpine-v2-pcie" for alpine_v2 + - "amazon,al-alpine-v3-pcie" for alpine_v3 + +- reg: + Usage: required + Value type: + Definition: Register ranges as listed in the reg-names property + +- reg-names: + Usage: required + Value type: + Definition: Must include the following entries + - "config" PCIe ECAM space + - "controller" AL proprietary registers + - "dbi" Designware PCIe registers + +Example: + + pcie-external0: pcie@fb600000 { + compatible = "amazon,al-alpine-v3-pcie"; + reg = <0x0 0xfb600000 0x0 0x00100000 + 0x0 0xfd800000 0x0 0x00010000 + 0x0 0xfd810000 0x0 0x00001000>; + reg-names = "config", "controller", "dbi"; + bus-range = <0 255>; + device_type = "pci"; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + interrupts = ; + interrupt-map-mask = <0x00 0 0 7>; + interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>; /* INTa */ + ranges = <0x02000000 0x0 0xc0010000 0x0 0xc0010000 0x0 0x07ff0000>; + }; diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml new file mode 100644 index 000000000000..51254b4e65dd --- /dev/null +++ b/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 BayLibre, SAS +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/phy/amlogic,meson-g12a-usb2-phy.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic G12A USB2 PHY + +maintainers: + - Neil Armstrong + +properties: + compatible: + enum: + - amlogic,meson-g12a-usb2-phy + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: xtal + + resets: + maxItems: 1 + + reset-names: + items: + - const: phy + + "#phy-cells": + const: 0 + + phy-supply: + maxItems: 1 + description: + Phandle to a regulator that provides power to the PHY. This + regulator will be managed during the PHY power on/off sequence. + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + - "#phy-cells" + +examples: + - | + phy@36000 { + compatible = "amlogic,meson-g12a-usb2-phy"; + reg = <0x36000 0x2000>; + clocks = <&xtal>; + clock-names = "xtal"; + resets = <&phy_reset>; + reset-names = "phy"; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml new file mode 100644 index 000000000000..346f9c35427c --- /dev/null +++ b/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 BayLibre, SAS +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic G12A USB3 + PCIE Combo PHY + +maintainers: + - Neil Armstrong + +properties: + compatible: + enum: + - amlogic,meson-g12a-usb3-pcie-phy + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: ref_clk + + resets: + maxItems: 1 + + reset-names: + items: + - const: phy + + "#phy-cells": + const: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + - "#phy-cells" + +examples: + - | + phy@46000 { + compatible = "amlogic,meson-g12a-usb3-pcie-phy"; + reg = <0x46000 0x2000>; + clocks = <&ref_clk>; + clock-names = "ref_clk"; + resets = <&phy_reset>; + reset-names = "phy"; + #phy-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/phy/lantiq,vrx200-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/lantiq,vrx200-pcie-phy.yaml new file mode 100644 index 000000000000..a97482179cf5 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/lantiq,vrx200-pcie-phy.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/lantiq,vrx200-pcie-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Lantiq VRX200 and ARX300 PCIe PHY Device Tree Bindings + +maintainers: + - Martin Blumenstingl + +properties: + "#phy-cells": + const: 1 + description: selects the PHY mode as defined in + + compatible: + enum: + - lantiq,vrx200-pcie-phy + - lantiq,arx300-pcie-phy + + reg: + maxItems: 1 + + clocks: + items: + - description: PHY module clock + - description: PDI register clock + + clock-names: + items: + - const: phy + - const: pdi + + resets: + items: + - description: exclusive PHY reset line + - description: shared reset line between the PCIe PHY and PCIe controller + + reset-names: + items: + - const: phy + - const: pcie + + lantiq,rcu: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the RCU syscon + + lantiq,rcu-endian-offset: + $ref: /schemas/types.yaml#/definitions/uint32 + description: the offset of the endian registers for this PHY instance in the RCU syscon + + lantiq,rcu-big-endian-mask: + $ref: /schemas/types.yaml#/definitions/uint32 + description: the mask to set the PDI (PHY) registers for this PHY instance to big endian + + big-endian: + description: Configures the PDI (PHY) registers in big-endian mode + type: boolean + + little-endian: + description: Configures the PDI (PHY) registers in big-endian mode + type: boolean + +required: + - "#phy-cells" + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + - lantiq,rcu + - lantiq,rcu-endian-offset + - lantiq,rcu-big-endian-mask + +additionalProperties: false + +examples: + - | + pcie0_phy: phy@106800 { + compatible = "lantiq,vrx200-pcie-phy"; + reg = <0x106800 0x100>; + lantiq,rcu = <&rcu0>; + lantiq,rcu-endian-offset = <0x4c>; + lantiq,rcu-big-endian-mask = <0x80>; /* bit 7 */ + big-endian; + clocks = <&pmu 32>, <&pmu 36>; + clock-names = "phy", "pdi"; + resets = <&reset0 12 24>, <&reset0 22 22>; + reset-names = "phy", "pcie"; + #phy-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt b/Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt deleted file mode 100644 index a6ebc3dea159..000000000000 --- a/Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt +++ /dev/null @@ -1,22 +0,0 @@ -* Amlogic G12A USB2 PHY binding - -Required properties: -- compatible: Should be "amlogic,meson-g12a-usb2-phy" -- reg: The base address and length of the registers -- #phys-cells: must be 0 (see phy-bindings.txt in this directory) -- clocks: a phandle to the clock of this PHY -- clock-names: must be "xtal" -- resets: a phandle to the reset line of this PHY -- reset-names: must be "phy" -- phy-supply: see phy-bindings.txt in this directory - -Example: - usb2_phy0: phy@36000 { - compatible = "amlogic,g12a-usb2-phy"; - reg = <0x0 0x36000 0x0 0x2000>; - clocks = <&xtal>; - clock-names = "xtal"; - resets = <&reset RESET_USB_PHY21>; - reset-names = "phy"; - #phy-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt b/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt deleted file mode 100644 index 7cfc17e2df31..000000000000 --- a/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt +++ /dev/null @@ -1,22 +0,0 @@ -* Amlogic G12A USB3 + PCIE Combo PHY binding - -Required properties: -- compatible: Should be "amlogic,meson-g12a-usb3-pcie-phy" -- #phys-cells: must be 1. The cell number is used to select the phy mode - as defined in between PHY_TYPE_USB3 and PHY_TYPE_PCIE -- reg: The base address and length of the registers -- clocks: a phandle to the 100MHz reference clock of this PHY -- clock-names: must be "ref_clk" -- resets: phandle to the reset lines for the PHY control -- reset-names: must be "phy" - -Example: - usb3_pcie_phy: phy@46000 { - compatible = "amlogic,g12a-usb3-pcie-phy"; - reg = <0x0 0x46000 0x0 0x2000>; - clocks = <&clkc CLKID_PCIE_PLL>; - clock-names = "ref_clk"; - resets = <&reset RESET_PCIE_PHY>; - reset-names = "phy"; - #phy-cells = <1>; - }; diff --git a/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt b/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt index cf2cd86db267..8c60e6985950 100644 --- a/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt +++ b/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt @@ -25,6 +25,13 @@ Required properties: - #address-cells: should be 1. - #size-cells: should be 0. +Optional properlties: + +- clocks: pointers to the reference clocks for this device (CP110 only), + consequently: MG clock, MG Core clock, AXI clock. +- clock-names: names of used clocks for CP110 only, must be : + "mg_clk", "mg_core_clk" and "axi_clk". + A sub-node is required for each comphy lane provided by the comphy. Required properties (child nodes): @@ -39,6 +46,9 @@ Examples: compatible = "marvell,comphy-cp110"; reg = <0x120000 0x6000>; marvell,system-controller = <&cpm_syscon0>; + clocks = <&CP110_LABEL(clk) 1 5>, <&CP110_LABEL(clk) 1 6>, + <&CP110_LABEL(clk) 1 18>; + clock-names = "mg_clk", "mg_core_clk", "axi_clk"; #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt new file mode 100644 index 000000000000..d23ff90baad5 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt @@ -0,0 +1,28 @@ +NVIDIA Tegra194 P2U binding + +Tegra194 has two PHY bricks namely HSIO (High Speed IO) and NVHS (NVIDIA High +Speed) each interfacing with 12 and 8 P2U instances respectively. +A P2U instance is a glue logic between Synopsys DesignWare Core PCIe IP's PIPE +interface and PHY of HSIO/NVHS bricks. Each P2U instance represents one PCIe +lane. + +Required properties: +- compatible: For Tegra19x, must contain "nvidia,tegra194-p2u". +- reg: Should be the physical address space and length of respective each P2U + instance. +- reg-names: Must include the entry "ctl". + +Required properties for PHY port node: +- #phy-cells: Defined by generic PHY bindings. Must be 0. + +Refer to phy/phy-bindings.txt for the generic PHY binding properties. + +Example: + +p2u_hsio_0: phy@3e10000 { + compatible = "nvidia,tegra194-p2u"; + reg = <0x03e10000 0x10000>; + reg-names = "ctl"; + + #phy-cells = <0>; +}; diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml index 125599a2dc5e..39ad8657d018 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml @@ -15,16 +15,13 @@ description: |+ - compatible: Should be one of the following: "aspeed,ast2400-scu", "syscon", "simple-mfd" - "aspeed,g4-scu", "syscon", "simple-mfd" Refer to the the bindings described in Documentation/devicetree/bindings/mfd/syscon.txt properties: compatible: - enum: - - aspeed,ast2400-pinctrl - - aspeed,g4-pinctrl + const: aspeed,ast2400-pinctrl patternProperties: '^.*$': @@ -35,28 +32,24 @@ patternProperties: "^function|groups$": allOf: - $ref: "/schemas/types.yaml#/definitions/string" - - enum: [ "ACPI", "ADC0", "ADC1", "ADC10", "ADC11", "ADC12", "ADC13", - "ADC14", "ADC15", "ADC2", "ADC3", "ADC4", "ADC5", "ADC6", "ADC7", - "ADC8", "ADC9", "BMCINT", "DDCCLK", "DDCDAT", "EXTRST", "FLACK", - "FLBUSY", "FLWP", "GPID", "GPID0", "GPID2", "GPID4", "GPID6", - "GPIE0", "GPIE2", "GPIE4", "GPIE6", "I2C10", "I2C11", "I2C12", - "I2C13", "I2C14", "I2C3", "I2C4", "I2C5", "I2C6", "I2C7", "I2C8", - "I2C9", "LPCPD", "LPCPME", "LPCRST", "LPCSMI", "MAC1LINK", - "MAC2LINK", "MDIO1", "MDIO2", "NCTS1", "NCTS2", "NCTS3", "NCTS4", - "NDCD1", "NDCD2", "NDCD3", "NDCD4", "NDSR1", "NDSR2", "NDSR3", - "NDSR4", "NDTR1", "NDTR2", "NDTR3", "NDTR4", "NDTS4", "NRI1", - "NRI2", "NRI3", "NRI4", "NRTS1", "NRTS2", "NRTS3", "OSCCLK", - "PWM0", "PWM1", "PWM2", "PWM3", "PWM4", "PWM5", "PWM6", "PWM7", - "RGMII1", "RGMII2", "RMII1", "RMII2", "ROM16", "ROM8", "ROMCS1", - "ROMCS2", "ROMCS3", "ROMCS4", "RXD1", "RXD2", "RXD3", "RXD4", - "SALT1", "SALT2", "SALT3", "SALT4", "SD1", "SD2", "SGPMCK", - "SGPMI", "SGPMLD", "SGPMO", "SGPSCK", "SGPSI0", "SGPSI1", "SGPSLD", - "SIOONCTRL", "SIOPBI", "SIOPBO", "SIOPWREQ", "SIOPWRGD", "SIOS3", - "SIOS5", "SIOSCI", "SPI1", "SPI1DEBUG", "SPI1PASSTHRU", "SPICS1", - "TIMER3", "TIMER4", "TIMER5", "TIMER6", "TIMER7", "TIMER8", "TXD1", - "TXD2", "TXD3", "TXD4", "UART6", "USB11D1", "USB11H2", "USB2D1", - "USB2H1", "USBCKI", "VGABIOS_ROM", "VGAHS", "VGAVS", "VPI18", - "VPI24", "VPI30", "VPO12", "VPO24", "WDTRST1", "WDTRST2" ] + - enum: [ ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, + ADC15, ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, + DDCCLK, DDCDAT, EXTRST, FLACK, FLBUSY, FLWP, GPID, GPID0, GPID2, + GPID4, GPID6, GPIE0, GPIE2, GPIE4, GPIE6, I2C10, I2C11, I2C12, + I2C13, I2C14, I2C3, I2C4, I2C5, I2C6, I2C7, I2C8, I2C9, LPCPD, + LPCPME, LPCRST, LPCSMI, MAC1LINK, MAC2LINK, MDIO1, MDIO2, NCTS1, + NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, + NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NDTS4, NRI1, NRI2, + NRI3, NRI4, NRTS1, NRTS2, NRTS3, OSCCLK, PWM0, PWM1, PWM2, PWM3, + PWM4, PWM5, PWM6, PWM7, RGMII1, RGMII2, RMII1, RMII2, ROM16, + ROM8, ROMCS1, ROMCS2, ROMCS3, ROMCS4, RXD1, RXD2, RXD3, RXD4, + SALT1, SALT2, SALT3, SALT4, SD1, SD2, SGPMCK, SGPMI, SGPMLD, + SGPMO, SGPSCK, SGPSI0, SGPSI1, SGPSLD, SIOONCTRL, SIOPBI, SIOPBO, + SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1DEBUG, + SPI1PASSTHRU, SPICS1, TIMER3, TIMER4, TIMER5, TIMER6, TIMER7, + TIMER8, TXD1, TXD2, TXD3, TXD4, UART6, USB11D1, USB11H2, USB2D1, + USB2H1, USBCKI, VGABIOS_ROM, VGAHS, VGAVS, VPI18, VPI24, VPI30, + VPO12, VPO24, WDTRST1, WDTRST2 ] required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml index 3e6d85318577..3c6405be07ed 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml @@ -22,9 +22,7 @@ description: |+ properties: compatible: - enum: - - aspeed,ast2500-pinctrl - - aspeed,g5-pinctrl + const: aspeed,ast2500-pinctrl aspeed,external-nodes: minItems: 2 maxItems: 2 @@ -44,31 +42,26 @@ patternProperties: "^function|groups$": allOf: - $ref: "/schemas/types.yaml#/definitions/string" - - enum: [ "ACPI", "ADC0", "ADC1", "ADC10", "ADC11", "ADC12", "ADC13", - "ADC14", "ADC15", "ADC2", "ADC3", "ADC4", "ADC5", "ADC6", "ADC7", - "ADC8", "ADC9", "BMCINT", "DDCCLK", "DDCDAT", "ESPI", "FWSPICS1", - "FWSPICS2", "GPID0", "GPID2", "GPID4", "GPID6", "GPIE0", "GPIE2", - "GPIE4", "GPIE6", "I2C10", "I2C11", "I2C12", "I2C13", "I2C14", - "I2C3", "I2C4", "I2C5", "I2C6", "I2C7", "I2C8", "I2C9", "LAD0", - "LAD1", "LAD2", "LAD3", "LCLK", "LFRAME", "LPCHC", "LPCPD", - "LPCPLUS", "LPCPME", "LPCRST", "LPCSMI", "LSIRQ", "MAC1LINK", - "MAC2LINK", "MDIO1", "MDIO2", "NCTS1", "NCTS2", "NCTS3", "NCTS4", - "NDCD1", "NDCD2", "NDCD3", "NDCD4", "NDSR1", "NDSR2", "NDSR3", - "NDSR4", "NDTR1", "NDTR2", "NDTR3", "NDTR4", "NRI1", "NRI2", - "NRI3", "NRI4", "NRTS1", "NRTS2", "NRTS3", "NRTS4", "OSCCLK", - "PEWAKE", "PNOR", "PWM0", "PWM1", "PWM2", "PWM3", "PWM4", "PWM5", - "PWM6", "PWM7", "RGMII1", "RGMII2", "RMII1", "RMII2", "RXD1", - "RXD2", "RXD3", "RXD4", "SALT1", "SALT10", "SALT11", "SALT12", - "SALT13", "SALT14", "SALT2", "SALT3", "SALT4", "SALT5", "SALT6", - "SALT7", "SALT8", "SALT9", "SCL1", "SCL2", "SD1", "SD2", "SDA1", - "SDA2", "SGPS1", "SGPS2", "SIOONCTRL", "SIOPBI", "SIOPBO", - "SIOPWREQ", "SIOPWRGD", "SIOS3", "SIOS5", "SIOSCI", "SPI1", - "SPI1CS1", "SPI1DEBUG", "SPI1PASSTHRU", "SPI2CK", "SPI2CS0", - "SPI2CS1", "SPI2MISO", "SPI2MOSI", "TIMER3", "TIMER4", "TIMER5", - "TIMER6", "TIMER7", "TIMER8", "TXD1", "TXD2", "TXD3", "TXD4", - "UART6", "USB11BHID", "USB2AD", "USB2AH", "USB2BD", "USB2BH", - "USBCKI", "VGABIOSROM", "VGAHS", "VGAVS", "VPI24", "VPO", - "WDTRST1", "WDTRST2", ] + - enum: [ ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, + ADC15, ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, + DDCCLK, DDCDAT, ESPI, FWSPICS1, FWSPICS2, GPID0, GPID2, GPID4, + GPID6, GPIE0, GPIE2, GPIE4, GPIE6, I2C10, I2C11, I2C12, I2C13, + I2C14, I2C3, I2C4, I2C5, I2C6, I2C7, I2C8, I2C9, LAD0, LAD1, + LAD2, LAD3, LCLK, LFRAME, LPCHC, LPCPD, LPCPLUS, LPCPME, LPCRST, + LPCSMI, LSIRQ, MAC1LINK, MAC2LINK, MDIO1, MDIO2, NCTS1, NCTS2, + NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, NDSR3, + NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4, NRTS1, + NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, PNOR, PWM0, PWM1, PWM2, + PWM3, PWM4, PWM5, PWM6, PWM7, RGMII1, RGMII2, RMII1, RMII2, RXD1, + RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, SALT13, SALT14, + SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, SALT8, SALT9, SCL1, + SCL2, SD1, SD2, SDA1, SDA2, SGPS1, SGPS2, SIOONCTRL, SIOPBI, + SIOPBO, SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1CS1, + SPI1DEBUG, SPI1PASSTHRU, SPI2CK, SPI2CS0, SPI2CS1, SPI2MISO, + SPI2MOSI, TIMER3, TIMER4, TIMER5, TIMER6, TIMER7, TIMER8, TXD1, + TXD2, TXD3, TXD4, UART6, USB11BHID, USB2AD, USB2AH, USB2BD, + USB2BH, USBCKI, VGABIOSROM, VGAHS, VGAVS, VPI24, VPO, WDTRST1, + WDTRST2, ] required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml new file mode 100644 index 000000000000..f83d888176cc --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml @@ -0,0 +1,115 @@ +# SPDX-License-Identifier: GPL-2.0+ +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/aspeed,ast2600-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ASPEED AST2600 Pin Controller + +maintainers: + - Andrew Jeffery + +description: |+ + The pin controller node should be the child of a syscon node with the + required property: + + - compatible: Should be one of the following: + "aspeed,ast2600-scu", "syscon", "simple-mfd" + + Refer to the the bindings described in + Documentation/devicetree/bindings/mfd/syscon.txt + +properties: + compatible: + const: aspeed,ast2600-pinctrl + +patternProperties: + '^.*$': + if: + type: object + then: + properties: + function: + allOf: + - $ref: "/schemas/types.yaml#/definitions/string" + - enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, + ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, ESPI, + ESPIALT, FSI1, FSI2, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1, + GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, GPIU2, + GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, I2C1, I2C10, I2C11, I2C12, + I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, I2C4, I2C5, I2C6, I2C7, + I2C8, I2C9, I3C3, I3C4, I3C5, I3C6, JTAGM, LHPD, LHSIRQ, LPC, + LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ, MACLINK1, MACLINK2, + MACLINK3, MACLINK4, MDIO1, MDIO2, MDIO3, MDIO4, NCTS1, NCTS2, + NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, NDSR3, + NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4, NRTS1, + NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, PWM0, PWM1, PWM10, PWM11, + PWM12, PWM13, PWM14, PWM15, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, + PWM8, PWM9, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3, + RMII4, RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, + SALT13, SALT14, SALT15, SALT16, SALT2, SALT3, SALT4, SALT5, + SALT6, SALT7, SALT8, SALT9, SD1, SD2, SD3, SD3DAT4, SD3DAT5, + SD3DAT6, SD3DAT7, SGPM1, SGPS1, SIOONCTRL, SIOPBI, SIOPBO, + SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, SPI1CS1, + SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, + TACH12, TACH13, TACH14, TACH15, TACH2, TACH3, TACH4, TACH5, + TACH6, TACH7, TACH8, TACH9, THRU0, THRU1, THRU2, THRU3, TXD1, + TXD2, TXD3, TXD4, UART10, UART11, UART12, UART13, UART6, UART7, + UART8, UART9, VB, VGAHS, VGAVS, WDTRST1, WDTRST2, WDTRST3, + WDTRST4, ] + groups: + allOf: + - $ref: "/schemas/types.yaml#/definitions/string" + - enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, + ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, ESPI, + ESPIALT, FSI1, FSI2, FWSPIABR, FWSPID, FWQSPID, FWSPIWP, GPIT0, + GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, + GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, HVI3C3, HVI3C4, I2C1, + I2C10, I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, + I2C4, I2C5, I2C6, I2C7, I2C8, I2C9, I3C3, I3C4, I3C5, I3C6, + JTAGM, LHPD, LHSIRQ, LPC, LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ, + MACLINK1, MACLINK2, MACLINK3, MACLINK4, MDIO1, MDIO2, MDIO3, + MDIO4, NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, + NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, + NRI2, NRI3, NRI4, NRTS1, NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, + PWM0, PWM1, PWM10G0, PWM10G1, PWM11G0, PWM11G1, PWM12G0, PWM12G1, + PWM13G0, PWM13G1, PWM14G0, PWM14G1, PWM15G0, PWM15G1, PWM2, PWM3, + PWM4, PWM5, PWM6, PWM7, PWM8G0, PWM8G1, PWM9G0, PWM9G1, QSPI1, + QSPI2, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3, + RMII4, RXD1, RXD2, RXD3, RXD4, SALT1, SALT10G0, SALT10G1, + SALT11G0, SALT11G1, SALT12G0, SALT12G1, SALT13G0, SALT13G1, + SALT14G0, SALT14G1, SALT15G0, SALT15G1, SALT16G0, SALT16G1, + SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, SALT8, SALT9G0, + SALT9G1, SD1, SD2, SD3, SD3DAT4, SD3DAT5, SD3DAT6, SD3DAT7, + SGPM1, SGPS1, SIOONCTRL, SIOPBI, SIOPBO, SIOPWREQ, SIOPWRGD, + SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, SPI1CS1, SPI1WP, SPI2, + SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, TACH12, TACH13, + TACH14, TACH15, TACH2, TACH3, TACH4, TACH5, TACH6, TACH7, TACH8, + TACH9, THRU0, THRU1, THRU2, THRU3, TXD1, TXD2, TXD3, TXD4, + UART10, UART11, UART12G0, UART12G1, UART13G0, UART13G1, UART6, + UART7, UART8, UART9, VB, VGAHS, VGAVS, WDTRST1, WDTRST2, WDTRST3, + WDTRST4, ] + +required: + - compatible + +examples: + - | + syscon: scu@1e6e2000 { + compatible = "aspeed,ast2600-scu", "syscon", "simple-mfd"; + reg = <0x1e6e2000 0xf6c>; + + pinctrl: pinctrl { + compatible = "aspeed,g6-pinctrl"; + + pinctrl_pwm10g1_default: pwm10g1_default { + function = "PWM10"; + groups = "PWM10G1"; + }; + + pinctrl_gpioh0_unbiased_default: gpioh0 { + pins = "A18"; + bias-disable; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt index ac6d614d74e0..3cab7336a326 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt @@ -8,6 +8,7 @@ Required properties: - compatible: should be one of: "brcm,bcm2835-gpio" - BCM2835 compatible pinctrl "brcm,bcm7211-gpio" - BCM7211 compatible pinctrl + "brcm,bcm2711-gpio" - BCM2711 compatible pinctrl - reg: Should contain the physical address of the GPIO module's registers. - gpio-controller: Marks the device node as a GPIO controller. - #gpio-cells : Should be two. The first cell is the pin number and the diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt index af20b0ec715c..0014d9899797 100644 --- a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt @@ -1,18 +1,18 @@ -Ingenic jz47xx pin controller +Ingenic XBurst pin controller Please refer to pinctrl-bindings.txt in this directory for details of the common pinctrl bindings used by client devices, including the meaning of the phrase "pin configuration node". -For the jz47xx SoCs, pin control is tightly bound with GPIO ports. All pins may +For the XBurst SoCs, pin control is tightly bound with GPIO ports. All pins may be used as GPIOs, multiplexed device functions are configured within the GPIO port configuration registers and it is typical to refer to pins using the naming scheme "PxN" where x is a character identifying the GPIO port with which the pin is associated and N is an integer from 0 to 31 identifying the pin within that GPIO port. For example PA0 is the first pin in GPIO port A, and -PB31 is the last pin in GPIO port B. The jz4740 contains 4 GPIO ports, PA to -PD, for a total of 128 pins. The jz4780 contains 6 GPIO ports, PA to PF, for a -total of 192 pins. +PB31 is the last pin in GPIO port B. The jz4740 and the x1000 contains 4 GPIO +ports, PA to PD, for a total of 128 pins. The jz4760, the jz4770 and the jz4780 +contains 6 GPIO ports, PA to PF, for a total of 192 pins. Required properties: @@ -21,8 +21,13 @@ Required properties: - compatible: One of: - "ingenic,jz4740-pinctrl" - "ingenic,jz4725b-pinctrl" + - "ingenic,jz4760-pinctrl" + - "ingenic,jz4760b-pinctrl" - "ingenic,jz4770-pinctrl" - "ingenic,jz4780-pinctrl" + - "ingenic,x1000-pinctrl" + - "ingenic,x1000e-pinctrl" + - "ingenic,x1500-pinctrl" - reg: Address range of the pinctrl registers. @@ -31,8 +36,10 @@ Required properties for sub-nodes (GPIO chips): - compatible: Must contain one of: - "ingenic,jz4740-gpio" + - "ingenic,jz4760-gpio" - "ingenic,jz4770-gpio" - "ingenic,jz4780-gpio" + - "ingenic,x1000-gpio" - reg: The GPIO bank number. - interrupt-controller: Marks the device node as an interrupt controller. - interrupts: Interrupt specifier for the controllers interrupt. diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt index 625a22e2f211..8b94aa8f5971 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt @@ -82,7 +82,7 @@ gpiom1: gpio@0 { compatible = "microchip,mcp23s17"; gpio-controller; #gpio-cells = <2>; - spi-present-mask = <0x01>; + microchip,spi-present-mask = <0x01>; reg = <0>; spi-max-frequency = <1000000>; }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.txt index cdec1eeb2799..c4de930f2406 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.txt @@ -132,9 +132,8 @@ to specify in a pin configuration subnode: qlink_request, qua_mi2s, sd_card, sd_write, sdc40, sdc41, sdc42, sdc43, sdc4_clk, sdc4_cmd, sec_mi2s, sp_cmu, spkr_i2s, ssbi1, ssc_irq, ter_mi2s, tgu_ch0, tgu_ch1, - tsense_pwm1, tsense_pwm2, tsif1_clk, tsif1_data, tsif1_en, - tsif1_error, tsif1_sync, tsif2_clk, tsif2_data, tsif2_en, - tsif2_error, tsif2_sync, uim1_clk, uim1_data, uim1_present, + tsense_pwm1, tsense_pwm2, tsif0, tsif1, + uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk, uim2_data, uim2_present, uim2_reset, uim_batt, usb_phy, vfr_1, vsense_clkout, vsense_data0, vsense_data1, vsense_mode, wlan1_adc0, wlan1_adc1, diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt index 7f64a7e92c28..c32bf3237545 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt @@ -21,6 +21,8 @@ PMIC's from Qualcomm. "qcom,pmi8994-gpio" "qcom,pmi8998-gpio" "qcom,pms405-gpio" + "qcom,pm8150-gpio" + "qcom,pm8150b-gpio" And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio" if the device is on an spmi bus or an ssbi bus respectively @@ -94,6 +96,10 @@ to specify in a pin configuration subnode: gpio1-gpio22 for pma8084 gpio1-gpio10 for pmi8994 gpio1-gpio12 for pms405 (holes on gpio1, gpio9 and gpio10) + gpio1-gpio10 for pm8150 (holes on gpio2, gpio5, gpio7 + and gpio8) + gpio1-gpio12 for pm8150b (holes on gpio3, gpio4, gpio7) + gpio1-gpio12 for pm8150l (hole on gpio7) - function: Usage: required diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.txt new file mode 100644 index 000000000000..b5767ee82ee6 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.txt @@ -0,0 +1,186 @@ +Qualcomm Technologies, Inc. SC7180 TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +SC7180 platform. + +- compatible: + Usage: required + Value type: + Definition: must be "qcom,sc7180-pinctrl" + +- reg: + Usage: required + Value type: + Definition: the base address and size of the north, south and west + TLMM tiles + +- reg-names: + Usage: required + Value type: + Definition: names for the cells of reg, must contain "north", "south" + and "west". + +- interrupts: + Usage: required + Value type: + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +- gpio-controller: + Usage: required + Value type: + Definition: identifies this node as a gpio controller + +- #gpio-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +- gpio-ranges: + Usage: required + Value type: + Definition: see ../gpio/gpio.txt + +- gpio-reserved-ranges: + Usage: optional + Value type: + Definition: see ../gpio/gpio.txt + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: + Definition: List of gpio pins affected by the properties specified in + this subnode. + + Valid pins are: + gpio0-gpio118 + Supports mux, bias and drive-strength + + sdc1_clk, sdc1_cmd, sdc1_data sdc2_clk, sdc2_cmd, + sdc2_data sdc1_rclk + Supports bias and drive-strength + + ufs_reset + Supports bias and drive-strength + +- function: + Usage: required + Value type: + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + + adsp_ext, agera_pll, aoss_cti, atest_char, atest_char0, + atest_char1, atest_char2, atest_char3, atest_tsens, + atest_tsens2, atest_usb1, atest_usb10, atest_usb11, + atest_usb12, atest_usb13, atest_usb2, atest_usb20, + atest_usb21, atest_usb22, atest_usb23, audio_ref, + btfm_slimbus, cam_mclk, cci_async, cci_i2c, cci_timer0, + cci_timer1, cci_timer2, cci_timer3, cci_timer4, + cri_trng, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1, + ddr_pxi2, ddr_pxi3, dp_hot, edp_lcd, gcc_gp1, gcc_gp2, + gcc_gp3, gpio, gp_pdm0, gp_pdm1, gp_pdm2, gps_tx, + jitter_bist, ldo_en, ldo_update, lpass_ext, mdp_vsync, + mdp_vsync0, mdp_vsync1, mdp_vsync2, mdp_vsync3, mi2s_0, + mi2s_1, mi2s_2, mss_lte, m_voc, pa_indicator, phase_flag, + PLL_BIST, pll_bypassnl, pll_reset, prng_rosc, qdss, + qdss_cti, qlink_enable, qlink_request, qspi_clk, qspi_cs, + qspi_data, qup00, qup01, qup02, qup03, qup04, qup05, + qup10, qup11, qup12, qup13, qup14, qup15, sdc1_tb, + sdc2_tb, sd_write, sp_cmu, tgu_ch0, tgu_ch1, tgu_ch2, + tgu_ch3, tsense_pwm1, tsense_pwm2, uim1, uim2, uim_batt, + usb_phy, vfr_1, _V_GPIO, _V_PPS_IN, _V_PPS_OUT, + vsense_trigger, wlan1_adc0, wlan1_adc1, wlan2_adc0, + wlan2_adc1, + +- bias-disable: + Usage: optional + Value type: + Definition: The specified pins should be configured as no pull. + +- bias-pull-down: + Usage: optional + Value type: + Definition: The specified pins should be configured as pull down. + +- bias-pull-up: + Usage: optional + Value type: + Definition: The specified pins should be configured as pull up. + +- output-high: + Usage: optional + Value type: + Definition: The specified pins are configured in output mode, driven + high. + Not valid for sdc pins. + +- output-low: + Usage: optional + Value type: + Definition: The specified pins are configured in output mode, driven + low. + Not valid for sdc pins. + +- drive-strength: + Usage: optional + Value type: + Definition: Selects the drive strength for the specified pins, in mA. + Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16 + +Example: + + tlmm: pinctrl@3500000 { + compatible = "qcom,sc7180-pinctrl"; + reg = <0x3500000 0x300000>, + <0x3900000 0x300000>, + <0x3D00000 0x300000>; + reg-names = "west", "north", "south"; + interrupts = ; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&tlmm 0 0 119>; + gpio-reserved-ranges = <0 4>, <106 4>; + interrupt-controller; + #interrupt-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml index 91d3e78b3395..400df2da018a 100644 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml @@ -37,7 +37,8 @@ properties: hwlocks: true st,syscfg: - $ref: "/schemas/types.yaml#/definitions/phandle-array" + allOf: + - $ref: "/schemas/types.yaml#/definitions/phandle-array" description: Should be phandle/offset/mask items: - description: Phandle to the syscon node which includes IRQ mux selection. diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml new file mode 100644 index 000000000000..aab70e8b681e --- /dev/null +++ b/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml @@ -0,0 +1,93 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 BayLibre, SAS +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/power/amlogic,meson-ee-pwrc.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic Meson Everything-Else Power Domains + +maintainers: + - Neil Armstrong + +description: |+ + The Everything-Else Power Domains node should be the child of a syscon + node with the required property: + + - compatible: Should be the following: + "amlogic,meson-gx-hhi-sysctrl", "simple-mfd", "syscon" + + Refer to the the bindings described in + Documentation/devicetree/bindings/mfd/syscon.txt + +properties: + compatible: + enum: + - amlogic,meson-g12a-pwrc + - amlogic,meson-sm1-pwrc + + clocks: + minItems: 2 + + clock-names: + items: + - const: vpu + - const: vapb + + resets: + minItems: 11 + + reset-names: + items: + - const: viu + - const: venc + - const: vcbus + - const: bt656 + - const: rdma + - const: venci + - const: vencp + - const: vdac + - const: vdi6 + - const: vencl + - const: vid_lock + + "#power-domain-cells": + const: 1 + + amlogic,ao-sysctrl: + description: phandle to the AO sysctrl node + allOf: + - $ref: /schemas/types.yaml#/definitions/phandle + +required: + - compatible + - clocks + - clock-names + - resets + - reset-names + - "#power-domain-cells" + - amlogic,ao-sysctrl + +examples: + - | + pwrc: power-controller { + compatible = "amlogic,meson-sm1-pwrc"; + #power-domain-cells = <1>; + amlogic,ao-sysctrl = <&rti>; + resets = <&reset_viu>, + <&reset_venc>, + <&reset_vcbus>, + <&reset_bt656>, + <&reset_rdma>, + <&reset_venci>, + <&reset_vencp>, + <&reset_vdac>, + <&reset_vdi6>, + <&reset_vencl>, + <&reset_vid_lock>; + reset-names = "viu", "venc", "vcbus", "bt656", + "rdma", "venci", "vencp", "vdac", + "vdi6", "vencl", "vid_lock"; + clocks = <&clk_vpu>, <&clk_vapb>; + clock-names = "vpu", "vapb"; + }; diff --git a/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt b/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt new file mode 100644 index 000000000000..933f0c48e887 --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt @@ -0,0 +1,20 @@ +Device Tree Bindings for Power Controller on MediaTek PMIC + +The power controller which could be found on PMIC is responsible for externally +powering off or on the remote MediaTek SoC through the circuit BBPU. + +Required properties: +- compatible: Should be one of follows + "mediatek,mt6323-pwrc": for MT6323 PMIC + +Example: + + pmic { + compatible = "mediatek,mt6323"; + + ... + + power-controller { + compatible = "mediatek,mt6323-pwrc"; + }; + } diff --git a/Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt b/Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt deleted file mode 100644 index 493bec80d59b..000000000000 --- a/Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt +++ /dev/null @@ -1,22 +0,0 @@ -Ingenic JZ47xx PWM Controller -============================= - -Required properties: -- compatible: Should be "ingenic,jz4740-pwm" -- #pwm-cells: Should be 3. See pwm.txt in this directory for a description - of the cells format. -- clocks : phandle to the external clock. -- clock-names : Should be "ext". - - -Example: - - pwm: pwm@10002000 { - compatible = "ingenic,jz4740-pwm"; - reg = <0x10002000 0x1000>; - - #pwm-cells = <3>; - - clocks = <&ext>; - clock-names = "ext"; - }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt index 991728cb46cb..c8501530173c 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt @@ -6,6 +6,8 @@ Required properties: - "mediatek,mt7622-pwm": found on mt7622 SoC. - "mediatek,mt7623-pwm": found on mt7623 SoC. - "mediatek,mt7628-pwm": found on mt7628 SoC. + - "mediatek,mt7629-pwm", "mediatek,mt7622-pwm": found on mt7629 SoC. + - "mediatek,mt8516-pwm": found on mt8516 SoC. - reg: physical base address and length of the controller's registers. - #pwm-cells: must be 2. See pwm.txt in this directory for a description of the cell format. diff --git a/Documentation/devicetree/bindings/pwm/pwm-sprd.txt b/Documentation/devicetree/bindings/pwm/pwm-sprd.txt new file mode 100644 index 000000000000..16fa5a096206 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-sprd.txt @@ -0,0 +1,40 @@ +Spreadtrum PWM controller + +Spreadtrum SoCs PWM controller provides 4 PWM channels. + +Required properties: +- compatible : Should be "sprd,ums512-pwm". +- reg: Physical base address and length of the controller's registers. +- clocks: The phandle and specifier referencing the controller's clocks. +- clock-names: Should contain following entries: + "pwmn": used to derive the functional clock for PWM channel n (n range: 0 ~ 3). + "enablen": for PWM channel n enable clock (n range: 0 ~ 3). +- #pwm-cells: Should be 2. See pwm.txt in this directory for a description of + the cells format. + +Optional properties: +- assigned-clocks: Reference to the PWM clock entries. +- assigned-clock-parents: The phandle of the parent clock of PWM clock. + +Example: + pwms: pwm@32260000 { + compatible = "sprd,ums512-pwm"; + reg = <0 0x32260000 0 0x10000>; + clock-names = "pwm0", "enable0", + "pwm1", "enable1", + "pwm2", "enable2", + "pwm3", "enable3"; + clocks = <&aon_clk CLK_PWM0>, <&aonapb_gate CLK_PWM0_EB>, + <&aon_clk CLK_PWM1>, <&aonapb_gate CLK_PWM1_EB>, + <&aon_clk CLK_PWM2>, <&aonapb_gate CLK_PWM2_EB>, + <&aon_clk CLK_PWM3>, <&aonapb_gate CLK_PWM3_EB>; + assigned-clocks = <&aon_clk CLK_PWM0>, + <&aon_clk CLK_PWM1>, + <&aon_clk CLK_PWM2>, + <&aon_clk CLK_PWM3>; + assigned-clock-parents = <&ext_26m>, + <&ext_26m>, + <&ext_26m>, + <&ext_26m>; + #pwm-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt index 3ae9f1088845..b9f58e480349 100644 --- a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt @@ -34,6 +34,9 @@ Optional input supply properties: - inl67-supply: The input supply for LDO_REG3 and LDO_REG4 Any standard regulator properties can be used to configure the single regulator. +regulator-initial-mode, regulator-allowed-modes and regulator-mode could be specified +for act8865 using mode values from dt-bindings/regulator/active-semi,8865-regulator.h +file. The valid names for regulators are: - for act8846: @@ -47,6 +50,8 @@ The valid names for regulators are: Example: -------- +#include + i2c1: i2c@f0018000 { pmic: act8865@5b { compatible = "active-semi,act8865"; @@ -65,9 +70,19 @@ Example: regulator-name = "VCC_1V2"; regulator-min-microvolt = <1100000>; regulator-max-microvolt = <1300000>; - regulator-suspend-mem-microvolt = <1150000>; - regulator-suspend-standby-microvolt = <1150000>; regulator-always-on; + + regulator-allowed-modes = , + ; + regulator-initial-mode = ; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-min-microvolt = <1150000>; + regulator-suspend-max-microvolt = <1150000>; + regulator-changeable-in-suspend; + regulator-mode = ; + }; }; vcc_3v3_reg: DCDC_REG3 { @@ -82,6 +97,14 @@ Example: regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; regulator-always-on; + + regulator-allowed-modes = , + ; + regulator-initial-mode = ; + + regulator-state-mem { + regulator-off-in-suspend; + }; }; vddfuse_reg: LDO_REG2 { diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml index a650b457085d..a78150c47aa2 100644 --- a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml @@ -19,9 +19,19 @@ description: allOf: - $ref: "regulator.yaml#" +if: + properties: + compatible: + contains: + const: regulator-fixed-clock + required: + - clocks + properties: compatible: - const: regulator-fixed + enum: + - const: regulator-fixed + - const: regulator-fixed-clock regulator-name: true @@ -29,6 +39,13 @@ properties: description: gpio to use for enable control maxItems: 1 + clocks: + description: + clock to use for enable control. This binding is only available if + the compatible is chosen to regulator-fixed-clock. The clock binding + is mandatory if compatible is chosen to regulator-fixed-clock. + maxItems: 1 + startup-delay-us: description: startup time in microseconds $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt new file mode 100644 index 000000000000..9a90a92f2d7e --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt @@ -0,0 +1,358 @@ +MediaTek MT6358 Regulator + +All voltage regulators provided by the MT6358 PMIC are described as the +subnodes of the MT6358 regulators node. Each regulator is named according +to its regulator type, buck_ and ldo_. The definition for each +of these nodes is defined using the standard binding for regulators at +Documentation/devicetree/bindings/regulator/regulator.txt. + +The valid names for regulators are:: +BUCK: + buck_vdram1, buck_vcore, buck_vpa, buck_vproc11, buck_vproc12, buck_vgpu, + buck_vs2, buck_vmodem, buck_vs1 +LDO: + ldo_vdram2, ldo_vsim1, ldo_vibr, ldo_vrf12, ldo_vio18, ldo_vusb, ldo_vcamio, + ldo_vcamd, ldo_vcn18, ldo_vfe28, ldo_vsram_proc11, ldo_vcn28, ldo_vsram_others, + ldo_vsram_gpu, ldo_vxo22, ldo_vefuse, ldo_vaux18, ldo_vmch, ldo_vbif28, + ldo_vsram_proc12, ldo_vcama1, ldo_vemc, ldo_vio28, ldo_va12, ldo_vrf18, + ldo_vcn33_bt, ldo_vcn33_wifi, ldo_vcama2, ldo_vmc, ldo_vldo28, ldo_vaud28, + ldo_vsim2 + +Example: + + pmic { + compatible = "mediatek,mt6358"; + + mt6358regulator: mt6358regulator { + compatible = "mediatek,mt6358-regulator"; + + mt6358_vdram1_reg: buck_vdram1 { + regulator-compatible = "buck_vdram1"; + regulator-name = "vdram1"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <2087500>; + regulator-ramp-delay = <12500>; + regulator-enable-ramp-delay = <0>; + regulator-always-on; + }; + + mt6358_vcore_reg: buck_vcore { + regulator-name = "vcore"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1293750>; + regulator-ramp-delay = <6250>; + regulator-enable-ramp-delay = <200>; + regulator-always-on; + }; + + mt6358_vpa_reg: buck_vpa { + regulator-name = "vpa"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3650000>; + regulator-ramp-delay = <50000>; + regulator-enable-ramp-delay = <250>; + }; + + mt6358_vproc11_reg: buck_vproc11 { + regulator-name = "vproc11"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1293750>; + regulator-ramp-delay = <6250>; + regulator-enable-ramp-delay = <200>; + regulator-always-on; + }; + + mt6358_vproc12_reg: buck_vproc12 { + regulator-name = "vproc12"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1293750>; + regulator-ramp-delay = <6250>; + regulator-enable-ramp-delay = <200>; + regulator-always-on; + }; + + mt6358_vgpu_reg: buck_vgpu { + regulator-name = "vgpu"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1293750>; + regulator-ramp-delay = <6250>; + regulator-enable-ramp-delay = <200>; + }; + + mt6358_vs2_reg: buck_vs2 { + regulator-name = "vs2"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <2087500>; + regulator-ramp-delay = <12500>; + regulator-enable-ramp-delay = <0>; + regulator-always-on; + }; + + mt6358_vmodem_reg: buck_vmodem { + regulator-name = "vmodem"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1293750>; + regulator-ramp-delay = <6250>; + regulator-enable-ramp-delay = <900>; + regulator-always-on; + }; + + mt6358_vs1_reg: buck_vs1 { + regulator-name = "vs1"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <2587500>; + regulator-ramp-delay = <12500>; + regulator-enable-ramp-delay = <0>; + regulator-always-on; + }; + + mt6358_vdram2_reg: ldo_vdram2 { + regulator-name = "vdram2"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <1800000>; + regulator-enable-ramp-delay = <3300>; + }; + + mt6358_vsim1_reg: ldo_vsim1 { + regulator-name = "vsim1"; + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <3100000>; + regulator-enable-ramp-delay = <540>; + }; + + mt6358_vibr_reg: ldo_vibr { + regulator-name = "vibr"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3300000>; + regulator-enable-ramp-delay = <60>; + }; + + mt6358_vrf12_reg: ldo_vrf12 { + compatible = "regulator-fixed"; + regulator-name = "vrf12"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + regulator-enable-ramp-delay = <120>; + }; + + mt6358_vio18_reg: ldo_vio18 { + compatible = "regulator-fixed"; + regulator-name = "vio18"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-enable-ramp-delay = <2700>; + regulator-always-on; + }; + + mt6358_vusb_reg: ldo_vusb { + regulator-name = "vusb"; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3100000>; + regulator-enable-ramp-delay = <270>; + regulator-always-on; + }; + + mt6358_vcamio_reg: ldo_vcamio { + compatible = "regulator-fixed"; + regulator-name = "vcamio"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-enable-ramp-delay = <270>; + }; + + mt6358_vcamd_reg: ldo_vcamd { + regulator-name = "vcamd"; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <1800000>; + regulator-enable-ramp-delay = <270>; + }; + + mt6358_vcn18_reg: ldo_vcn18 { + compatible = "regulator-fixed"; + regulator-name = "vcn18"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-enable-ramp-delay = <270>; + }; + + mt6358_vfe28_reg: ldo_vfe28 { + compatible = "regulator-fixed"; + regulator-name = "vfe28"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + regulator-enable-ramp-delay = <270>; + }; + + mt6358_vsram_proc11_reg: ldo_vsram_proc11 { + regulator-name = "vsram_proc11"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1293750>; + regulator-ramp-delay = <6250>; + regulator-enable-ramp-delay = <240>; + regulator-always-on; + }; + + mt6358_vcn28_reg: ldo_vcn28 { + compatible = "regulator-fixed"; + regulator-name = "vcn28"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + regulator-enable-ramp-delay = <270>; + }; + + mt6358_vsram_others_reg: ldo_vsram_others { + regulator-name = "vsram_others"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1293750>; + regulator-ramp-delay = <6250>; + regulator-enable-ramp-delay = <240>; + regulator-always-on; + }; + + mt6358_vsram_gpu_reg: ldo_vsram_gpu { + regulator-name = "vsram_gpu"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1293750>; + regulator-ramp-delay = <6250>; + regulator-enable-ramp-delay = <240>; + }; + + mt6358_vxo22_reg: ldo_vxo22 { + compatible = "regulator-fixed"; + regulator-name = "vxo22"; + regulator-min-microvolt = <2200000>; + regulator-max-microvolt = <2200000>; + regulator-enable-ramp-delay = <120>; + regulator-always-on; + }; + + mt6358_vefuse_reg: ldo_vefuse { + regulator-name = "vefuse"; + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <1900000>; + regulator-enable-ramp-delay = <270>; + }; + + mt6358_vaux18_reg: ldo_vaux18 { + compatible = "regulator-fixed"; + regulator-name = "vaux18"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-enable-ramp-delay = <270>; + }; + + mt6358_vmch_reg: ldo_vmch { + regulator-name = "vmch"; + regulator-min-microvolt = <2900000>; + regulator-max-microvolt = <3300000>; + regulator-enable-ramp-delay = <60>; + }; + + mt6358_vbif28_reg: ldo_vbif28 { + compatible = "regulator-fixed"; + regulator-name = "vbif28"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + regulator-enable-ramp-delay = <270>; + }; + + mt6358_vsram_proc12_reg: ldo_vsram_proc12 { + regulator-name = "vsram_proc12"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1293750>; + regulator-ramp-delay = <6250>; + regulator-enable-ramp-delay = <240>; + regulator-always-on; + }; + + mt6358_vcama1_reg: ldo_vcama1 { + regulator-name = "vcama1"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3000000>; + regulator-enable-ramp-delay = <270>; + }; + + mt6358_vemc_reg: ldo_vemc { + regulator-name = "vemc"; + regulator-min-microvolt = <2900000>; + regulator-max-microvolt = <3300000>; + regulator-enable-ramp-delay = <60>; + regulator-always-on; + }; + + mt6358_vio28_reg: ldo_vio28 { + compatible = "regulator-fixed"; + regulator-name = "vio28"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + regulator-enable-ramp-delay = <270>; + }; + + mt6358_va12_reg: ldo_va12 { + compatible = "regulator-fixed"; + regulator-name = "va12"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + regulator-enable-ramp-delay = <270>; + regulator-always-on; + }; + + mt6358_vrf18_reg: ldo_vrf18 { + compatible = "regulator-fixed"; + regulator-name = "vrf18"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-enable-ramp-delay = <120>; + }; + + mt6358_vcn33_bt_reg: ldo_vcn33_bt { + regulator-name = "vcn33_bt"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3500000>; + regulator-enable-ramp-delay = <270>; + }; + + mt6358_vcn33_wifi_reg: ldo_vcn33_wifi { + regulator-name = "vcn33_wifi"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3500000>; + regulator-enable-ramp-delay = <270>; + }; + + mt6358_vcama2_reg: ldo_vcama2 { + regulator-name = "vcama2"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3000000>; + regulator-enable-ramp-delay = <270>; + }; + + mt6358_vmc_reg: ldo_vmc { + regulator-name = "vmc"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-enable-ramp-delay = <60>; + }; + + mt6358_vldo28_reg: ldo_vldo28 { + regulator-name = "vldo28"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <3000000>; + regulator-enable-ramp-delay = <270>; + }; + + mt6358_vaud28_reg: ldo_vaud28 { + compatible = "regulator-fixed"; + regulator-name = "vaud28"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + regulator-enable-ramp-delay = <270>; + }; + + mt6358_vsim2_reg: ldo_vsim2 { + regulator-name = "vsim2"; + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <3100000>; + regulator-enable-ramp-delay = <540>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt index 14d2eee96b3d..bab9f71140b8 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt @@ -22,9 +22,12 @@ RPMh resource. The names used for regulator nodes must match those supported by a given PMIC. Supported regulator node names: + PM8005: smps1 - smps4 + PM8009: smps1 - smps2, ldo1 - ldo7 + PM8150: smps1 - smps10, ldo1 - ldo18 + PM8150L: smps1 - smps8, ldo1 - ldo11, bob, flash, rgb PM8998: smps1 - smps13, ldo1 - ldo28, lvs1 - lvs2 PMI8998: bob - PM8005: smps1 - smps4 ======================== First Level Nodes - PMIC @@ -33,9 +36,13 @@ First Level Nodes - PMIC - compatible Usage: required Value type: - Definition: Must be one of: "qcom,pm8998-rpmh-regulators", - "qcom,pmi8998-rpmh-regulators" or - "qcom,pm8005-rpmh-regulators". + Definition: Must be one of below: + "qcom,pm8005-rpmh-regulators" + "qcom,pm8009-rpmh-regulators" + "qcom,pm8150-rpmh-regulators" + "qcom,pm8150l-rpmh-regulators" + "qcom,pm8998-rpmh-regulators" + "qcom,pmi8998-rpmh-regulators" - qcom,pmic-id Usage: required diff --git a/Documentation/devicetree/bindings/regulator/sy8824x.txt b/Documentation/devicetree/bindings/regulator/sy8824x.txt new file mode 100644 index 000000000000..c5e95850c427 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/sy8824x.txt @@ -0,0 +1,24 @@ +SY8824C/SY8824E/SY20276 Voltage regulator + +Required properties: +- compatible: Must be one of the following. + "silergy,sy8824c" + "silergy,sy8824e" + "silergy,sy20276" + "silergy,sy20278" +- reg: I2C slave address + +Any property defined as part of the core regulator binding, defined in +./regulator.txt, can also be used. + +Example: + + vcore: regulator@00 { + compatible = "silergy,sy8824c"; + reg = <0x66>; + regulator-name = "vcore"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1150000>; + regulator-boot-on; + regulator-always-on; + }; diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt b/Documentation/devicetree/bindings/regulator/twl-regulator.txt index 74a91c4f8530..549f80436deb 100644 --- a/Documentation/devicetree/bindings/regulator/twl-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt @@ -71,3 +71,10 @@ Example: regulator-min-microvolt = <1000000>; regulator-max-microvolt = <3000000>; }; + +For twl6030 regulators/LDOs: + + - ti,retain-on-reset: Does not turn off the supplies during warm + reset. Could be needed for VMMC, as TWL6030 + reset sequence for this signal does not comply + with the SD specification. diff --git a/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt b/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt index c9919f4b92d2..94fd38b0d163 100644 --- a/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt @@ -13,6 +13,7 @@ this layer. These clocks and resets should be described in each property. Required properties: - compatible: Should be "socionext,uniphier-pro4-usb3-regulator" - for Pro4 SoC + "socionext,uniphier-pro5-usb3-regulator" - for Pro5 SoC "socionext,uniphier-pxs2-usb3-regulator" - for PXs2 SoC "socionext,uniphier-ld20-usb3-regulator" - for LD20 SoC "socionext,uniphier-pxs3-usb3-regulator" - for PXs3 SoC @@ -20,12 +21,12 @@ Required properties: - clocks: A list of phandles to the clock gate for USB3 glue layer. According to the clock-names, appropriate clocks are required. - clock-names: Should contain - "gio", "link" - for Pro4 SoC + "gio", "link" - for Pro4 and Pro5 SoCs "link" - for others - resets: A list of phandles to the reset control for USB3 glue layer. According to the reset-names, appropriate resets are required. - reset-names: Should contain - "gio", "link" - for Pro4 SoC + "gio", "link" - for Pro4 and Pro5 SoCs "link" - for others See Documentation/devicetree/bindings/regulator/regulator.txt diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt deleted file mode 100644 index 28ef6c295c76..000000000000 --- a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt +++ /dev/null @@ -1,19 +0,0 @@ -Amlogic Meson SoC Reset Controller -======================================= - -Please also refer to reset.txt in this directory for common reset -controller binding usage. - -Required properties: -- compatible: Should be "amlogic,meson8b-reset", "amlogic,meson-gxbb-reset" or - "amlogic,meson-axg-reset". -- reg: should contain the register address base -- #reset-cells: 1, see below - -example: - -reset: reset-controller { - compatible = "amlogic,meson-gxbb-reset"; - reg = <0x0 0x04404 0x0 0x20>; - #reset-cells = <1>; -}; diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml new file mode 100644 index 000000000000..00917d868d58 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 BayLibre, SAS +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/reset/amlogic,meson-reset.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic Meson SoC Reset Controller + +maintainers: + - Neil Armstrong + +properties: + compatible: + enum: + - amlogic,meson8b-reset # Reset Controller on Meson8b and compatible SoCs + - amlogic,meson-gxbb-reset # Reset Controller on GXBB and compatible SoCs + - amlogic,meson-axg-reset # Reset Controller on AXG and compatible SoCs + + reg: + maxItems: 1 + + "#reset-cells": + const: 1 + +required: + - compatible + - reg + - "#reset-cells" + +examples: + - | + reset-controller@c884404 { + compatible = "amlogic,meson-gxbb-reset"; + reg = <0xc884404 0x20>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt b/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt index 13e095182db4..c2489e41a801 100644 --- a/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt +++ b/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt @@ -8,6 +8,7 @@ Required properties: - compatible: - For i.MX7 SoCs should be "fsl,imx7d-src", "syscon" - For i.MX8MQ SoCs should be "fsl,imx8mq-src", "syscon" + - For i.MX8MM SoCs should be "fsl,imx8mm-src", "fsl,imx8mq-src", "syscon" - reg: should be register base and length as documented in the datasheet - interrupts: Should contain SRC interrupt @@ -46,5 +47,6 @@ Example: For list of all valid reset indices see - for i.MX7 and - for i.MX8MQ + for i.MX7, + for i.MX8MQ and + for i.MX8MM diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt index c25da39df707..ea0a6a9734c1 100644 --- a/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt +++ b/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt @@ -11,6 +11,7 @@ Required properties: - compatible: should be one of the following: - "hisilicon,hi6220-sysctrl", "syscon" : For peripheral reset controller. - "hisilicon,hi6220-mediactrl", "syscon" : For media reset controller. + - "hisilicon,hi6220-aoctrl", "syscon" : For ao reset controller. - reg: should be register base and length as documented in the datasheet - #reset-cells: 1, see below diff --git a/Documentation/devicetree/bindings/reset/snps,dw-reset.txt b/Documentation/devicetree/bindings/reset/snps,dw-reset.txt new file mode 100644 index 000000000000..f94f911dd98d --- /dev/null +++ b/Documentation/devicetree/bindings/reset/snps,dw-reset.txt @@ -0,0 +1,30 @@ +Synopsys DesignWare Reset controller +======================================= + +Please also refer to reset.txt in this directory for common reset +controller binding usage. + +Required properties: + +- compatible: should be one of the following. + "snps,dw-high-reset" - for active high configuration + "snps,dw-low-reset" - for active low configuration + +- reg: physical base address of the controller and length of memory mapped + region. + +- #reset-cells: must be 1. + +example: + + dw_rst_1: reset-controller@0000 { + compatible = "snps,dw-high-reset"; + reg = <0x0000 0x4>; + #reset-cells = <1>; + }; + + dw_rst_2: reset-controller@1000 {i + compatible = "snps,dw-low-reset"; + reg = <0x1000 0x8>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/riscv/cpus.txt b/Documentation/devicetree/bindings/riscv/cpus.txt deleted file mode 100644 index adf7b7af5dc3..000000000000 --- a/Documentation/devicetree/bindings/riscv/cpus.txt +++ /dev/null @@ -1,162 +0,0 @@ -=================== -RISC-V CPU Bindings -=================== - -The device tree allows to describe the layout of CPUs in a system through -the "cpus" node, which in turn contains a number of subnodes (ie "cpu") -defining properties for every cpu. - -Bindings for CPU nodes follow the Devicetree Specification, available from: - -https://www.devicetree.org/specifications/ - -with updates for 32-bit and 64-bit RISC-V systems provided in this document. - -=========== -Terminology -=========== - -This document uses some terminology common to the RISC-V community that is not -widely used, the definitions of which are listed here: - -* hart: A hardware execution context, which contains all the state mandated by - the RISC-V ISA: a PC and some registers. This terminology is designed to - disambiguate software's view of execution contexts from any particular - microarchitectural implementation strategy. For example, my Intel laptop is - described as having one socket with two cores, each of which has two hyper - threads. Therefore this system has four harts. - -===================================== -cpus and cpu node bindings definition -===================================== - -The RISC-V architecture, in accordance with the Devicetree Specification, -requires the cpus and cpu nodes to be present and contain the properties -described below. - -- cpus node - - Description: Container of cpu nodes - - The node name must be "cpus". - - A cpus node must define the following properties: - - - #address-cells - Usage: required - Value type: - Definition: must be set to 1 - - #size-cells - Usage: required - Value type: - Definition: must be set to 0 - -- cpu node - - Description: Describes a hart context - - PROPERTIES - - - device_type - Usage: required - Value type: - Definition: must be "cpu" - - reg - Usage: required - Value type: - Definition: The hart ID of this CPU node - - compatible: - Usage: required - Value type: - Definition: must contain "riscv", may contain one of - "sifive,rocket0" - - mmu-type: - Usage: optional - Value type: - Definition: Specifies the CPU's MMU type. Possible values are - "riscv,sv32" - "riscv,sv39" - "riscv,sv48" - - riscv,isa: - Usage: required - Value type: - Definition: Contains the RISC-V ISA string of this hart. These - ISA strings are defined by the RISC-V ISA manual. - -Example: SiFive Freedom U540G Development Kit ---------------------------------------------- - -This system contains two harts: a hart marked as disabled that's used for -low-level system tasks and should be ignored by Linux, and a second hart that -Linux is allowed to run on. - - cpus { - #address-cells = <1>; - #size-cells = <0>; - timebase-frequency = <1000000>; - cpu@0 { - clock-frequency = <1600000000>; - compatible = "sifive,rocket0", "riscv"; - device_type = "cpu"; - i-cache-block-size = <64>; - i-cache-sets = <128>; - i-cache-size = <16384>; - next-level-cache = <&L15 &L0>; - reg = <0>; - riscv,isa = "rv64imac"; - status = "disabled"; - L10: interrupt-controller { - #interrupt-cells = <1>; - compatible = "riscv,cpu-intc"; - interrupt-controller; - }; - }; - cpu@1 { - clock-frequency = <1600000000>; - compatible = "sifive,rocket0", "riscv"; - d-cache-block-size = <64>; - d-cache-sets = <64>; - d-cache-size = <32768>; - d-tlb-sets = <1>; - d-tlb-size = <32>; - device_type = "cpu"; - i-cache-block-size = <64>; - i-cache-sets = <64>; - i-cache-size = <32768>; - i-tlb-sets = <1>; - i-tlb-size = <32>; - mmu-type = "riscv,sv39"; - next-level-cache = <&L15 &L0>; - reg = <1>; - riscv,isa = "rv64imafdc"; - status = "okay"; - tlb-split; - L13: interrupt-controller { - #interrupt-cells = <1>; - compatible = "riscv,cpu-intc"; - interrupt-controller; - }; - }; - }; - -Example: Spike ISA Simulator with 1 Hart ----------------------------------------- - -This device tree matches the Spike ISA golden model as run with `spike -p1`. - - cpus { - cpu@0 { - device_type = "cpu"; - reg = <0x00000000>; - status = "okay"; - compatible = "riscv"; - riscv,isa = "rv64imafdc"; - mmu-type = "riscv,sv48"; - clock-frequency = <0x3b9aca00>; - interrupt-controller { - #interrupt-cells = <0x00000001>; - interrupt-controller; - compatible = "riscv,cpu-intc"; - } - } - } diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml index c899111aa5e3..b261a3015f84 100644 --- a/Documentation/devicetree/bindings/riscv/cpus.yaml +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml @@ -10,6 +10,18 @@ maintainers: - Paul Walmsley - Palmer Dabbelt +description: | + This document uses some terminology common to the RISC-V community + that is not widely used, the definitions of which are listed here: + + hart: A hardware execution context, which contains all the state + mandated by the RISC-V ISA: a PC and some registers. This + terminology is designed to disambiguate software's view of execution + contexts from any particular microarchitectural implementation + strategy. For example, an Intel laptop containing one socket with + two cores, each of which has two hyperthreads, could be described as + having four harts. + properties: compatible: items: @@ -50,6 +62,10 @@ properties: User-Level ISA document, available from https://riscv.org/specifications/ + While the isa strings in ISA specification are case + insensitive, letters in the riscv,isa string must be all + lowercase to simplify parsing. + timebase-frequency: type: integer minimum: 1 diff --git a/Documentation/devicetree/bindings/riscv/sifive.yaml b/Documentation/devicetree/bindings/riscv/sifive.yaml index 9d17dc2f3f84..3ab532713dc1 100644 --- a/Documentation/devicetree/bindings/riscv/sifive.yaml +++ b/Documentation/devicetree/bindings/riscv/sifive.yaml @@ -19,7 +19,7 @@ properties: compatible: items: - enum: - - sifive,freedom-unleashed-a00 + - sifive,hifive-unleashed-a00 - const: sifive,fu540-c000 - const: sifive,fu540 ... diff --git a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt deleted file mode 100644 index 4d403645ac9b..000000000000 --- a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt +++ /dev/null @@ -1,21 +0,0 @@ -Amlogic Meson Random number generator -===================================== - -Required properties: - -- compatible : should be "amlogic,meson-rng" -- reg : Specifies base physical address and size of the registers. - -Optional properties: - -- clocks : phandle to the following named clocks -- clock-names: Name of core clock, must be "core" - -Example: - -rng { - compatible = "amlogic,meson-rng"; - reg = <0x0 0xc8834000 0x0 0x4>; - clocks = <&clkc CLKID_RNG0>; - clock-names = "core"; -}; diff --git a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml new file mode 100644 index 000000000000..a9ff3cb35c5e --- /dev/null +++ b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 BayLibre, SAS +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/rng/amlogic,meson-rng.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic Meson Random number generator + +maintainers: + - Neil Armstrong + +properties: + compatible: + enum: + - amlogic,meson-rng + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: core + +required: + - compatible + - reg + +examples: + - | + rng@c8834000 { + compatible = "amlogic,meson-rng"; + reg = <0xc8834000 0x4>; + }; diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.txt b/Documentation/devicetree/bindings/rng/mtk-rng.txt index 2bc89f133701..dfdcb5cd2ea8 100644 --- a/Documentation/devicetree/bindings/rng/mtk-rng.txt +++ b/Documentation/devicetree/bindings/rng/mtk-rng.txt @@ -6,6 +6,7 @@ Required properties: "mediatek,mt7622-rng", "mediatek,mt7623-rng" : for MT7622 "mediatek,mt7629-rng", "mediatek,mt7623-rng" : for MT7629 "mediatek,mt7623-rng" : for MT7623 + "mediatek,mt8516-rng", "mediatek,mt7623-rng" : for MT8516 - clocks : list of clock specifiers, corresponding to entries in clock-names property; - clock-names : Should contain "rng" entries; diff --git a/Documentation/devicetree/bindings/rng/timeriomem_rng.txt b/Documentation/devicetree/bindings/rng/timeriomem_rng.txt index 214940093b55..fb4846160047 100644 --- a/Documentation/devicetree/bindings/rng/timeriomem_rng.txt +++ b/Documentation/devicetree/bindings/rng/timeriomem_rng.txt @@ -12,7 +12,7 @@ Optional properties: which disables using this rng to automatically fill the kernel's entropy pool. -N.B. currently 'reg' must be four bytes wide and aligned +N.B. currently 'reg' must be at least four bytes wide and 32-bit aligned Example: diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml index 924622f39c44..d7a57ec4a640 100644 --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml @@ -25,6 +25,7 @@ properties: - items: - const: allwinner,sun50i-a64-rtc - const: allwinner,sun8i-h3-rtc + - const: allwinner,sun50i-h6-rtc reg: maxItems: 1 @@ -92,6 +93,18 @@ allOf: minItems: 3 maxItems: 3 + - if: + properties: + compatible: + contains: + const: allwinner,sun50i-h6-rtc + + then: + properties: + clock-output-names: + minItems: 3 + maxItems: 3 + - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/rtc/nxp,rtc-2123.txt b/Documentation/devicetree/bindings/rtc/nxp,rtc-2123.txt index 1994f601800a..7371f525a687 100644 --- a/Documentation/devicetree/bindings/rtc/nxp,rtc-2123.txt +++ b/Documentation/devicetree/bindings/rtc/nxp,rtc-2123.txt @@ -1,7 +1,7 @@ NXP PCF2123 SPI Real Time Clock Required properties: -- compatible: should be: "nxp,rtc-pcf2123" +- compatible: should be: "nxp,pcf2123" or "microcrystal,rv2123" - reg: should be the SPI slave chipselect address @@ -11,7 +11,7 @@ Optional properties: Example: pcf2123: rtc@3 { - compatible = "nxp,rtc-pcf2123" + compatible = "nxp,pcf2123" reg = <3> spi-cs-high; }; diff --git a/Documentation/devicetree/bindings/rtc/pcf8563.txt b/Documentation/devicetree/bindings/rtc/pcf8563.txt index 36984acbb383..6076fe76dbfa 100644 --- a/Documentation/devicetree/bindings/rtc/pcf8563.txt +++ b/Documentation/devicetree/bindings/rtc/pcf8563.txt @@ -3,7 +3,9 @@ Philips PCF8563/Epson RTC8564 Real Time Clock Required properties: -- compatible: Should contain "nxp,pcf8563". +- compatible: Should contain "nxp,pcf8563", + "epson,rtc8564" or + "microcrystal,rv8564" - reg: I2C address for chip. Optional property: diff --git a/Documentation/devicetree/bindings/rtc/rtc-ds1307.txt b/Documentation/devicetree/bindings/rtc/rtc-ds1307.txt index eaee19b60960..66f0a31ae9ce 100644 --- a/Documentation/devicetree/bindings/rtc/rtc-ds1307.txt +++ b/Documentation/devicetree/bindings/rtc/rtc-ds1307.txt @@ -19,6 +19,7 @@ Required properties: "pericom,pt7c4338", "epson,rx8025", "isil,isl12057" + "epson,rx8130" - reg: I2C bus address of the device Optional properties: diff --git a/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt b/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt new file mode 100644 index 000000000000..fffac74999da --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt @@ -0,0 +1,36 @@ +Freescale FlexTimer Module (FTM) Alarm + +Required properties: +- compatible : Should be "fsl,-ftm-alarm", the + supported chips include + "fsl,ls1012a-ftm-alarm" + "fsl,ls1021a-ftm-alarm" + "fsl,ls1028a-ftm-alarm" + "fsl,ls1043a-ftm-alarm" + "fsl,ls1046a-ftm-alarm" + "fsl,ls1088a-ftm-alarm" + "fsl,ls208xa-ftm-alarm" + "fsl,lx2160a-ftm-alarm" +- reg : Specifies base physical address and size of the register sets for the + FlexTimer Module. +- interrupts : Should be the FlexTimer Module interrupt. +- fsl,rcpm-wakeup property and rcpm node : Please refer + Documentation/devicetree/bindings/soc/fsl/rcpm.txt + +Optional properties: +- big-endian: If the host controller is big-endian mode, specify this property. + The default endian mode is little-endian. + +Example: +rcpm: rcpm@1e34040 { + compatible = "fsl,ls1088a-rcpm", "fsl,qoriq-rcpm-2.1+"; + reg = <0x0 0x1e34040 0x0 0x18>; + #fsl,rcpm-wakeup-cells = <6>; +}; + +ftm_alarm0: timer@2800000 { + compatible = "fsl,ls1088a-ftm-alarm"; + reg = <0x0 0x2800000 0x0 0x10000>; + fsl,rcpm-wakeup = <&rcpm 0x0 0x0 0x0 0x0 0x4000 0x0>; + interrupts = <0 44 4>; +}; diff --git a/Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt b/Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt new file mode 100644 index 000000000000..c014f54a9853 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt @@ -0,0 +1,22 @@ +* Amlogic Virtual RTC (VRTC) + +This is a Linux interface to an RTC managed by firmware, hence it's +virtual from a Linux perspective. The interface is 1 register where +an alarm time (in seconds) is to be written. + +Required properties: +- compatible: should be "amlogic,meson-vrtc" +- reg: physical address for the alarm register + +The alarm register is a simple scratch register shared between the +application processors (AP) and the secure co-processor (SCP.) When +the AP suspends, the SCP will use the value of this register to +program an always-on timer before going sleep. When the timer expires, +the SCP will wake up and will then wake the AP. + +Example: + + vrtc: rtc@0a8 { + compatible = "amlogic,meson-vrtc"; + reg = <0x0 0x000a8 0x0 0x4>; + }; diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml index 0c12ce9a9b45..18cb456752f6 100644 --- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml @@ -52,8 +52,6 @@ properties: - nxp,pcf2127 # Real-time clock - nxp,pcf2129 - # Real-time clock/calendar - - nxp,pcf8563 # Real-time Clock Module - pericom,pt7c4338 # I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.txt b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.txt deleted file mode 100644 index c06c045126fc..000000000000 --- a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.txt +++ /dev/null @@ -1,38 +0,0 @@ -Amlogic Meson SoC UART Serial Interface -======================================= - -The Amlogic Meson SoC UART Serial Interface is present on a large range -of SoCs, and can be present either in the "Always-On" power domain or the -"Everything-Else" power domain. - -The particularity of the "Always-On" Serial Interface is that the hardware -is active since power-on and does not need any clock gating and is usable -as very early serial console. - -Required properties: -- compatible : compatible: value should be different for each SoC family as : - - Meson6 : "amlogic,meson6-uart" - - Meson8 : "amlogic,meson8-uart" - - Meson8b : "amlogic,meson8b-uart" - - GX (GXBB, GXL, GXM) : "amlogic,meson-gx-uart" - eventually followed by : "amlogic,meson-ao-uart" if this UART interface - is in the "Always-On" power domain. -- reg : offset and length of the register set for the device. -- interrupts : identifier to the device interrupt -- clocks : a list of phandle + clock-specifier pairs, one for each - entry in clock names. -- clock-names : - * "xtal" for external xtal clock identifier - * "pclk" for the bus core clock, either the clk81 clock or the gate clock - * "baud" for the source of the baudrate generator, can be either the xtal - or the pclk. - -e.g. -uart_A: serial@84c0 { - compatible = "amlogic,meson-gx-uart"; - reg = <0x0 0x84c0 0x0 0x14>; - interrupts = ; - /* Use xtal as baud rate clock source */ - clocks = <&xtal>, <&clkc CLKID_UART0>, <&xtal>; - clock-names = "xtal", "pclk", "baud"; -}; diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml new file mode 100644 index 000000000000..214fe8beddc3 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 BayLibre, SAS +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/serial/amlogic,meson-uart.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic Meson SoC UART Serial Interface + +maintainers: + - Neil Armstrong + +description: | + The Amlogic Meson SoC UART Serial Interface is present on a large range + of SoCs, and can be present either in the "Always-On" power domain or the + "Everything-Else" power domain. + + The particularity of the "Always-On" Serial Interface is that the hardware + is active since power-on and does not need any clock gating and is usable + as very early serial console. + +properties: + compatible: + oneOf: + - description: Always-on power domain UART controller + items: + - enum: + - amlogic,meson6-uart + - amlogic,meson8-uart + - amlogic,meson8b-uart + - amlogic,meson-gx-uart + - const: amlogic,meson-ao-uart + - description: Everything-Else power domain UART controller + enum: + - amlogic,meson6-uart + - amlogic,meson8-uart + - amlogic,meson8b-uart + - amlogic,meson-gx-uart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: external xtal clock identifier + - description: the bus core clock, either the clk81 clock or the gate clock + - description: the source of the baudrate generator, can be either the xtal or the pclk + + clock-names: + items: + - const: xtal + - const: pclk + - const: baud + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +examples: + - | + serial@84c0 { + compatible = "amlogic,meson-gx-uart"; + reg = <0x84c0 0x14>; + interrupts = <26>; + clocks = <&xtal>, <&pclk>, <&xtal>; + clock-names = "xtal", "pclk", "baud"; + }; diff --git a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.txt b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.txt new file mode 100644 index 000000000000..f1bbe0826be5 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.txt @@ -0,0 +1,22 @@ +* Freescale LINFlexD UART + +The LINFlexD controller implements several LIN protocol versions, as well as +support for full-duplex UART communication through 8-bit and 9-bit frames. + +See chapter 47 ("LINFlexD") in the reference manual[1]. + +Required properties: +- compatible : + - "fsl,s32v234-linflexuart" for LINFlexD configured in UART mode, which + is compatible with the one integrated on S32V234 SoC +- reg : Address and length of the register set for the device +- interrupts : Should contain uart interrupt + +Example: +uart0: serial@40053000 { + compatible = "fsl,s32v234-linflexuart"; + reg = <0x0 0x40053000 0x0 0x1000>; + interrupts = <0 59 4>; +}; + +[1] https://www.nxp.com/webapp/Download?colCode=S32V234RM diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt index 21483ba820bc..3495eee81d53 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt @@ -13,7 +13,10 @@ Required properties: - reg : Address and length of the register set for the device - interrupts : Should contain uart interrupt - clocks : phandle + clock specifier pairs, one for each entry in clock-names -- clock-names : should contain: "ipg" - the uart clock +- clock-names : For vf610/ls1021a/imx7ulp, "ipg" clock is for uart bus/baud + clock. For imx8qxp lpuart, "ipg" clock is bus clock that is used to access + lpuart controller registers, it also requires "baud" clock for module to + receive/transmit data. Optional properties: - dmas: A list of two dma specifiers, one for each entry in dma-names. diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt b/Documentation/devicetree/bindings/serial/mtk-uart.txt index 6fdffb735fb9..3a3b57079f0d 100644 --- a/Documentation/devicetree/bindings/serial/mtk-uart.txt +++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt @@ -9,6 +9,7 @@ Required properties: * "mediatek,mt6589-uart" for MT6589 compatible UARTS * "mediatek,mt6755-uart" for MT6755 compatible UARTS * "mediatek,mt6765-uart" for MT6765 compatible UARTS + * "mediatek,mt6779-uart" for MT6779 compatible UARTS * "mediatek,mt6795-uart" for MT6795 compatible UARTS * "mediatek,mt6797-uart" for MT6797 compatible UARTS * "mediatek,mt7622-uart" for MT7622 compatible UARTS diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt index d7edf732eb7f..f709304036c2 100644 --- a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt +++ b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt @@ -1,7 +1,12 @@ NVIDIA Tegra20/Tegra30 high speed (DMA based) UART controller driver. Required properties: -- compatible : should be "nvidia,tegra30-hsuart", "nvidia,tegra20-hsuart". +- compatible : should be, + "nvidia,tegra20-hsuart" for Tegra20, + "nvidia,tegra30-hsuart" for Tegra30, + "nvidia,tegra186-hsuart" for Tegra186, + "nvidia,tegra194-hsuart" for Tegra194. + - reg: Should contain UART controller registers location and length. - interrupts: Should contain UART controller interrupts. - clocks: Must contain one entry, for the module clock. @@ -19,6 +24,37 @@ Required properties: Optional properties: - nvidia,enable-modem-interrupt: Enable modem interrupts. Should be enable only if all 8 lines of UART controller are pinmuxed. +- nvidia,adjust-baud-rates: List of entries providing percentage of baud rate + adjustment within a range. + Each entry contains sets of 3 values. Range low/high and adjusted rate. + + When baud rate set on controller falls within the range mentioned in this + field, baud rate will be adjusted by percentage mentioned here. + Ex: <9600 115200 200> + Increase baud rate by 2% when set baud rate falls within range 9600 to 115200 + +Baud Rate tolerance: + Standard UART devices are expected to have tolerance for baud rate error by + -4 to +4 %. All Tegra devices till Tegra210 had this support. However, + Tegra186 chip has a known hardware issue. UART Rx baud rate tolerance level + is 0% to +4% in 1-stop config. Otherwise, the received data will have + corruption/invalid framing errors. Parker errata suggests adjusting baud + rate to be higher than the deviations observed in Tx. + + Tx deviation of connected device can be captured over scope (or noted from + its spec) for valid range and Tegra baud rate has to be set above actual + Tx baud rate observed. To do this we use nvidia,adjust-baud-rates + + As an example, consider there is deviation observed in Tx for baud rates as + listed below. + 0 to 9600 has 1% deviation + 9600 to 115200 2% deviation + This slight deviation is expcted and Tegra UART is expected to handle it. Due + to the issue stated above, baud rate on Tegra UART should be set equal to or + above deviation observed for avoiding frame errors. + Property should be set like this + nvidia,adjust-baud-rates = <0 9600 100>, + <9600 115200 200>; Example: @@ -33,4 +69,5 @@ serial@70006000 { reset-names = "serial"; dmas = <&apbdma 8>, <&apbdma 8>; dma-names = "rx", "tx"; + nvidia,adjust-baud-rates = <1000000 4000000 136>; /* 1.36% shift */ }; diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.txt b/Documentation/devicetree/bindings/serial/sifive-serial.txt deleted file mode 100644 index c86b1e524159..000000000000 --- a/Documentation/devicetree/bindings/serial/sifive-serial.txt +++ /dev/null @@ -1,33 +0,0 @@ -SiFive asynchronous serial interface (UART) - -Required properties: - -- compatible: should be something similar to - "sifive,-uart" for the UART as integrated - on a particular chip, and "sifive,uart" for the - general UART IP block programming model. Supported - compatible strings as of the date of this writing are: - "sifive,fu540-c000-uart" for the SiFive UART v0 as - integrated onto the SiFive FU540 chip, or "sifive,uart0" - for the SiFive UART v0 IP block with no chip integration - tweaks (if any) -- reg: address and length of the register space -- interrupts: Should contain the UART interrupt identifier -- clocks: Should contain a clock identifier for the UART's parent clock - - -UART HDL that corresponds to the IP block version numbers can be found -here: - -https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/uart - - -Example: - -uart0: serial@10010000 { - compatible = "sifive,fu540-c000-uart", "sifive,uart0"; - interrupt-parent = <&plic0>; - interrupts = <80>; - reg = <0x0 0x10010000 0x0 0x1000>; - clocks = <&prci PRCI_CLK_TLCLK>; -}; diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.yaml b/Documentation/devicetree/bindings/serial/sifive-serial.yaml new file mode 100644 index 000000000000..e8d3aeda1202 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/sifive-serial.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/sifive-serial.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SiFive asynchronous serial interface (UART) + +maintainers: + - Pragnesh Patel + - Paul Walmsley + - Palmer Dabbelt + +allOf: + - $ref: /schemas/serial.yaml# + +properties: + compatible: + items: + - const: sifive,fu540-c000-uart + - const: sifive,uart0 + + description: + Should be something similar to "sifive,-uart" + for the UART as integrated on a particular chip, + and "sifive,uart" for the general UART IP + block programming model. + + UART HDL that corresponds to the IP block version + numbers can be found here - + + https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/uart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include + serial@10010000 { + compatible = "sifive,fu540-c000-uart", "sifive,uart0"; + interrupt-parent = <&plic0>; + interrupts = <80>; + reg = <0x0 0x10010000 0x0 0x1000>; + clocks = <&prci PRCI_CLK_TLCLK>; + }; + +... diff --git a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt index a6b19485c9dc..8620f7fcbd50 100644 --- a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt +++ b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt @@ -20,6 +20,11 @@ Optional properties: linux,rs485-enabled-at-boot-time: see rs485.txt. - dmas: phandle(s) to DMA controller node(s). Refer to stm32-dma.txt - dma-names: "rx" and/or "tx" +- wakeup-source: bool flag to indicate this device has wakeup capabilities +- interrupt-names, if optional wake-up interrupt is used, should be: + - "event": the name for the interrupt line of the USART instance + - "wakeup" the name for the optional wake-up interrupt + Examples: usart4: serial@40004c00 { diff --git a/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt b/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt index 6bf6b43f8dd8..3dd563cec794 100644 --- a/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt +++ b/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt @@ -11,6 +11,7 @@ Required properties: "amlogic,meson8b-clk-measure" for Meson8b SoCs "amlogic,meson-axg-clk-measure" for AXG SoCs "amlogic,meson-g12a-clk-measure" for G12a SoCs + "amlogic,meson-sm1-clk-measure" for SM1 SoCs - reg: base address and size of the Clock Measurer register space. Example: diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt index d7afaff5faff..05ec2a838c54 100644 --- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt @@ -18,7 +18,8 @@ Required properties: - reg : offset and length of the device registers. - bus-frequency : the clock frequency for QUICC Engine. - fsl,qe-num-riscs: define how many RISC engines the QE has. -- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use for the +- fsl,qe-snums: This property has to be specified as '/bits/ 8' value, + defining the array of serial number (SNUM) values for the virtual threads. Optional properties: @@ -34,6 +35,11 @@ Recommended properties - brg-frequency : the internal clock source frequency for baud-rate generators in Hz. +Deprecated properties +- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use + for the threads. Use fsl,qe-snums instead to not only specify the + number of snums, but also their values. + Example: qe@e0100000 { #address-cells = <1>; @@ -44,6 +50,11 @@ Example: reg = ; brg-frequency = <0>; bus-frequency = <179A7B00>; + fsl,qe-snums = /bits/ 8 < + 0x04 0x05 0x0C 0x0D 0x14 0x15 0x1C 0x1D + 0x24 0x25 0x2C 0x2D 0x34 0x35 0x88 0x89 + 0x98 0x99 0xA8 0xA9 0xB8 0xB9 0xC8 0xC9 + 0xD8 0xD9 0xE8 0xE9>; } * Multi-User RAM (MURAM) diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt index 954ffee0a9c4..4fc571e78f01 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt @@ -15,7 +15,10 @@ power-domains. - compatible: Usage: required Value type: - Definition: must be "qcom,sdm845-aoss-qmp" + Definition: must be one of: + "qcom,sc7180-aoss-qmp" + "qcom,sdm845-aoss-qmp" + "qcom,sm8150-aoss-qmp" - reg: Usage: required diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt index f7b00a7c0f68..f541d1f776a2 100644 --- a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt @@ -19,8 +19,15 @@ child of the pmmc node. Required Properties: -------------------- - compatible: should be "ti,sci-pm-domain" -- #power-domain-cells: Must be 1 so that an id can be provided in each - device node. +- #power-domain-cells: Can be one of the following: + 1: Containing the device id of each node + 2: First entry should be device id + Second entry should be one of the floowing: + TI_SCI_PD_EXCLUSIVE: To allow device to be + exclusively controlled by + the requesting hosts. + TI_SCI_PD_SHARED: To allow device to be shared + by multiple hosts. Example (K2G): ------------- diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml index e0284d8c3b63..38d4cede0860 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml @@ -70,7 +70,9 @@ allOf: properties: compatible: contains: - const: allwinner,sun8i-h3-spdif + enum: + - allwinner,sun8i-h3-spdif + - allwinner,sun50i-h6-spdif then: properties: diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun50i-a64-codec-analog.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun50i-a64-codec-analog.yaml new file mode 100644 index 000000000000..f290eb72a878 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/allwinner,sun50i-a64-codec-analog.yaml @@ -0,0 +1,39 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/allwinner,sun50i-a64-codec-analog.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A64 Analog Codec Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +properties: + compatible: + const: allwinner,sun50i-a64-codec-analog + + reg: + maxItems: 1 + + cpvdd-supply: + description: + Regulator for the headphone amplifier + +required: + - compatible + - reg + - cpvdd-supply + +additionalProperties: false + +examples: + - | + codec_analog: codec-analog@1f015c0 { + compatible = "allwinner,sun50i-a64-codec-analog"; + reg = <0x01f015c0 0x4>; + cpvdd-supply = <®_eldo1>; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml new file mode 100644 index 000000000000..5e7cc05bbff1 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/allwinner,sun8i-a33-codec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A33 Codec Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +properties: + "#sound-dai-cells": + const: 0 + + compatible: + const: allwinner,sun8i-a33-codec + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Bus Clock + - description: Module Clock + + clock-names: + items: + - const: bus + - const: mod + +required: + - "#sound-dai-cells" + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + audio-codec@1c22e00 { + #sound-dai-cells = <0>; + compatible = "allwinner,sun8i-a33-codec"; + reg = <0x01c22e00 0x400>; + interrupts = <0 29 4>; + clocks = <&ccu 47>, <&ccu 92>; + clock-names = "bus", "mod"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-fifo.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-fifo.txt index 4330fc9dca6d..3080979350a0 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,axg-fifo.txt +++ b/Documentation/devicetree/bindings/sound/amlogic,axg-fifo.txt @@ -4,13 +4,18 @@ Required properties: - compatible: 'amlogic,axg-toddr' or 'amlogic,axg-toddr' or 'amlogic,g12a-frddr' or - 'amlogic,g12a-toddr' + 'amlogic,g12a-toddr' or + 'amlogic,sm1-frddr' or + 'amlogic,sm1-toddr' - reg: physical base address of the controller and length of memory mapped region. - interrupts: interrupt specifier for the fifo. - clocks: phandle to the fifo peripheral clock provided by the audio clock controller. -- resets: phandle to memory ARB line provided by the arb reset controller. +- resets: list of reset phandle, one for each entry reset-names. +- reset-names: should contain the following: + * "arb" : memory ARB line (required) + * "rst" : dedicated device reset line (optional) - #sound-dai-cells: must be 0. Example of FRDDR A on the A113 SoC: diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.txt index 73f473a9365f..716878107a24 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.txt +++ b/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.txt @@ -2,7 +2,8 @@ Required properties: - compatible: 'amlogic,axg-pdm' or - 'amlogic,g12a-pdm' + 'amlogic,g12a-pdm' or + 'amlogic,sm1-pdm' - reg: physical base address of the controller and length of memory mapped region. - clocks: list of clock phandle, one for each entry clock-names. @@ -12,6 +13,9 @@ Required properties: * "sysclk" : dsp system clock - #sound-dai-cells: must be 0. +Optional property: +- resets: phandle to the dedicated reset line of the pdm input. + Example of PDM on the A113 SoC: pdm: audio-controller@ff632000 { diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.txt index 0b82504fa419..df92a4ecf288 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.txt +++ b/Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.txt @@ -2,7 +2,8 @@ Required properties: - compatible: 'amlogic,axg-spdifin' or - 'amlogic,g12a-spdifin' + 'amlogic,g12a-spdifin' or + 'amlogic,sm1-spdifin' - interrupts: interrupt specifier for the spdif input. - clocks: list of clock phandle, one for each entry clock-names. - clock-names: should contain the following: @@ -10,6 +11,9 @@ Required properties: * "refclk" : spdif input reference clock - #sound-dai-cells: must be 0. +Optional property: +- resets: phandle to the dedicated reset line of the spdif input. + Example on the A113 SoC: spdifin: audio-controller@400 { diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.txt index 826152730508..28381dd1f633 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.txt +++ b/Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.txt @@ -2,13 +2,17 @@ Required properties: - compatible: 'amlogic,axg-spdifout' or - 'amlogic,g12a-spdifout' + 'amlogic,g12a-spdifout' or + 'amlogic,sm1-spdifout' - clocks: list of clock phandle, one for each entry clock-names. - clock-names: should contain the following: * "pclk" : peripheral clock. * "mclk" : master clock - #sound-dai-cells: must be 0. +Optional property: +- resets: phandle to the dedicated reset line of the spdif output. + Example on the A113 SoC: spdifout: audio-controller@480 { diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.txt index 8835a43edfbb..5996c0cd89c2 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.txt +++ b/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.txt @@ -4,7 +4,9 @@ Required properties: - compatible: 'amlogic,axg-tdmin' or 'amlogic,axg-tdmout' or 'amlogic,g12a-tdmin' or - 'amlogic,g12a-tdmout' + 'amlogic,g12a-tdmout' or + 'amlogic,sm1-tdmin' or + 'amlogic,sm1-tdmout - reg: physical base address of the controller and length of memory mapped region. - clocks: list of clock phandle, one for each entry clock-names. diff --git a/Documentation/devicetree/bindings/sound/amlogic,g12a-tohdmitx.txt b/Documentation/devicetree/bindings/sound/amlogic,g12a-tohdmitx.txt index aa6c35570d31..4e8cd7eb7cec 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,g12a-tohdmitx.txt +++ b/Documentation/devicetree/bindings/sound/amlogic,g12a-tohdmitx.txt @@ -1,10 +1,12 @@ * Amlogic HDMI Tx control glue Required properties: -- compatible: "amlogic,g12a-tohdmitx" +- compatible: "amlogic,g12a-tohdmitx" or + "amlogic,sm1-tohdmitx" - reg: physical base address of the controller and length of memory mapped region. - #sound-dai-cells: should be 1. +- resets: phandle to the dedicated reset line of the hdmitx glue. Example on the S905X2 SoC: @@ -12,6 +14,7 @@ tohdmitx: audio-controller@744 { compatible = "amlogic,g12a-tohdmitx"; reg = <0x0 0x744 0x0 0x4>; #sound-dai-cells = <1>; + resets = <&clkc_audio AUD_RESET_TOHDMITX>; }; Example of an 'amlogic,axg-sound-card': diff --git a/Documentation/devicetree/bindings/sound/everest,es8316.txt b/Documentation/devicetree/bindings/sound/everest,es8316.txt new file mode 100644 index 000000000000..1bf03c5f2af4 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/everest,es8316.txt @@ -0,0 +1,23 @@ +Everest ES8316 audio CODEC + +This device supports both I2C and SPI. + +Required properties: + + - compatible : should be "everest,es8316" + - reg : the I2C address of the device for I2C + +Optional properties: + + - clocks : a list of phandle, should contain entries for clock-names + - clock-names : should include as follows: + "mclk" : master clock (MCLK) of the device + +Example: + +es8316: codec@11 { + compatible = "everest,es8316"; + reg = <0x11>; + clocks = <&clks 10>; + clock-names = "mclk"; +}; diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt b/Documentation/devicetree/bindings/sound/fsl,esai.txt index 5b9914367610..0e6e2166f76c 100644 --- a/Documentation/devicetree/bindings/sound/fsl,esai.txt +++ b/Documentation/devicetree/bindings/sound/fsl,esai.txt @@ -7,8 +7,11 @@ other DSPs. It has up to six transmitters and four receivers. Required properties: - - compatible : Compatible list, must contain "fsl,imx35-esai" or - "fsl,vf610-esai" + - compatible : Compatible list, should contain one of the following + compatibles: + "fsl,imx35-esai", + "fsl,vf610-esai", + "fsl,imx6ull-esai", - reg : Offset and length of the register set for the device. diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt b/Documentation/devicetree/bindings/sound/fsl-sai.txt index 2e726b983845..0dc83cc4a236 100644 --- a/Documentation/devicetree/bindings/sound/fsl-sai.txt +++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt @@ -8,7 +8,9 @@ codec/DSP interfaces. Required properties: - compatible : Compatible list, contains "fsl,vf610-sai", - "fsl,imx6sx-sai" or "fsl,imx6ul-sai" + "fsl,imx6sx-sai", "fsl,imx6ul-sai", + "fsl,imx7ulp-sai", "fsl,imx8mq-sai" or + "fsl,imx8qm-sai". - reg : Offset and length of the register set for the device. diff --git a/Documentation/devicetree/bindings/sound/sun50i-codec-analog.txt b/Documentation/devicetree/bindings/sound/sun50i-codec-analog.txt deleted file mode 100644 index 056a098495cc..000000000000 --- a/Documentation/devicetree/bindings/sound/sun50i-codec-analog.txt +++ /dev/null @@ -1,14 +0,0 @@ -* Allwinner A64 Codec Analog Controls - -Required properties: -- compatible: must be one of the following compatibles: - - "allwinner,sun50i-a64-codec-analog" -- reg: must contain the registers location and length -- cpvdd-supply: Regulator supply for the headphone amplifier - -Example: - codec_analog: codec-analog@1f015c0 { - compatible = "allwinner,sun50i-a64-codec-analog"; - reg = <0x01f015c0 0x4>; - cpvdd-supply = <®_eldo1>; - }; diff --git a/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt b/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt deleted file mode 100644 index 2ca3d138528e..000000000000 --- a/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt +++ /dev/null @@ -1,63 +0,0 @@ -Allwinner SUN8I audio codec ------------------------------------- - -On Sun8i-A33 SoCs, the audio is separated in different parts: - - A DAI driver. It uses the "sun4i-i2s" driver which is - documented here: - Documentation/devicetree/bindings/sound/sun4i-i2s.txt - - An analog part of the codec which is handled as PRCM registers. - See Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt - - An digital part of the codec which is documented in this current - binding documentation. - - And finally, an audio card which links all the above components. - The simple-audio card will be used. - See Documentation/devicetree/bindings/sound/simple-card.txt - -This bindings documentation exposes Sun8i codec (digital part). - -Required properties: -- compatible: must be "allwinner,sun8i-a33-codec" -- reg: must contain the registers location and length -- interrupts: must contain the codec interrupt -- clocks: a list of phandle + clock-specifer pairs, one for each entry - in clock-names. -- clock-names: should contain followings: - - "bus": the parent APB clock for this controller - - "mod": the parent module clock - -Here is an example to add a sound card and the codec binding on sun8i SoCs that -are similar to A33 using simple-card: - - sound { - compatible = "simple-audio-card"; - simple-audio-card,name = "sun8i-a33-audio"; - simple-audio-card,format = "i2s"; - simple-audio-card,frame-master = <&link_codec>; - simple-audio-card,bitclock-master = <&link_codec>; - simple-audio-card,mclk-fs = <512>; - simple-audio-card,aux-devs = <&codec_analog>; - simple-audio-card,routing = - "Left DAC", "Digital Left DAC", - "Right DAC", "Digital Right DAC"; - - simple-audio-card,cpu { - sound-dai = <&dai>; - }; - - link_codec: simple-audio-card,codec { - sound-dai = <&codec>; - }; - - soc@1c00000 { - [...] - - audio-codec@1c22e00 { - #sound-dai-cells = <0>; - compatible = "allwinner,sun8i-a33-codec"; - reg = <0x01c22e00 0x400>; - interrupts = ; - clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>; - clock-names = "bus", "mod"; - }; - }; - diff --git a/Documentation/devicetree/bindings/sound/uda1334.txt b/Documentation/devicetree/bindings/sound/uda1334.txt new file mode 100644 index 000000000000..f64071b25e8d --- /dev/null +++ b/Documentation/devicetree/bindings/sound/uda1334.txt @@ -0,0 +1,17 @@ +UDA1334 audio CODEC + +This device uses simple GPIO pins for controlling codec settings. + +Required properties: + + - compatible : "nxp,uda1334" + - nxp,mute-gpios: a GPIO spec for the MUTE pin. + - nxp,deemph-gpios: a GPIO spec for the De-emphasis pin + +Example: + +uda1334: audio-codec { + compatible = "nxp,uda1334"; + nxp,mute-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>; + nxp,deemph-gpios = <&gpio3 3 GPIO_ACTIVE_LOW>; +}; diff --git a/Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml b/Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml new file mode 100644 index 000000000000..1b43993bccdb --- /dev/null +++ b/Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soundwire/soundwire-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SoundWire Controller Generic Binding + +maintainers: + - Srinivas Kandagatla + - Vinod Koul + +description: | + SoundWire busses can be described with a node for the SoundWire controller + device and a set of child nodes for each SoundWire slave on the bus. + +properties: + $nodename: + pattern: "^soundwire(@.*)?$" + + "#address-cells": + const: 2 + + "#size-cells": + const: 0 + +patternProperties: + "^.*@[0-9a-f],[0-9a-f]$": + type: object + + properties: + compatible: + pattern: "^sdw[0-9a-f]{1}[0-9a-f]{4}[0-9a-f]{4}[0-9a-f]{2}$" + description: Is the textual representation of SoundWire Enumeration + address. compatible string should contain SoundWire Version ID, + Manufacturer ID, Part ID and Class ID in order and shall be in + lower-case hexadecimal with leading zeroes. + Valid sizes of these fields are + Version ID is 1 nibble, number '0x1' represents SoundWire 1.0 + and '0x2' represents SoundWire 1.1 and so on. + MFD is 4 nibbles + PID is 4 nibbles + CID is 2 nibbles + More Information on detail of encoding of these fields can be + found in MIPI Alliance DisCo & SoundWire 1.0 Specifications. + + reg: + maxItems: 1 + description: + Link ID followed by Instance ID of SoundWire Device Address. + + required: + - compatible + - reg + +required: + - "#address-cells" + - "#size-cells" + +examples: + - | + soundwire@c2d0000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x0c2d0000 0x2000>; + + speaker@0,1 { + compatible = "sdw10217201000"; + reg = <0 1>; + powerdown-gpios = <&wcdpinctrl 2 0>; + #thermal-sensor-cells = <0>; + }; + + speaker@0,2 { + compatible = "sdw10217201000"; + reg = <0 2>; + powerdown-gpios = <&wcdpinctrl 2 0>; + #thermal-sensor-cells = <0>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml new file mode 100644 index 000000000000..49b617c98ae7 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 BayLibre, SAS +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/spi/amlogic,meson-gx-spicc.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic Meson SPI Communication Controller + +maintainers: + - Neil Armstrong + +allOf: + - $ref: "spi-controller.yaml#" + +description: | + The Meson SPICC is a generic SPI controller for general purpose Full-Duplex + communications with dedicated 16 words RX/TX PIO FIFOs. + +properties: + compatible: + enum: + - amlogic,meson-gx-spicc # SPICC controller on Amlogic GX and compatible SoCs + - amlogic,meson-axg-spicc # SPICC controller on Amlogic AXG and compatible SoCs + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + resets: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + description: input clock for the baud rate generator + items: + - const: core + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +examples: + - | + spi@c1108d80 { + compatible = "amlogic,meson-gx-spicc"; + reg = <0xc1108d80 0x80>; + interrupts = <112>; + clocks = <&clk81>; + clock-names = "core"; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-switch@0 { + compatible = "micrel,ks8995m"; + spi-max-frequency = <1000000>; + reg = <0>; + }; + }; + diff --git a/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml b/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml new file mode 100644 index 000000000000..5f33c39d820b --- /dev/null +++ b/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 BayLibre, SAS +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/spi/amlogic,meson6-spifc.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic Meson SPI Flash Controller + +maintainers: + - Neil Armstrong + +allOf: + - $ref: "spi-controller.yaml#" + +description: | + The Meson SPIFC is a controller optimized for communication with SPI + NOR memories, without DMA support and a 64-byte unified transmit / + receive buffer. + +properties: + compatible: + enum: + - amlogic,meson6-spifc # SPI Flash Controller on Meson6 and compatible SoCs + - amlogic,meson-gxbb-spifc # SPI Flash Controller on GXBB and compatible SoCs + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - clocks + +examples: + - | + spi@c1108c80 { + compatible = "amlogic,meson6-spifc"; + reg = <0xc1108c80 0x80>; + clocks = <&clk81>; + #address-cells = <1>; + #size-cells = <0>; + + flash: flash@0 { + compatible = "spansion,m25p80", "jedec,spi-nor"; + reg = <0>; + spi-max-frequency = <40000000>; + }; + }; + diff --git a/Documentation/devicetree/bindings/spi/nuvoton,npcm-fiu.txt b/Documentation/devicetree/bindings/spi/nuvoton,npcm-fiu.txt new file mode 100644 index 000000000000..a388005842ad --- /dev/null +++ b/Documentation/devicetree/bindings/spi/nuvoton,npcm-fiu.txt @@ -0,0 +1,47 @@ +* Nuvoton FLASH Interface Unit (FIU) SPI Controller + +NPCM FIU supports single, dual and quad communication interface. + +The NPCM7XX supports three FIU modules, +FIU0 and FIUx supports two chip selects, +FIU3 support four chip select. + +Required properties: + - compatible : "nuvoton,npcm750-fiu" for the NPCM7XX BMC + - #address-cells : should be 1. + - #size-cells : should be 0. + - reg : the first contains the register location and length, + the second contains the memory mapping address and length + - reg-names: Should contain the reg names "control" and "memory" + - clocks : phandle of FIU reference clock. + +Required properties in case the pins can be muxed: + - pinctrl-names : a pinctrl state named "default" must be defined. + - pinctrl-0 : phandle referencing pin configuration of the device. + +Optional property: + - nuvoton,spix-mode: enable spix-mode for an expansion bus to an ASIC or CPLD. + +Aliases: +- All the FIU controller nodes should be represented in the aliases node using + the following format 'fiu{n}' where n is a unique number for the alias. + In the NPCM7XX BMC: + fiu0 represent fiu 0 controller + fiu1 represent fiu 3 controller + fiu2 represent fiu x controller + +Example: +fiu3: spi@c00000000 { + compatible = "nuvoton,npcm750-fiu"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0xfb000000 0x1000>, <0x80000000 0x10000000>; + reg-names = "control", "memory"; + clocks = <&clk NPCM7XX_CLK_AHB>; + pinctrl-names = "default"; + pinctrl-0 = <&spi3_pins>; + spi-nor@0 { + ... + }; +}; + diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml index 876c0623f322..732339275848 100644 --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml @@ -31,7 +31,7 @@ properties: If that property is used, the number of chip selects will be increased automatically with max(cs-gpios, hardware chip selects). - So if, for example, the controller has 2 CS lines, and the + So if, for example, the controller has 4 CS lines, and the cs-gpios looks like this cs-gpios = <&gpio1 0 0>, <0>, <&gpio1 1 0>, <&gpio1 2 0>; @@ -73,7 +73,6 @@ patternProperties: Compatible of the SPI device. reg: - maxItems: 1 minimum: 0 maximum: 256 description: diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt index dcc7eaada511..162e024b95a0 100644 --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt @@ -6,6 +6,7 @@ Required properties: or "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi" "fsl,ls1012a-dspi" followed by "fsl,ls1021a-v1.0-dspi" + "fsl,ls1088a-dspi" followed by "fsl,ls1021a-v1.0-dspi" - reg : Offset and length of the register set for the device - interrupts : Should contain SPI controller interrupt - clocks: from common clock binding: handle to dspi clock. diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt index e8f1d627d288..69dc5d57b1ef 100644 --- a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt +++ b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt @@ -3,9 +3,8 @@ Required properties: - compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi", "fsl,imx7d-qspi", "fsl,imx6ul-qspi", - "fsl,ls1021a-qspi" + "fsl,ls1021a-qspi", "fsl,ls2080a-qspi" or - "fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi", "fsl,ls1043a-qspi" followed by "fsl,ls1021a-qspi" - reg : the first contains the register location and length, the second contains the memory mapping address and length @@ -34,7 +33,11 @@ qspi0: quadspi@40044000 { clock-names = "qspi_en", "qspi"; flash0: s25fl128s@0 { - .... + #address-cells = <1>; + #size-cells = <1>; + compatible = "spansion,s25fl128s", "jedec,spi-nor"; + spi-max-frequency = <50000000>; + reg = <0>; }; }; diff --git a/Documentation/devicetree/bindings/spi/spi-meson.txt b/Documentation/devicetree/bindings/spi/spi-meson.txt deleted file mode 100644 index b7f5e86fed22..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-meson.txt +++ /dev/null @@ -1,55 +0,0 @@ -Amlogic Meson SPI controllers - -* SPIFC (SPI Flash Controller) - -The Meson SPIFC is a controller optimized for communication with SPI -NOR memories, without DMA support and a 64-byte unified transmit / -receive buffer. - -Required properties: - - compatible: should be "amlogic,meson6-spifc" or "amlogic,meson-gxbb-spifc" - - reg: physical base address and length of the controller registers - - clocks: phandle of the input clock for the baud rate generator - - #address-cells: should be 1 - - #size-cells: should be 0 - - spi@c1108c80 { - compatible = "amlogic,meson6-spifc"; - reg = <0xc1108c80 0x80>; - clocks = <&clk81>; - #address-cells = <1>; - #size-cells = <0>; - }; - -* SPICC (SPI Communication Controller) - -The Meson SPICC is generic SPI controller for general purpose Full-Duplex -communications with dedicated 16 words RX/TX PIO FIFOs. - -Required properties: - - compatible: should be: - "amlogic,meson-gx-spicc" on Amlogic GX and compatible SoCs. - "amlogic,meson-axg-spicc" on Amlogic AXG and compatible SoCs - - reg: physical base address and length of the controller registers - - interrupts: The interrupt specifier - - clock-names: Must contain "core" - - clocks: phandle of the input clock for the baud rate generator - - #address-cells: should be 1 - - #size-cells: should be 0 - -Optional properties: - - resets: phandle of the internal reset line - -See ../spi/spi-bus.txt for more details on SPI bus master and slave devices -required and optional properties. - -Example : - spi@c1108d80 { - compatible = "amlogic,meson-gx-spicc"; - reg = <0xc1108d80 0x80>; - interrupts = ; - clock-names = "core"; - clocks = <&clk81>; - #address-cells = <1>; - #size-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt index c0f6c8ecfa2e..3a8079eb18c8 100644 --- a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt +++ b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt @@ -5,6 +5,7 @@ Required properties: - mediatek,mt2701-spi: for mt2701 platforms - mediatek,mt2712-spi: for mt2712 platforms - mediatek,mt6589-spi: for mt6589 platforms + - mediatek,mt6765-spi: for mt6765 platforms - mediatek,mt7622-spi: for mt7622 platforms - "mediatek,mt7629-spi", "mediatek,mt7622-spi": for mt7629 platforms - mediatek,mt8135-spi: for mt8135 platforms diff --git a/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt b/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt index 8de589b376ce..2567c829e2dc 100644 --- a/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt +++ b/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt @@ -25,18 +25,23 @@ data by ADI software channels at the same time, or two parallel routine of setti ADI registers will make ADI controller registers chaos to lead incorrect results. Then we need one hardware spinlock to synchronize between the multiple subsystems. +The new version ADI controller supplies multiple master channels for different +subsystem accessing, that means no need to add hardware spinlock to synchronize, +thus change the hardware spinlock support to be optional to keep backward +compatibility. + Required properties: - compatible: Should be "sprd,sc9860-adi". - reg: Offset and length of ADI-SPI controller register space. -- hwlocks: Reference to a phandle of a hwlock provider node. -- hwlock-names: Reference to hwlock name strings defined in the same order - as the hwlocks, should be "adi". - #address-cells: Number of cells required to define a chip select address on the ADI-SPI bus. Should be set to 1. - #size-cells: Size of cells required to define a chip select address size on the ADI-SPI bus. Should be set to 0. Optional properties: +- hwlocks: Reference to a phandle of a hwlock provider node. +- hwlock-names: Reference to hwlock name strings defined in the same order + as the hwlocks, should be "adi". - sprd,hw-channels: This is an array of channel values up to 49 channels. The first value specifies the hardware channel id which is used to transfer data triggered by hardware automatically, and the second diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt index 04cbb90a5d3e..28f2cbaf1702 100644 --- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt @@ -23,6 +23,7 @@ Required properties: Optional property: - little-endian : If present, the TMU registers are little endian. If absent, the default is big endian. +- clocks : the clock for clocking the TMU silicon. Example: diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml b/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml new file mode 100644 index 000000000000..20adc1c8e9cc --- /dev/null +++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml @@ -0,0 +1,102 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/allwinner,sun4i-a10-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A10 Timer Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +properties: + compatible: + enum: + - allwinner,sun4i-a10-timer + - allwinner,sun8i-a23-timer + - allwinner,sun8i-v3s-timer + - allwinner,suniv-f1c100s-timer + + reg: + maxItems: 1 + + interrupts: + description: + List of timers interrupts + + clocks: + maxItems: 1 + +allOf: + - if: + properties: + compatible: + items: + const: allwinner,sun4i-a10-timer + + then: + properties: + interrupts: + minItems: 6 + maxItems: 6 + + - if: + properties: + compatible: + items: + const: allwinner,sun8i-a23-timer + + then: + properties: + interrupts: + minItems: 2 + maxItems: 2 + + - if: + properties: + compatible: + items: + const: allwinner,sun8i-v3s-timer + + then: + properties: + interrupts: + minItems: 3 + maxItems: 3 + + - if: + properties: + compatible: + items: + const: allwinner,suniv-f1c100s-timer + + then: + properties: + interrupts: + minItems: 3 + maxItems: 3 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + timer { + compatible = "allwinner,sun4i-a10-timer"; + reg = <0x01c20c00 0x400>; + interrupts = <22>, + <23>, + <24>, + <25>, + <67>, + <68>; + clocks = <&osc>; + }; + +... diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt deleted file mode 100644 index 3da9d515c03a..000000000000 --- a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt +++ /dev/null @@ -1,19 +0,0 @@ -Allwinner A1X SoCs Timer Controller - -Required properties: - -- compatible : should be one of the following: - "allwinner,sun4i-a10-timer" - "allwinner,suniv-f1c100s-timer" -- reg : Specifies base physical address and size of the registers. -- interrupts : The interrupt of the first timer -- clocks: phandle to the source clock (usually a 24 MHz fixed clock) - -Example: - -timer { - compatible = "allwinner,sun4i-a10-timer"; - reg = <0x01c20c00 0x400>; - interrupts = <22>; - clocks = <&osc>; -}; diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt deleted file mode 100644 index 2c5c1be78360..000000000000 --- a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt +++ /dev/null @@ -1,26 +0,0 @@ -Allwinner SoCs High Speed Timer Controller - -Required properties: - -- compatible : should be "allwinner,sun5i-a13-hstimer" or - "allwinner,sun7i-a20-hstimer" -- reg : Specifies base physical address and size of the registers. -- interrupts : The interrupts of these timers (2 for the sun5i IP, 4 for the sun7i - one) -- clocks: phandle to the source clock (usually the AHB clock) - -Optional properties: -- resets: phandle to a reset controller asserting the timer - -Example: - -timer@1c60000 { - compatible = "allwinner,sun7i-a20-hstimer"; - reg = <0x01c60000 0x1000>; - interrupts = <0 51 1>, - <0 52 1>, - <0 53 1>, - <0 54 1>; - clocks = <&ahb1_gates 19>; - resets = <&ahb1rst 19>; -}; diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml new file mode 100644 index 000000000000..dfa0c41fd261 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/allwinner,sun5i-a13-hstimer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A13 High-Speed Timer Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +properties: + compatible: + oneOf: + - const: allwinner,sun5i-a13-hstimer + - const: allwinner,sun7i-a20-hstimer + - items: + - const: allwinner,sun6i-a31-hstimer + - const: allwinner,sun7i-a20-hstimer + + reg: + maxItems: 1 + + interrupts: + minItems: 2 + maxItems: 4 + items: + - description: Timer 0 Interrupt + - description: Timer 1 Interrupt + - description: Timer 2 Interrupt + - description: Timer 3 Interrupt + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +if: + properties: + compatible: + items: + const: allwinner,sun5i-a13-hstimer + +then: + properties: + interrupts: + minItems: 2 + maxItems: 2 + +else: + properties: + interrupts: + minItems: 4 + maxItems: 4 + +additionalProperties: false + +examples: + - | + timer@1c60000 { + compatible = "allwinner,sun7i-a20-hstimer"; + reg = <0x01c60000 0x1000>; + interrupts = <0 51 1>, + <0 52 1>, + <0 53 1>, + <0 54 1>; + clocks = <&ahb1_gates 19>; + resets = <&ahb1rst 19>; + }; + +... diff --git a/Documentation/devicetree/bindings/timer/ingenic,tcu.txt b/Documentation/devicetree/bindings/timer/ingenic,tcu.txt new file mode 100644 index 000000000000..5a4b9ddd9470 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/ingenic,tcu.txt @@ -0,0 +1,137 @@ +Ingenic JZ47xx SoCs Timer/Counter Unit devicetree bindings +========================================================== + +For a description of the TCU hardware and drivers, have a look at +Documentation/mips/ingenic-tcu.txt. + +Required properties: + +- compatible: Must be one of: + * ingenic,jz4740-tcu + * ingenic,jz4725b-tcu + * ingenic,jz4770-tcu + followed by "simple-mfd". +- reg: Should be the offset/length value corresponding to the TCU registers +- clocks: List of phandle & clock specifiers for clocks external to the TCU. + The "pclk", "rtc" and "ext" clocks should be provided. The "tcu" clock + should be provided if the SoC has it. +- clock-names: List of name strings for the external clocks. +- #clock-cells: Should be <1>; + Clock consumers specify this argument to identify a clock. The valid values + may be found in . +- interrupt-controller : Identifies the node as an interrupt controller +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt source. The value should be 1. +- interrupts : Specifies the interrupt the controller is connected to. + +Optional properties: + +- ingenic,pwm-channels-mask: Bitmask of TCU channels reserved for PWM use. + Default value is 0xfc. + + +Children nodes +========================================================== + + +PWM node: +--------- + +Required properties: + +- compatible: Must be one of: + * ingenic,jz4740-pwm + * ingenic,jz4725b-pwm +- #pwm-cells: Should be 3. See ../pwm/pwm.txt for a description of the cell + format. +- clocks: List of phandle & clock specifiers for the TCU clocks. +- clock-names: List of name strings for the TCU clocks. + + +Watchdog node: +-------------- + +Required properties: + +- compatible: Must be "ingenic,jz4740-watchdog" +- clocks: phandle to the WDT clock +- clock-names: should be "wdt" + + +OS Timer node: +--------- + +Required properties: + +- compatible: Must be one of: + * ingenic,jz4725b-ost + * ingenic,jz4770-ost +- clocks: phandle to the OST clock +- clock-names: should be "ost" +- interrupts : Specifies the interrupt the OST is connected to. + + +Example +========================================================== + +#include +#include + +/ { + tcu: timer@10002000 { + compatible = "ingenic,jz4770-tcu", "simple-mfd"; + reg = <0x10002000 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x10002000 0x1000>; + + #clock-cells = <1>; + + clocks = <&cgu JZ4770_CLK_RTC + &cgu JZ4770_CLK_EXT + &cgu JZ4770_CLK_PCLK>; + clock-names = "rtc", "ext", "pclk"; + + interrupt-controller; + #interrupt-cells = <1>; + + interrupt-parent = <&intc>; + interrupts = <27 26 25>; + + watchdog: watchdog@0 { + compatible = "ingenic,jz4740-watchdog"; + reg = <0x0 0xc>; + + clocks = <&tcu TCU_CLK_WDT>; + clock-names = "wdt"; + }; + + pwm: pwm@40 { + compatible = "ingenic,jz4740-pwm"; + reg = <0x40 0x80>; + + #pwm-cells = <3>; + + clocks = <&tcu TCU_CLK_TIMER0 + &tcu TCU_CLK_TIMER1 + &tcu TCU_CLK_TIMER2 + &tcu TCU_CLK_TIMER3 + &tcu TCU_CLK_TIMER4 + &tcu TCU_CLK_TIMER5 + &tcu TCU_CLK_TIMER6 + &tcu TCU_CLK_TIMER7>; + clock-names = "timer0", "timer1", "timer2", "timer3", + "timer4", "timer5", "timer6", "timer7"; + }; + + ost: timer@e0 { + compatible = "ingenic,jz4770-ost"; + reg = <0xe0 0x20>; + + clocks = <&tcu TCU_CLK_OST>; + clock-names = "ost"; + + interrupts = <15>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt b/Documentation/devicetree/bindings/timer/renesas,cmt.txt index c5220bcd852b..a444cfc5852a 100644 --- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt @@ -12,16 +12,13 @@ datasheets. Required Properties: - compatible: must contain one or more of the following: - - "renesas,cmt-48-sh73a0" for the sh73A0 48-bit CMT - (CMT1) - - "renesas,cmt-48-r8a7740" for the r8a7740 48-bit CMT - (CMT1) - - "renesas,cmt-48" for all non-second generation 48-bit CMT - (CMT1 on sh73a0 and r8a7740) - This is a fallback for the above renesas,cmt-48-* entries. - - "renesas,r8a73a4-cmt0" for the 32-bit CMT0 device included in r8a73a4. - "renesas,r8a73a4-cmt1" for the 48-bit CMT1 device included in r8a73a4. + - "renesas,r8a7740-cmt0" for the 32-bit CMT0 device included in r8a7740. + - "renesas,r8a7740-cmt1" for the 48-bit CMT1 device included in r8a7740. + - "renesas,r8a7740-cmt2" for the 32-bit CMT2 device included in r8a7740. + - "renesas,r8a7740-cmt3" for the 32-bit CMT3 device included in r8a7740. + - "renesas,r8a7740-cmt4" for the 32-bit CMT4 device included in r8a7740. - "renesas,r8a7743-cmt0" for the 32-bit CMT0 device included in r8a7743. - "renesas,r8a7743-cmt1" for the 48-bit CMT1 device included in r8a7743. - "renesas,r8a7744-cmt0" for the 32-bit CMT0 device included in r8a7744. @@ -31,29 +28,38 @@ Required Properties: - "renesas,r8a77470-cmt0" for the 32-bit CMT0 device included in r8a77470. - "renesas,r8a77470-cmt1" for the 48-bit CMT1 device included in r8a77470. - "renesas,r8a774a1-cmt0" for the 32-bit CMT0 device included in r8a774a1. - - "renesas,r8a774a1-cmt1" for the 48-bit CMT1 device included in r8a774a1. + - "renesas,r8a774a1-cmt1" for the 48-bit CMT devices included in r8a774a1. - "renesas,r8a774c0-cmt0" for the 32-bit CMT0 device included in r8a774c0. - - "renesas,r8a774c0-cmt1" for the 48-bit CMT1 device included in r8a774c0. + - "renesas,r8a774c0-cmt1" for the 48-bit CMT devices included in r8a774c0. - "renesas,r8a7790-cmt0" for the 32-bit CMT0 device included in r8a7790. - "renesas,r8a7790-cmt1" for the 48-bit CMT1 device included in r8a7790. - "renesas,r8a7791-cmt0" for the 32-bit CMT0 device included in r8a7791. - "renesas,r8a7791-cmt1" for the 48-bit CMT1 device included in r8a7791. + - "renesas,r8a7792-cmt0" for the 32-bit CMT0 device included in r8a7792. + - "renesas,r8a7792-cmt1" for the 48-bit CMT1 device included in r8a7792. - "renesas,r8a7793-cmt0" for the 32-bit CMT0 device included in r8a7793. - "renesas,r8a7793-cmt1" for the 48-bit CMT1 device included in r8a7793. - "renesas,r8a7794-cmt0" for the 32-bit CMT0 device included in r8a7794. - "renesas,r8a7794-cmt1" for the 48-bit CMT1 device included in r8a7794. - "renesas,r8a7795-cmt0" for the 32-bit CMT0 device included in r8a7795. - - "renesas,r8a7795-cmt1" for the 48-bit CMT1 device included in r8a7795. + - "renesas,r8a7795-cmt1" for the 48-bit CMT devices included in r8a7795. - "renesas,r8a7796-cmt0" for the 32-bit CMT0 device included in r8a7796. - - "renesas,r8a7796-cmt1" for the 48-bit CMT1 device included in r8a7796. + - "renesas,r8a7796-cmt1" for the 48-bit CMT devices included in r8a7796. - "renesas,r8a77965-cmt0" for the 32-bit CMT0 device included in r8a77965. - - "renesas,r8a77965-cmt1" for the 48-bit CMT1 device included in r8a77965. + - "renesas,r8a77965-cmt1" for the 48-bit CMT devices included in r8a77965. - "renesas,r8a77970-cmt0" for the 32-bit CMT0 device included in r8a77970. - - "renesas,r8a77970-cmt1" for the 48-bit CMT1 device included in r8a77970. + - "renesas,r8a77970-cmt1" for the 48-bit CMT devices included in r8a77970. - "renesas,r8a77980-cmt0" for the 32-bit CMT0 device included in r8a77980. - - "renesas,r8a77980-cmt1" for the 48-bit CMT1 device included in r8a77980. + - "renesas,r8a77980-cmt1" for the 48-bit CMT devices included in r8a77980. - "renesas,r8a77990-cmt0" for the 32-bit CMT0 device included in r8a77990. - - "renesas,r8a77990-cmt1" for the 48-bit CMT1 device included in r8a77990. + - "renesas,r8a77990-cmt1" for the 48-bit CMT devices included in r8a77990. + - "renesas,r8a77995-cmt0" for the 32-bit CMT0 device included in r8a77995. + - "renesas,r8a77995-cmt1" for the 48-bit CMT devices included in r8a77995. + - "renesas,sh73a0-cmt0" for the 32-bit CMT0 device included in sh73a0. + - "renesas,sh73a0-cmt1" for the 48-bit CMT1 device included in sh73a0. + - "renesas,sh73a0-cmt2" for the 32-bit CMT2 device included in sh73a0. + - "renesas,sh73a0-cmt3" for the 32-bit CMT3 device included in sh73a0. + - "renesas,sh73a0-cmt4" for the 32-bit CMT4 device included in sh73a0. - "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car Gen2 and RZ/G1. @@ -63,7 +69,7 @@ Required Properties: listed above. - "renesas,rcar-gen3-cmt0" for 32-bit CMT0 devices included in R-Car Gen3 and RZ/G2. - - "renesas,rcar-gen3-cmt1" for 48-bit CMT1 devices included in R-Car Gen3 + - "renesas,rcar-gen3-cmt1" for 48-bit CMT devices included in R-Car Gen3 and RZ/G2. These are fallbacks for R-Car Gen3 and RZ/G2 entries listed above. diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 2e742d399e87..870ac52d2225 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -104,6 +104,8 @@ properties: - infineon,slb9645tt # Infineon TLV493D-A1B6 I2C 3D Magnetic Sensor - infineon,tlv493d-a1b6 + # Inspur Power System power supply unit version 1 + - inspur,ipsps1 # Intersil ISL29028 Ambient Light and Proximity Sensor - isil,isl29028 # Intersil ISL29030 Ambient Light and Proximity Sensor diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt index a74720486ee2..d78ef63935f9 100644 --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt @@ -54,6 +54,8 @@ Optional properties: PHY reset from the UFS controller. - resets : reset node register - reset-names : describe reset node register, the "rst" corresponds to reset the whole UFS IP. +- reset-gpios : A phandle and gpio specifier denoting the GPIO connected + to the RESET pin of the UFS memory device. Note: If above properties are not defined it can be assumed that the supply regulators or clocks are always on. diff --git a/Documentation/devicetree/bindings/usb/cdns-usb3.txt b/Documentation/devicetree/bindings/usb/cdns-usb3.txt new file mode 100644 index 000000000000..b7dc606d37b5 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/cdns-usb3.txt @@ -0,0 +1,45 @@ +Binding for the Cadence USBSS-DRD controller + +Required properties: + - reg: Physical base address and size of the controller's register areas. + Controller has 3 different regions: + - HOST registers area + - DEVICE registers area + - OTG/DRD registers area + - reg-names - register memory area names: + "xhci" - for HOST registers space + "dev" - for DEVICE registers space + "otg" - for OTG/DRD registers space + - compatible: Should contain: "cdns,usb3" + - interrupts: Interrupts used by cdns3 controller: + "host" - interrupt used by XHCI driver. + "peripheral" - interrupt used by device driver + "otg" - interrupt used by DRD/OTG part of driver + +Optional properties: + - maximum-speed : valid arguments are "super-speed", "high-speed" and + "full-speed"; refer to usb/generic.txt + - dr_mode: Should be one of "host", "peripheral" or "otg". + - phys: reference to the USB PHY + - phy-names: from the *Generic PHY* bindings; + Supported names are: + - cdns3,usb2-phy + - cdns3,usb3-phy + + - cdns,on-chip-buff-size : size of memory intended as internal memory for endpoints + buffers expressed in KB + +Example: + usb@f3000000 { + compatible = "cdns,usb3"; + interrupts = , + , + ; + interrupt-names = "host", "peripheral", "otg"; + reg = <0xf3000000 0x10000>, /* memory area for HOST registers */ + <0xf3010000 0x10000>, /* memory area for DEVICE registers */ + <0xf3020000 0x10000>; /* memory area for OTG/DRD registers */ + reg-names = "xhci", "dev", "otg"; + phys = <&usb2_phy>, <&usb3_phy>; + phy-names = "cdns3,usb2-phy", "cnds3,usb3-phy"; + }; diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt index a254386a91ad..cfc9f40ab641 100644 --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt @@ -10,6 +10,7 @@ Required properties: "fsl,imx6sx-usb" "fsl,imx6ul-usb" "fsl,imx7d-usb" + "fsl,imx7ulp-usb" "lsi,zevio-usb" "qcom,ci-hdrc" "chipidea,usb2" diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt index b7111f43fa59..66c394f9e11f 100644 --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt @@ -12,13 +12,11 @@ Required properties: - interrupts: interrupt number to the cpu. - clocks: from common clock binding: handle to usb clock. - clock-names: from common clock binding: Shall be "usbhost". - - port: if in the SoC there are EHCI phys, they should be listed here. - One phy per port. Each port should have following entries: - - reg: port number on EHCI controller, e.g - On Exynos5250, port 0 is USB2.0 otg phy - port 1 is HSIC phy0 - port 2 is HSIC phy1 - - phys: from the *Generic PHY* bindings; specifying phy used by port. + - phys: from the *Generic PHY* bindings; array specifying phy(s) used + by the root port. + - phy-names: from the *Generic PHY* bindings; array of the names for + each phy for the root ports, must be a subset of the following: + "host", "hsic0", "hsic1". Optional properties: - samsung,vbus-gpio: if present, specifies the GPIO that @@ -35,12 +33,8 @@ Example: clocks = <&clock 285>; clock-names = "usbhost"; - #address-cells = <1>; - #size-cells = <0>; - port@0 { - reg = <0>; - phys = <&usb2phy 1>; - }; + phys = <&usb2phy 1>; + phy-names = "host"; }; OHCI @@ -52,13 +46,11 @@ Required properties: - interrupts: interrupt number to the cpu. - clocks: from common clock binding: handle to usb clock. - clock-names: from common clock binding: Shall be "usbhost". - - port: if in the SoC there are OHCI phys, they should be listed here. - One phy per port. Each port should have following entries: - - reg: port number on OHCI controller, e.g - On Exynos5250, port 0 is USB2.0 otg phy - port 1 is HSIC phy0 - port 2 is HSIC phy1 - - phys: from the *Generic PHY* bindings, specifying phy used by port. + - phys: from the *Generic PHY* bindings; array specifying phy(s) used + by the root port. + - phy-names: from the *Generic PHY* bindings; array of the names for + each phy for the root ports, must be a subset of the following: + "host", "hsic0", "hsic1". Example: usb@12120000 { @@ -69,13 +61,8 @@ Example: clocks = <&clock 285>; clock-names = "usbhost"; - #address-cells = <1>; - #size-cells = <0>; - port@0 { - reg = <0>; - phys = <&usb2phy 1>; - }; - + phys = <&usb2phy 1>; + phy-names = "host"; }; DWC3 diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt index a5d011d2efc8..ba2e32d500c0 100644 --- a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt +++ b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt @@ -11,13 +11,6 @@ Required sub-node: Documentation/devicetree/bindings/connector/usb-connector.txt -Deprecated properties : -- fcs,max-sink-microvolt : Maximum sink voltage accepted by port controller -- fcs,max-sink-microamp : Maximum sink current accepted by port controller -- fcs,max-sink-microwatt : Maximum sink power accepted by port controller -- fcs,operating-sink-microwatt : Minimum amount of power accepted from a sink - when negotiating - Example: diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt index 0a74ab8dfdc2..cf5a1ad456e6 100644 --- a/Documentation/devicetree/bindings/usb/generic.txt +++ b/Documentation/devicetree/bindings/usb/generic.txt @@ -30,6 +30,10 @@ Optional properties: optional for OTG device. - adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is optional for OTG device. + - usb-role-switch: boolean, indicates that the device is capable of assigning + the USB data role (USB host or USB device) for a given + USB connector, such as Type-C, Type-B(micro). + see connector/usb-connector.txt. This is an attribute to a USB controller such as: diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt index 266c2d917a28..f3e4acecabe8 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt @@ -30,7 +30,8 @@ Required properties: the following ones are optional: "ref_ck": reference clock used by low power mode etc, "mcu_ck": mcu_bus clock for register access, - "dma_ck": dma_bus clock for data transfer by DMA + "dma_ck": dma_bus clock for data transfer by DMA, + "xhci_ck": controller clock - phys : see usb-hcd.txt in the current directory @@ -100,7 +101,7 @@ Required properties: - clocks : a list of phandle + clock-specifier pairs, one for each entry in clock-names - clock-names : must contain "sys_ck", and the following ones are optional: - "ref_ck", "mcu_ck" and "dma_ck" + "ref_ck", "mcu_ck" and "dma_ck", "xhci_ck" Optional properties: - vbus-supply : reference to the VBUS regulator; diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt index 3382b5cb471d..b9af7f5ee91d 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt @@ -16,7 +16,7 @@ Required properties: entry in clock-names - clock-names : must contain "sys_ck" for clock of controller, the following clocks are optional: - "ref_ck", "mcu_ck" and "dam_ck"; + "ref_ck", "mcu_ck" and "dma_ck"; - phys : see usb-hcd.txt in the current directory - dr_mode : should be one of "host", "peripheral" or "otg", refer to usb/generic.txt @@ -28,8 +28,13 @@ Optional properties: parent's address space - extcon : external connector for vbus and idpin changes detection, needed when supports dual-role mode. + it's considered valid for compatibility reasons, not allowed for + new bindings, and use "usb-role-switch" property instead. - vbus-supply : reference to the VBUS regulator, needed when supports dual-role mode. + it's considered valid for compatibility reasons, not allowed for + new bindings, and put into a usb-connector node. + see connector/usb-connector.txt. - pinctrl-names : a pinctrl state named "default" is optional, and need be defined if auto drd switch is enabled, that means the property dr_mode is set as "otg", and meanwhile the property "mediatek,enable-manual-drd" @@ -39,6 +44,8 @@ Optional properties: - maximum-speed : valid arguments are "super-speed", "high-speed" and "full-speed"; refer to usb/generic.txt + - usb-role-switch : use USB Role Switch to support dual-role switch, but + not extcon; see usb/generic.txt. - enable-manual-drd : supports manual dual-role switch via debugfs; usually used when receptacle is TYPE-A and also wants to support dual-role mode. @@ -61,6 +68,9 @@ The xhci should be added as subnode to mtu3 as shown in the following example if host mode is enabled. The DT binding details of xhci can be found in: Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt +The port would be added as subnode if use "usb-role-switch" property. + see graph.txt + Example: ssusb: usb@11271000 { compatible = "mediatek,mt8173-mtu3"; diff --git a/Documentation/devicetree/bindings/usb/renesas,usb3.txt b/Documentation/devicetree/bindings/usb/renesas,usb3-peri.txt similarity index 100% rename from Documentation/devicetree/bindings/usb/renesas,usb3.txt rename to Documentation/devicetree/bindings/usb/renesas,usb3-peri.txt diff --git a/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt b/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt new file mode 100644 index 000000000000..3d05ae56cb0d --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt @@ -0,0 +1,30 @@ +USB GPIO Based Connection Detection + +This is typically used to switch dual role mode from the USB ID pin connected +to an input GPIO, and also used to enable/disable device mode from the USB +Vbus pin connected to an input GPIO. + +Required properties: +- compatible : should include "gpio-usb-b-connector" and "usb-b-connector". +- id-gpios, vbus-gpios : input gpios, either one of them must be present, + and both can be present as well. + see connector/usb-connector.txt + +Optional properties: +- vbus-supply : can be present if needed when supports dual role mode. + see connector/usb-connector.txt + +- Sub-nodes: + - port : can be present. + see graph.txt + +Example: + +&mtu3 { + connector { + compatible = "gpio-usb-b-connector", "usb-b-connector"; + type = "micro"; + id-gpios = <&pio 12 GPIO_ACTIVE_HIGH>; + vbus-supply = <&usb_p0_vbus>; + }; +}; diff --git a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt index a85a631ec434..b353b9816487 100644 --- a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt +++ b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt @@ -7,6 +7,7 @@ Required properties: "fsl,vf610-usbmisc" for Vybrid vf610 "fsl,imx6sx-usbmisc" for imx6sx "fsl,imx7d-usbmisc" for imx7d + "fsl,imx7ulp-usbmisc" for imx7ulp - reg: Should contain registers location and length Examples: diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 29dcc6f8a64a..967e78c5ec0a 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -27,6 +27,8 @@ patternProperties: description: Abilis Systems "^abracon,.*": description: Abracon Corporation + "^acme,.*": + description: Acme Systems srl "^actions,.*": description: Actions Semiconductor Co., Ltd. "^active-semi,.*": @@ -81,6 +83,8 @@ patternProperties: description: Analogix Semiconductor, Inc. "^andestech,.*": description: Andes Technology Corporation + "^anvo,.*": + description: Anvo-Systems Dresden GmbH "^apm,.*": description: Applied Micro Circuits Corporation (APM) "^aptina,.*": @@ -269,6 +273,8 @@ patternProperties: description: Emerging Display Technologies "^eeti,.*": description: eGalax_eMPIA Technology Inc + "^einfochips,.*": + description: Einfochips "^elan,.*": description: Elan Microelectronic Corp. "^elgin,.*": @@ -437,6 +443,8 @@ patternProperties: description: Innolux Corporation "^inside-secure,.*": description: INSIDE Secure + "^inspur,.*": + description: Inspur Corporation "^intel,.*": description: Intel Corporation "^intercontrol,.*": @@ -503,6 +511,8 @@ patternProperties: description: Lantiq Semiconductor "^lattice,.*": description: Lattice Semiconductor + "^leez,.*": + description: Leez "^lego,.*": description: LEGO Systems A/S "^lemaker,.*": @@ -531,6 +541,8 @@ patternProperties: description: Linear Technology Corporation "^logicpd,.*": description: Logic PD, Inc. + "^longcheer,.*": + description: Longcheer Technology (Shanghai) Co., Ltd. "^lsi,.*": description: LSI Corp. (LSI Logic) "^lwn,.*": @@ -551,6 +563,8 @@ patternProperties: description: mCube "^meas,.*": description: Measurement Specialties + "^mecer,.*": + description: Mustek Limited "^mediatek,.*": description: MediaTek Inc. "^megachips,.*": @@ -577,6 +591,8 @@ patternProperties: description: Micro Crystal AG "^micron,.*": description: Micron Technology Inc. + "^microsoft,.*": + description: Microsoft Corporation "^mikroe,.*": description: MikroElektronika d.o.o. "^miniand,.*": @@ -815,6 +831,8 @@ patternProperties: description: Semtech Corporation "^sensirion,.*": description: Sensirion AG + "^sensortek,.*": + description: Sensortek Technology Corporation "^sff,.*": description: Small Form Factor Committee "^sgd,.*": diff --git a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml new file mode 100644 index 000000000000..3a54f58683a0 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/allwinner,sun4i-a10-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A10 Watchdog Device Tree Bindings + +allOf: + - $ref: "watchdog.yaml#" + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +properties: + compatible: + oneOf: + - const: allwinner,sun4i-a10-wdt + - const: allwinner,sun6i-a31-wdt + - items: + - const: allwinner,sun50i-a64-wdt + - const: allwinner,sun6i-a31-wdt + - items: + - const: allwinner,sun50i-h6-wdt + - const: allwinner,sun6i-a31-wdt + - items: + - const: allwinner,suniv-f1c100s-wdt + - const: allwinner,sun4i-a10-wdt + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - interrupts + +unevaluatedProperties: false + +examples: + - | + wdt: watchdog@1c20c90 { + compatible = "allwinner,sun4i-a10-wdt"; + reg = <0x01c20c90 0x10>; + interrupts = <24>; + clocks = <&osc24M>; + timeout-sec = <10>; + }; + +... diff --git a/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml b/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml new file mode 100644 index 000000000000..d7352f709b37 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 BayLibre, SAS +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/watchdog/amlogic,meson-gxbb-wdt.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Meson GXBB SoCs Watchdog timer + +maintainers: + - Neil Armstrong + +properties: + compatible: + enum: + - amlogic,meson-gxbb-wdt + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + description: + A phandle to the clock of this PHY + +required: + - compatible + - reg + - clocks + +examples: + - | + watchdog@98d0 { + compatible = "amlogic,meson-gxbb-wdt"; + reg = <0x98d0 0x10>; + clocks = <&xtal>; + }; diff --git a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt index c5077a1f5cb3..d78d4a8fb868 100644 --- a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt @@ -4,6 +4,7 @@ Required properties: - compatible: must be one of: - "aspeed,ast2400-wdt" - "aspeed,ast2500-wdt" + - "aspeed,ast2600-wdt" - reg: physical base address of the controller and length of memory mapped region diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt new file mode 100644 index 000000000000..f902508d6cac --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt @@ -0,0 +1,22 @@ +* Freescale i.MX7ULP Watchdog Timer (WDT) Controller + +Required properties: +- compatible : Should be "fsl,imx7ulp-wdt" +- reg : Should contain WDT registers location and length +- interrupts : Should contain WDT interrupt +- clocks: Should contain a phandle pointing to the gated peripheral clock. + +Optional properties: +- timeout-sec : Contains the watchdog timeout in seconds + +Examples: + +wdog1: watchdog@403d0000 { + compatible = "fsl,imx7ulp-wdt"; + reg = <0x403d0000 0x10000>; + interrupts = ; + clocks = <&pcc2 IMX7ULP_CLK_WDG1>; + assigned-clocks = <&pcc2 IMX7ULP_CLK_WDG1>; + assigned-clocks-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>; + timeout-sec = <40>; +}; diff --git a/Documentation/devicetree/bindings/watchdog/ingenic,jz4740-wdt.txt b/Documentation/devicetree/bindings/watchdog/ingenic,jz4740-wdt.txt deleted file mode 100644 index ce1cb72d5345..000000000000 --- a/Documentation/devicetree/bindings/watchdog/ingenic,jz4740-wdt.txt +++ /dev/null @@ -1,17 +0,0 @@ -Ingenic Watchdog Timer (WDT) Controller for JZ4740 & JZ4780 - -Required properties: -compatible: "ingenic,jz4740-watchdog" or "ingenic,jz4780-watchdog" -reg: Register address and length for watchdog registers -clocks: phandle to the RTC clock -clock-names: should be "rtc" - -Example: - -watchdog: jz4740-watchdog@10002000 { - compatible = "ingenic,jz4740-watchdog"; - reg = <0x10002000 0x10>; - - clocks = <&cgu JZ4740_CLK_RTC>; - clock-names = "rtc"; -}; diff --git a/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt b/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt deleted file mode 100644 index c7fe36fa739c..000000000000 --- a/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt +++ /dev/null @@ -1,16 +0,0 @@ -Meson GXBB SoCs Watchdog timer - -Required properties: - -- compatible : should be "amlogic,meson-gxbb-wdt" -- reg : Specifies base physical address and size of the registers. -- clocks : Should be a phandle to the Watchdog clock source, for GXBB the xtal - is the default clock source. - -Example: - -wdt: watchdog@98d0 { - compatible = "amlogic,meson-gxbb-wdt"; - reg = <0 0x98d0 0x0 0x10>; - clocks = <&xtal>; -}; diff --git a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt deleted file mode 100644 index e65198d82a2b..000000000000 --- a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt +++ /dev/null @@ -1,22 +0,0 @@ -Allwinner SoCs Watchdog timer - -Required properties: - -- compatible : should be one of - "allwinner,sun4i-a10-wdt" - "allwinner,sun6i-a31-wdt" - "allwinner,sun50i-a64-wdt","allwinner,sun6i-a31-wdt" - "allwinner,sun50i-h6-wdt","allwinner,sun6i-a31-wdt" - "allwinner,suniv-f1c100s-wdt", "allwinner,sun4i-a10-wdt" -- reg : Specifies base physical address and size of the registers. - -Optional properties: -- timeout-sec : Contains the watchdog timeout in seconds - -Example: - -wdt: watchdog@1c20c90 { - compatible = "allwinner,sun4i-a10-wdt"; - reg = <0x01c20c90 0x10>; - timeout-sec = <10>; -}; diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.yaml b/Documentation/devicetree/bindings/watchdog/watchdog.yaml new file mode 100644 index 000000000000..187bf6cb62bf --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/watchdog.yaml @@ -0,0 +1,26 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/watchdog.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Watchdog Generic Bindings + +maintainers: + - Guenter Roeck + - Wim Van Sebroeck + +description: | + This document describes generic bindings which can be used to + describe watchdog devices in a device tree. + +properties: + $nodename: + pattern: "^watchdog(@.*|-[0-9a-f])?$" + + timeout-sec: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Contains the watchdog timeout in seconds. + +... diff --git a/Documentation/devicetree/writing-schema.md b/Documentation/devicetree/writing-schema.md deleted file mode 100644 index dc032db36262..000000000000 --- a/Documentation/devicetree/writing-schema.md +++ /dev/null @@ -1,130 +0,0 @@ -# Writing DeviceTree Bindings in json-schema - -Devicetree bindings are written using json-schema vocabulary. Schema files are -written in a JSON compatible subset of YAML. YAML is used instead of JSON as it -considered more human readable and has some advantages such as allowing -comments (Prefixed with '#'). - -## Schema Contents - -Each schema doc is a structured json-schema which is defined by a set of -top-level properties. Generally, there is one binding defined per file. The -top-level json-schema properties used are: - -- __$id__ - A json-schema unique identifier string. The string must be a valid -URI typically containing the binding's filename and path. For DT schema, it must -begin with "http://devicetree.org/schemas/". The URL is used in constructing -references to other files specified in schema "$ref" properties. A $ref values -with a leading '/' will have the hostname prepended. A $ref value a relative -path or filename only will be prepended with the hostname and path components -of the current schema file's '$id' value. A URL is used even for local files, -but there may not actually be files present at those locations. - -- __$schema__ - Indicates the meta-schema the schema file adheres to. - -- __title__ - A one line description on the contents of the binding schema. - -- __maintainers__ - A DT specific property. Contains a list of email address(es) -for maintainers of this binding. - -- __description__ - Optional. A multi-line text block containing any detailed -information about this binding. It should contain things such as what the block -or device does, standards the device conforms to, and links to datasheets for -more information. - -- __select__ - Optional. A json-schema used to match nodes for applying the -schema. By default without 'select', nodes are matched against their possible -compatible string values or node name. Most bindings should not need select. - -- __allOf__ - Optional. A list of other schemas to include. This is used to -include other schemas the binding conforms to. This may be schemas for a -particular class of devices such as I2C or SPI controllers. - -- __properties__ - A set of sub-schema defining all the DT properties for the -binding. The exact schema syntax depends on whether properties are known, -common properties (e.g. 'interrupts') or are binding/vendor specific properties. - - A property can also define a child DT node with child properties defined -under it. - - For more details on properties sections, see 'Property Schema' section. - -- __patternProperties__ - Optional. Similar to 'properties', but names are regex. - -- __required__ - A list of DT properties from the 'properties' section that -must always be present. - -- __examples__ - Optional. A list of one or more DTS hunks implementing the -binding. Note: YAML doesn't allow leading tabs, so spaces must be used instead. - -Unless noted otherwise, all properties are required. - -## Property Schema - -The 'properties' section of the schema contains all the DT properties for a -binding. Each property contains a set of constraints using json-schema -vocabulary for that property. The properties schemas are what is used for -validation of DT files. - -For common properties, only additional constraints not covered by the common -binding schema need to be defined such as how many values are valid or what -possible values are valid. - -Vendor specific properties will typically need more detailed schema. With the -exception of boolean properties, they should have a reference to a type in -schemas/types.yaml. A "description" property is always required. - -The Devicetree schemas don't exactly match the YAML encoded DT data produced by -dtc. They are simplified to make them more compact and avoid a bunch of -boilerplate. The tools process the schema files to produce the final schema for -validation. There are currently 2 transformations the tools perform. - -The default for arrays in json-schema is they are variable sized and allow more -entries than explicitly defined. This can be restricted by defining 'minItems', -'maxItems', and 'additionalItems'. However, for DeviceTree Schemas, a fixed -size is desired in most cases, so these properties are added based on the -number of entries in an 'items' list. - -The YAML Devicetree format also makes all string values an array and scalar -values a matrix (in order to define groupings) even when only a single value -is present. Single entries in schemas are fixed up to match this encoding. - -## Testing - -### Dependencies - -The DT schema project must be installed in order to validate the DT schema -binding documents and validate DTS files using the DT schema. The DT schema -project can be installed with pip: - -`pip3 install git+https://github.com/devicetree-org/dt-schema.git@master` - -dtc must also be built with YAML output support enabled. This requires that -libyaml and its headers be installed on the host system. - -### Running checks - -The DT schema binding documents must be validated using the meta-schema (the -schema for the schema) to ensure they are both valid json-schema and valid -binding schema. All of the DT binding documents can be validated using the -`dt_binding_check` target: - -`make dt_binding_check` - -In order to perform validation of DT source files, use the `dtbs_check` target: - -`make dtbs_check` - -This will first run the `dt_binding_check` which generates the processed schema. - -It is also possible to run checks with a single schema file by setting the -'DT_SCHEMA_FILES' variable to a specific schema file. - -`make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/trivial-devices.yaml` - - -## json-schema Resources - -[JSON-Schema Specifications](http://json-schema.org/) - -[Using JSON Schema Book](http://usingjsonschema.com/) diff --git a/Documentation/devicetree/writing-schema.rst b/Documentation/devicetree/writing-schema.rst new file mode 100644 index 000000000000..f4a638072262 --- /dev/null +++ b/Documentation/devicetree/writing-schema.rst @@ -0,0 +1,154 @@ +:orphan: + +Writing DeviceTree Bindings in json-schema +========================================== + +Devicetree bindings are written using json-schema vocabulary. Schema files are +written in a JSON compatible subset of YAML. YAML is used instead of JSON as it +considered more human readable and has some advantages such as allowing +comments (Prefixed with '#'). + +Schema Contents +--------------- + +Each schema doc is a structured json-schema which is defined by a set of +top-level properties. Generally, there is one binding defined per file. The +top-level json-schema properties used are: + +$id + A json-schema unique identifier string. The string must be a valid + URI typically containing the binding's filename and path. For DT schema, it must + begin with "http://devicetree.org/schemas/". The URL is used in constructing + references to other files specified in schema "$ref" properties. A $ref values + with a leading '/' will have the hostname prepended. A $ref value a relative + path or filename only will be prepended with the hostname and path components + of the current schema file's '$id' value. A URL is used even for local files, + but there may not actually be files present at those locations. + +$schema + Indicates the meta-schema the schema file adheres to. + +title + A one line description on the contents of the binding schema. + +maintainers + A DT specific property. Contains a list of email address(es) + for maintainers of this binding. + +description + Optional. A multi-line text block containing any detailed + information about this binding. It should contain things such as what the block + or device does, standards the device conforms to, and links to datasheets for + more information. + +select + Optional. A json-schema used to match nodes for applying the + schema. By default without 'select', nodes are matched against their possible + compatible string values or node name. Most bindings should not need select. + + allOf + Optional. A list of other schemas to include. This is used to + include other schemas the binding conforms to. This may be schemas for a + particular class of devices such as I2C or SPI controllers. + + properties + A set of sub-schema defining all the DT properties for the + binding. The exact schema syntax depends on whether properties are known, + common properties (e.g. 'interrupts') or are binding/vendor specific properties. + +A property can also define a child DT node with child properties defined +under it. + +For more details on properties sections, see 'Property Schema' section. + +patternProperties + Optional. Similar to 'properties', but names are regex. + +required + A list of DT properties from the 'properties' section that + must always be present. + +examples + Optional. A list of one or more DTS hunks implementing the + binding. Note: YAML doesn't allow leading tabs, so spaces must be used instead. + +Unless noted otherwise, all properties are required. + +Property Schema +--------------- + +The 'properties' section of the schema contains all the DT properties for a +binding. Each property contains a set of constraints using json-schema +vocabulary for that property. The properties schemas are what is used for +validation of DT files. + +For common properties, only additional constraints not covered by the common +binding schema need to be defined such as how many values are valid or what +possible values are valid. + +Vendor specific properties will typically need more detailed schema. With the +exception of boolean properties, they should have a reference to a type in +schemas/types.yaml. A "description" property is always required. + +The Devicetree schemas don't exactly match the YAML encoded DT data produced by +dtc. They are simplified to make them more compact and avoid a bunch of +boilerplate. The tools process the schema files to produce the final schema for +validation. There are currently 2 transformations the tools perform. + +The default for arrays in json-schema is they are variable sized and allow more +entries than explicitly defined. This can be restricted by defining 'minItems', +'maxItems', and 'additionalItems'. However, for DeviceTree Schemas, a fixed +size is desired in most cases, so these properties are added based on the +number of entries in an 'items' list. + +The YAML Devicetree format also makes all string values an array and scalar +values a matrix (in order to define groupings) even when only a single value +is present. Single entries in schemas are fixed up to match this encoding. + +Testing +------- + +Dependencies +~~~~~~~~~~~~ + +The DT schema project must be installed in order to validate the DT schema +binding documents and validate DTS files using the DT schema. The DT schema +project can be installed with pip:: + + pip3 install git+https://github.com/devicetree-org/dt-schema.git@master + +dtc must also be built with YAML output support enabled. This requires that +libyaml and its headers be installed on the host system. + +Running checks +~~~~~~~~~~~~~~ + +The DT schema binding documents must be validated using the meta-schema (the +schema for the schema) to ensure they are both valid json-schema and valid +binding schema. All of the DT binding documents can be validated using the +``dt_binding_check`` target:: + + make dt_binding_check + +In order to perform validation of DT source files, use the `dtbs_check` target:: + + make dtbs_check + +This will first run the `dt_binding_check` which generates the processed schema. + +It is also possible to run checks with a single schema file by setting the +``DT_SCHEMA_FILES`` variable to a specific schema file. + +:: + + make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/trivial-devices.yaml + make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/trivial-devices.yaml + + +json-schema Resources +--------------------- + + +`JSON-Schema Specifications `_ + +`Using JSON Schema Book `_ diff --git a/Documentation/driver-api/device_link.rst b/Documentation/driver-api/device_link.rst index ae1e3d0394b0..1b5020ec6517 100644 --- a/Documentation/driver-api/device_link.rst +++ b/Documentation/driver-api/device_link.rst @@ -78,8 +78,8 @@ typically deleted in its ``->remove`` callback for symmetry. That way, if the driver is compiled as a module, the device link is added on module load and orderly deleted on unload. The same restrictions that apply to device link addition (e.g. exclusion of a parallel suspend/resume transition) apply equally -to deletion. Device links with ``DL_FLAG_STATELESS`` unset (i.e. managed -device links) are deleted automatically by the driver core. +to deletion. Device links managed by the driver core are deleted automatically +by it. Several flags may be specified on device link addition, two of which have already been mentioned above: ``DL_FLAG_STATELESS`` to express that no diff --git a/Documentation/driver-api/dmaengine/index.rst b/Documentation/driver-api/dmaengine/index.rst index 3026fa975937..b9df904d0a79 100644 --- a/Documentation/driver-api/dmaengine/index.rst +++ b/Documentation/driver-api/dmaengine/index.rst @@ -47,7 +47,7 @@ This book adds some notes about PXA DMA pxa_dma -.. only:: subproject +.. only:: subproject and html Indices ======= diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst index 921c71a3d683..3fdb32422f8a 100644 --- a/Documentation/driver-api/gpio/driver.rst +++ b/Documentation/driver-api/gpio/driver.rst @@ -69,9 +69,9 @@ driver code: The code implementing a gpio_chip should support multiple instances of the controller, preferably using the driver model. That code will configure each -gpio_chip and issue ``gpiochip_add[_data]()`` or ``devm_gpiochip_add_data()``. -Removing a GPIO controller should be rare; use ``[devm_]gpiochip_remove()`` -when it is unavoidable. +gpio_chip and issue gpiochip_add(), gpiochip_add_data(), or +devm_gpiochip_add_data(). Removing a GPIO controller should be rare; use +gpiochip_remove() when it is unavoidable. Often a gpio_chip is part of an instance-specific structure with states not exposed by the GPIO interfaces, such as addressing, power management, and more. @@ -259,7 +259,7 @@ most often cascaded off a parent interrupt controller, and in some special cases the GPIO logic is melded with a SoC's primary interrupt controller. The IRQ portions of the GPIO block are implemented using an irq_chip, using -the header . So basically such a driver is utilizing two sub- +the header . So this combined driver is utilizing two sub- systems simultaneously: gpio and irq. It is legal for any IRQ consumer to request an IRQ from any irqchip even if it @@ -391,25 +391,119 @@ Infrastructure helpers for GPIO irqchips ---------------------------------------- To help out in handling the set-up and management of GPIO irqchips and the -associated irqdomain and resource allocation callbacks, the gpiolib has -some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig -symbol: +associated irqdomain and resource allocation callbacks. These are activated +by selecting the Kconfig symbol GPIOLIB_IRQCHIP. If the symbol +IRQ_DOMAIN_HIERARCHY is also selected, hierarchical helpers will also be +provided. A big portion of overhead code will be managed by gpiolib, +under the assumption that your interrupts are 1-to-1-mapped to the +GPIO line index: -- gpiochip_irqchip_add(): adds a chained cascaded irqchip to a gpiochip. It - will pass the struct gpio_chip* for the chip to all IRQ callbacks, so the - callbacks need to embed the gpio_chip in its state container and obtain a - pointer to the container using container_of(). - (See Documentation/driver-api/driver-model/design-patterns.rst) + GPIO line offset Hardware IRQ + 0 0 + 1 1 + 2 2 + ... ... + ngpio-1 ngpio-1 + +If some GPIO lines do not have corresponding IRQs, the bitmask valid_mask +and the flag need_valid_mask in gpio_irq_chip can be used to mask off some +lines as invalid for associating with IRQs. + +The preferred way to set up the helpers is to fill in the +struct gpio_irq_chip inside struct gpio_chip before adding the gpio_chip. +If you do this, the additional irq_chip will be set up by gpiolib at the +same time as setting up the rest of the GPIO functionality. The following +is a typical example of a cascaded interrupt handler using gpio_irq_chip: + + /* Typical state container with dynamic irqchip */ + struct my_gpio { + struct gpio_chip gc; + struct irq_chip irq; + }; + + int irq; /* from platform etc */ + struct my_gpio *g; + struct gpio_irq_chip *girq; + + /* Set up the irqchip dynamically */ + g->irq.name = "my_gpio_irq"; + g->irq.irq_ack = my_gpio_ack_irq; + g->irq.irq_mask = my_gpio_mask_irq; + g->irq.irq_unmask = my_gpio_unmask_irq; + g->irq.irq_set_type = my_gpio_set_irq_type; + + /* Get a pointer to the gpio_irq_chip */ + girq = &g->gc.irq; + girq->chip = &g->irq; + girq->parent_handler = ftgpio_gpio_irq_handler; + girq->num_parents = 1; + girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents), + GFP_KERNEL); + if (!girq->parents) + return -ENOMEM; + girq->default_type = IRQ_TYPE_NONE; + girq->handler = handle_bad_irq; + girq->parents[0] = irq; + + return devm_gpiochip_add_data(dev, &g->gc, g); + +The helper support using hierarchical interrupt controllers as well. +In this case the typical set-up will look like this: + + /* Typical state container with dynamic irqchip */ + struct my_gpio { + struct gpio_chip gc; + struct irq_chip irq; + struct fwnode_handle *fwnode; + }; + + int irq; /* from platform etc */ + struct my_gpio *g; + struct gpio_irq_chip *girq; + + /* Set up the irqchip dynamically */ + g->irq.name = "my_gpio_irq"; + g->irq.irq_ack = my_gpio_ack_irq; + g->irq.irq_mask = my_gpio_mask_irq; + g->irq.irq_unmask = my_gpio_unmask_irq; + g->irq.irq_set_type = my_gpio_set_irq_type; + + /* Get a pointer to the gpio_irq_chip */ + girq = &g->gc.irq; + girq->chip = &g->irq; + girq->default_type = IRQ_TYPE_NONE; + girq->handler = handle_bad_irq; + girq->fwnode = g->fwnode; + girq->parent_domain = parent; + girq->child_to_parent_hwirq = my_gpio_child_to_parent_hwirq; + + return devm_gpiochip_add_data(dev, &g->gc, g); + +As you can see pretty similar, but you do not supply a parent handler for +the IRQ, instead a parent irqdomain, an fwnode for the hardware and +a funcion .child_to_parent_hwirq() that has the purpose of looking up +the parent hardware irq from a child (i.e. this gpio chip) hardware irq. +As always it is good to look at examples in the kernel tree for advice +on how to find the required pieces. + +The old way of adding irqchips to gpiochips after registration is also still +available but we try to move away from this: + +- DEPRECATED: gpiochip_irqchip_add(): adds a chained cascaded irqchip to a + gpiochip. It will pass the struct gpio_chip* for the chip to all IRQ + callbacks, so the callbacks need to embed the gpio_chip in its state + container and obtain a pointer to the container using container_of(). + (See Documentation/driver-model/design-patterns.txt) - gpiochip_irqchip_add_nested(): adds a nested cascaded irqchip to a gpiochip, as discussed above regarding different types of cascaded irqchips. The cascaded irq has to be handled by a threaded interrupt handler. Apart from that it works exactly like the chained irqchip. -- gpiochip_set_chained_irqchip(): sets up a chained cascaded irq handler for a - gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler - data. Notice that we pass is as the handler data, since the irqchip data is - likely used by the parent irqchip. +- DEPRECATED: gpiochip_set_chained_irqchip(): sets up a chained cascaded irq + handler for a gpio_chip from a parent IRQ and passes the struct gpio_chip* + as handler data. Notice that we pass is as the handler data, since the + irqchip data is likely used by the parent irqchip. - gpiochip_set_nested_irqchip(): sets up a nested cascaded irq handler for a gpio_chip from a parent IRQ. As the parent IRQ has usually been @@ -418,11 +512,11 @@ symbol: If there is a need to exclude certain GPIO lines from the IRQ domain handled by these helpers, we can set .irq.need_valid_mask of the gpiochip before -``[devm_]gpiochip_add_data()`` is called. This allocates an .irq.valid_mask with as -many bits set as there are GPIO lines in the chip, each bit representing line -0..n-1. Drivers can exclude GPIO lines by clearing bits from this mask. The mask -must be filled in before gpiochip_irqchip_add() or gpiochip_irqchip_add_nested() -is called. +devm_gpiochip_add_data() or gpiochip_add_data() is called. This allocates an +.irq.valid_mask with as many bits set as there are GPIO lines in the chip, each +bit representing line 0..n-1. Drivers can exclude GPIO lines by clearing bits +from this mask. The mask must be filled in before gpiochip_irqchip_add() or +gpiochip_irqchip_add_nested() is called. To use the helpers please keep the following in mind: diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index d12a80f386a6..38e638abe3eb 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -65,6 +65,7 @@ available subsections can be seen below. dmaengine/index slimbus soundwire/index + thermal/index fpga/index acpi/index backlight/lp855x-driver.rst @@ -75,6 +76,7 @@ available subsections can be seen below. dell_rbu edid eisa + ipmb isa isapnp generic-counter diff --git a/Documentation/driver-api/ipmb.rst b/Documentation/driver-api/ipmb.rst index 7e2265144157..3ec3baed84c4 100644 --- a/Documentation/driver-api/ipmb.rst +++ b/Documentation/driver-api/ipmb.rst @@ -83,7 +83,7 @@ Instantiate the device ---------------------- After loading the driver, you can instantiate the device as -described in 'Documentation/i2c/instantiating-devices'. +described in 'Documentation/i2c/instantiating-devices.rst'. If you have multiple BMCs, each connected to your Satellite MC via a different I2C bus, you can instantiate a device for each of those BMCs. diff --git a/Documentation/driver-api/mtd/spi-nor.rst b/Documentation/driver-api/mtd/spi-nor.rst index f5333e3bf486..1f0437676762 100644 --- a/Documentation/driver-api/mtd/spi-nor.rst +++ b/Documentation/driver-api/mtd/spi-nor.rst @@ -59,7 +59,7 @@ Part III - How can drivers use the framework? The main API is spi_nor_scan(). Before you call the hook, a driver should initialize the necessary fields for spi_nor{}. Please see -drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to fsl-quadspi.c +drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to spi-fsl-qspi.c when you want to write a new driver for a SPI NOR controller. Another API is spi_nor_restore(), this is used to restore the status of SPI flash chip such as addressing mode. Call it whenever detach the driver from diff --git a/Documentation/driver-api/pinctl.rst b/Documentation/driver-api/pinctl.rst index 2bb1bc484278..3d2deaf48841 100644 --- a/Documentation/driver-api/pinctl.rst +++ b/Documentation/driver-api/pinctl.rst @@ -638,8 +638,8 @@ group of pins would work something like this:: } static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned selector, - unsigned ** const pins, - unsigned * const num_pins) + const unsigned ** pins, + unsigned * num_pins) { *pins = (unsigned *) foo_groups[selector].pins; *num_pins = foo_groups[selector].num_pins; @@ -705,7 +705,7 @@ group of pins would work something like this:: { u8 regbit = (1 << selector + group); - writeb((readb(MUX)|regbit), MUX) + writeb((readb(MUX)|regbit), MUX); return 0; } diff --git a/Documentation/driver-api/serial/n_gsm.rst b/Documentation/driver-api/serial/n_gsm.rst index f3ad9fd26408..286e7ff4d2d9 100644 --- a/Documentation/driver-api/serial/n_gsm.rst +++ b/Documentation/driver-api/serial/n_gsm.rst @@ -18,18 +18,22 @@ How to use it 2. switch the serial line to using the n_gsm line discipline by using TIOCSETD ioctl, 3. configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl, +4. obtain base gsmtty number for the used serial port, Major parts of the initialization program : (a good starting point is util-linux-ng/sys-utils/ldattach.c):: + #include + #include #include - #define N_GSM0710 21 /* GSM 0710 Mux */ + #include #define DEFAULT_SPEED B115200 #define SERIAL_PORT /dev/ttyS0 int ldisc = N_GSM0710; struct gsm_config c; struct termios configuration; + uint32_t first; /* open the serial port connected to the modem */ fd = open(SERIAL_PORT, O_RDWR | O_NOCTTY | O_NDELAY); @@ -58,21 +62,14 @@ Major parts of the initialization program : c.mtu = 127; /* set the new configuration */ ioctl(fd, GSMIOC_SETCONF, &c); + /* get first gsmtty device node */ + ioctl(fd, GSMIOC_GETFIRST, &first); + printf("first muxed line: /dev/gsmtty%i\n", first); /* and wait for ever to keep the line discipline enabled */ daemon(0,0); pause(); -4. create the devices corresponding to the "virtual" serial ports (take care, - each modem has its configuration and some DLC have dedicated functions, - for example GPS), starting with minor 1 (DLC0 is reserved for the management - of the mux):: - - MAJOR=`cat /proc/devices |grep gsmtty | awk '{print $1}` - for i in `seq 1 4`; do - mknod /dev/ttygsm$i c $MAJOR $i - done - 5. use these devices as plain serial ports. for example, it's possible: diff --git a/Documentation/driver-api/sgi-ioc4.rst b/Documentation/driver-api/sgi-ioc4.rst deleted file mode 100644 index 72709222d3c0..000000000000 --- a/Documentation/driver-api/sgi-ioc4.rst +++ /dev/null @@ -1,49 +0,0 @@ -==================================== -SGI IOC4 PCI (multi function) device -==================================== - -The SGI IOC4 PCI device is a bit of a strange beast, so some notes on -it are in order. - -First, even though the IOC4 performs multiple functions, such as an -IDE controller, a serial controller, a PS/2 keyboard/mouse controller, -and an external interrupt mechanism, it's not implemented as a -multifunction device. The consequence of this from a software -standpoint is that all these functions share a single IRQ, and -they can't all register to own the same PCI device ID. To make -matters a bit worse, some of the register blocks (and even registers -themselves) present in IOC4 are mixed-purpose between these several -functions, meaning that there's no clear "owning" device driver. - -The solution is to organize the IOC4 driver into several independent -drivers, "ioc4", "sgiioc4", and "ioc4_serial". Note that there is no -PS/2 controller driver as this functionality has never been wired up -on a shipping IO card. - -ioc4 -==== -This is the core (or shim) driver for IOC4. It is responsible for -initializing the basic functionality of the chip, and allocating -the PCI resources that are shared between the IOC4 functions. - -This driver also provides registration functions that the other -IOC4 drivers can call to make their presence known. Each driver -needs to provide a probe and remove function, which are invoked -by the core driver at appropriate times. The interface of these -IOC4 function probe and remove operations isn't precisely the same -as PCI device probe and remove operations, but is logically the -same operation. - -sgiioc4 -======= -This is the IDE driver for IOC4. Its name isn't very descriptive -simply for historical reasons (it used to be the only IOC4 driver -component). There's not much to say about it other than it hooks -up to the ioc4 driver via the appropriate registration, probe, and -remove functions. - -ioc4_serial -=========== -This is the serial driver for IOC4. There's not much to say about it -other than it hooks up to the ioc4 driver via the appropriate registration, -probe, and remove functions. diff --git a/Documentation/driver-api/soundwire/index.rst b/Documentation/driver-api/soundwire/index.rst index 6db026028f27..234911a0db99 100644 --- a/Documentation/driver-api/soundwire/index.rst +++ b/Documentation/driver-api/soundwire/index.rst @@ -10,7 +10,7 @@ SoundWire Documentation error_handling locking -.. only:: subproject +.. only:: subproject and html Indices ======= diff --git a/Documentation/thermal/cpu-cooling-api.rst b/Documentation/driver-api/thermal/cpu-cooling-api.rst similarity index 100% rename from Documentation/thermal/cpu-cooling-api.rst rename to Documentation/driver-api/thermal/cpu-cooling-api.rst diff --git a/Documentation/thermal/exynos_thermal.rst b/Documentation/driver-api/thermal/exynos_thermal.rst similarity index 100% rename from Documentation/thermal/exynos_thermal.rst rename to Documentation/driver-api/thermal/exynos_thermal.rst diff --git a/Documentation/thermal/exynos_thermal_emulation.rst b/Documentation/driver-api/thermal/exynos_thermal_emulation.rst similarity index 100% rename from Documentation/thermal/exynos_thermal_emulation.rst rename to Documentation/driver-api/thermal/exynos_thermal_emulation.rst diff --git a/Documentation/driver-api/thermal/index.rst b/Documentation/driver-api/thermal/index.rst new file mode 100644 index 000000000000..5ba61d19c6ae --- /dev/null +++ b/Documentation/driver-api/thermal/index.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======= +Thermal +======= + +.. toctree:: + :maxdepth: 1 + + cpu-cooling-api + sysfs-api + power_allocator + + exynos_thermal + exynos_thermal_emulation + intel_powerclamp + nouveau_thermal + x86_pkg_temperature_thermal diff --git a/Documentation/thermal/intel_powerclamp.rst b/Documentation/driver-api/thermal/intel_powerclamp.rst similarity index 100% rename from Documentation/thermal/intel_powerclamp.rst rename to Documentation/driver-api/thermal/intel_powerclamp.rst diff --git a/Documentation/thermal/nouveau_thermal.rst b/Documentation/driver-api/thermal/nouveau_thermal.rst similarity index 100% rename from Documentation/thermal/nouveau_thermal.rst rename to Documentation/driver-api/thermal/nouveau_thermal.rst diff --git a/Documentation/thermal/power_allocator.rst b/Documentation/driver-api/thermal/power_allocator.rst similarity index 100% rename from Documentation/thermal/power_allocator.rst rename to Documentation/driver-api/thermal/power_allocator.rst diff --git a/Documentation/driver-api/thermal/sysfs-api.rst b/Documentation/driver-api/thermal/sysfs-api.rst new file mode 100644 index 000000000000..fab2c9b36d08 --- /dev/null +++ b/Documentation/driver-api/thermal/sysfs-api.rst @@ -0,0 +1,798 @@ +=================================== +Generic Thermal Sysfs driver How To +=================================== + +Written by Sujith Thomas , Zhang Rui + +Updated: 2 January 2008 + +Copyright (c) 2008 Intel Corporation + + +0. Introduction +=============== + +The generic thermal sysfs provides a set of interfaces for thermal zone +devices (sensors) and thermal cooling devices (fan, processor...) to register +with the thermal management solution and to be a part of it. + +This how-to focuses on enabling new thermal zone and cooling devices to +participate in thermal management. +This solution is platform independent and any type of thermal zone devices +and cooling devices should be able to make use of the infrastructure. + +The main task of the thermal sysfs driver is to expose thermal zone attributes +as well as cooling device attributes to the user space. +An intelligent thermal management application can make decisions based on +inputs from thermal zone attributes (the current temperature and trip point +temperature) and throttle appropriate devices. + +- `[0-*]` denotes any positive number starting from 0 +- `[1-*]` denotes any positive number starting from 1 + +1. thermal sysfs driver interface functions +=========================================== + +1.1 thermal zone device interface +--------------------------------- + + :: + + struct thermal_zone_device + *thermal_zone_device_register(char *type, + int trips, int mask, void *devdata, + struct thermal_zone_device_ops *ops, + const struct thermal_zone_params *tzp, + int passive_delay, int polling_delay)) + + This interface function adds a new thermal zone device (sensor) to + /sys/class/thermal folder as `thermal_zone[0-*]`. It tries to bind all the + thermal cooling devices registered at the same time. + + type: + the thermal zone type. + trips: + the total number of trip points this thermal zone supports. + mask: + Bit string: If 'n'th bit is set, then trip point 'n' is writeable. + devdata: + device private data + ops: + thermal zone device call-backs. + + .bind: + bind the thermal zone device with a thermal cooling device. + .unbind: + unbind the thermal zone device with a thermal cooling device. + .get_temp: + get the current temperature of the thermal zone. + .set_trips: + set the trip points window. Whenever the current temperature + is updated, the trip points immediately below and above the + current temperature are found. + .get_mode: + get the current mode (enabled/disabled) of the thermal zone. + + - "enabled" means the kernel thermal management is + enabled. + - "disabled" will prevent kernel thermal driver action + upon trip points so that user applications can take + charge of thermal management. + .set_mode: + set the mode (enabled/disabled) of the thermal zone. + .get_trip_type: + get the type of certain trip point. + .get_trip_temp: + get the temperature above which the certain trip point + will be fired. + .set_emul_temp: + set the emulation temperature which helps in debugging + different threshold temperature points. + tzp: + thermal zone platform parameters. + passive_delay: + number of milliseconds to wait between polls when + performing passive cooling. + polling_delay: + number of milliseconds to wait between polls when checking + whether trip points have been crossed (0 for interrupt driven systems). + + :: + + void thermal_zone_device_unregister(struct thermal_zone_device *tz) + + This interface function removes the thermal zone device. + It deletes the corresponding entry from /sys/class/thermal folder and + unbinds all the thermal cooling devices it uses. + + :: + + struct thermal_zone_device + *thermal_zone_of_sensor_register(struct device *dev, int sensor_id, + void *data, + const struct thermal_zone_of_device_ops *ops) + + This interface adds a new sensor to a DT thermal zone. + This function will search the list of thermal zones described in + device tree and look for the zone that refer to the sensor device + pointed by dev->of_node as temperature providers. For the zone + pointing to the sensor node, the sensor will be added to the DT + thermal zone device. + + The parameters for this interface are: + + dev: + Device node of sensor containing valid node pointer in + dev->of_node. + sensor_id: + a sensor identifier, in case the sensor IP has more + than one sensors + data: + a private pointer (owned by the caller) that will be + passed back, when a temperature reading is needed. + ops: + `struct thermal_zone_of_device_ops *`. + + ============== ======================================= + get_temp a pointer to a function that reads the + sensor temperature. This is mandatory + callback provided by sensor driver. + set_trips a pointer to a function that sets a + temperature window. When this window is + left the driver must inform the thermal + core via thermal_zone_device_update. + get_trend a pointer to a function that reads the + sensor temperature trend. + set_emul_temp a pointer to a function that sets + sensor emulated temperature. + ============== ======================================= + + The thermal zone temperature is provided by the get_temp() function + pointer of thermal_zone_of_device_ops. When called, it will + have the private pointer @data back. + + It returns error pointer if fails otherwise valid thermal zone device + handle. Caller should check the return handle with IS_ERR() for finding + whether success or not. + + :: + + void thermal_zone_of_sensor_unregister(struct device *dev, + struct thermal_zone_device *tzd) + + This interface unregisters a sensor from a DT thermal zone which was + successfully added by interface thermal_zone_of_sensor_register(). + This function removes the sensor callbacks and private data from the + thermal zone device registered with thermal_zone_of_sensor_register() + interface. It will also silent the zone by remove the .get_temp() and + get_trend() thermal zone device callbacks. + + :: + + struct thermal_zone_device + *devm_thermal_zone_of_sensor_register(struct device *dev, + int sensor_id, + void *data, + const struct thermal_zone_of_device_ops *ops) + + This interface is resource managed version of + thermal_zone_of_sensor_register(). + + All details of thermal_zone_of_sensor_register() described in + section 1.1.3 is applicable here. + + The benefit of using this interface to register sensor is that it + is not require to explicitly call thermal_zone_of_sensor_unregister() + in error path or during driver unbinding as this is done by driver + resource manager. + + :: + + void devm_thermal_zone_of_sensor_unregister(struct device *dev, + struct thermal_zone_device *tzd) + + This interface is resource managed version of + thermal_zone_of_sensor_unregister(). + All details of thermal_zone_of_sensor_unregister() described in + section 1.1.4 is applicable here. + Normally this function will not need to be called and the resource + management code will ensure that the resource is freed. + + :: + + int thermal_zone_get_slope(struct thermal_zone_device *tz) + + This interface is used to read the slope attribute value + for the thermal zone device, which might be useful for platform + drivers for temperature calculations. + + :: + + int thermal_zone_get_offset(struct thermal_zone_device *tz) + + This interface is used to read the offset attribute value + for the thermal zone device, which might be useful for platform + drivers for temperature calculations. + +1.2 thermal cooling device interface +------------------------------------ + + + :: + + struct thermal_cooling_device + *thermal_cooling_device_register(char *name, + void *devdata, struct thermal_cooling_device_ops *) + + This interface function adds a new thermal cooling device (fan/processor/...) + to /sys/class/thermal/ folder as `cooling_device[0-*]`. It tries to bind itself + to all the thermal zone devices registered at the same time. + + name: + the cooling device name. + devdata: + device private data. + ops: + thermal cooling devices call-backs. + + .get_max_state: + get the Maximum throttle state of the cooling device. + .get_cur_state: + get the Currently requested throttle state of the + cooling device. + .set_cur_state: + set the Current throttle state of the cooling device. + + :: + + void thermal_cooling_device_unregister(struct thermal_cooling_device *cdev) + + This interface function removes the thermal cooling device. + It deletes the corresponding entry from /sys/class/thermal folder and + unbinds itself from all the thermal zone devices using it. + +1.3 interface for binding a thermal zone device with a thermal cooling device +----------------------------------------------------------------------------- + + :: + + int thermal_zone_bind_cooling_device(struct thermal_zone_device *tz, + int trip, struct thermal_cooling_device *cdev, + unsigned long upper, unsigned long lower, unsigned int weight); + + This interface function binds a thermal cooling device to a particular trip + point of a thermal zone device. + + This function is usually called in the thermal zone device .bind callback. + + tz: + the thermal zone device + cdev: + thermal cooling device + trip: + indicates which trip point in this thermal zone the cooling device + is associated with. + upper: + the Maximum cooling state for this trip point. + THERMAL_NO_LIMIT means no upper limit, + and the cooling device can be in max_state. + lower: + the Minimum cooling state can be used for this trip point. + THERMAL_NO_LIMIT means no lower limit, + and the cooling device can be in cooling state 0. + weight: + the influence of this cooling device in this thermal + zone. See 1.4.1 below for more information. + + :: + + int thermal_zone_unbind_cooling_device(struct thermal_zone_device *tz, + int trip, struct thermal_cooling_device *cdev); + + This interface function unbinds a thermal cooling device from a particular + trip point of a thermal zone device. This function is usually called in + the thermal zone device .unbind callback. + + tz: + the thermal zone device + cdev: + thermal cooling device + trip: + indicates which trip point in this thermal zone the cooling device + is associated with. + +1.4 Thermal Zone Parameters +--------------------------- + + :: + + struct thermal_bind_params + + This structure defines the following parameters that are used to bind + a zone with a cooling device for a particular trip point. + + .cdev: + The cooling device pointer + .weight: + The 'influence' of a particular cooling device on this + zone. This is relative to the rest of the cooling + devices. For example, if all cooling devices have a + weight of 1, then they all contribute the same. You can + use percentages if you want, but it's not mandatory. A + weight of 0 means that this cooling device doesn't + contribute to the cooling of this zone unless all cooling + devices have a weight of 0. If all weights are 0, then + they all contribute the same. + .trip_mask: + This is a bit mask that gives the binding relation between + this thermal zone and cdev, for a particular trip point. + If nth bit is set, then the cdev and thermal zone are bound + for trip point n. + .binding_limits: + This is an array of cooling state limits. Must have + exactly 2 * thermal_zone.number_of_trip_points. It is an + array consisting of tuples of + state limits. Each trip will be associated with one state + limit tuple when binding. A NULL pointer means + on all trips. + These limits are used when binding a cdev to a trip point. + .match: + This call back returns success(0) if the 'tz and cdev' need to + be bound, as per platform data. + + :: + + struct thermal_zone_params + + This structure defines the platform level parameters for a thermal zone. + This data, for each thermal zone should come from the platform layer. + This is an optional feature where some platforms can choose not to + provide this data. + + .governor_name: + Name of the thermal governor used for this zone + .no_hwmon: + a boolean to indicate if the thermal to hwmon sysfs interface + is required. when no_hwmon == false, a hwmon sysfs interface + will be created. when no_hwmon == true, nothing will be done. + In case the thermal_zone_params is NULL, the hwmon interface + will be created (for backward compatibility). + .num_tbps: + Number of thermal_bind_params entries for this zone + .tbp: + thermal_bind_params entries + +2. sysfs attributes structure +============================= + +== ================ +RO read only value +WO write only value +RW read/write value +== ================ + +Thermal sysfs attributes will be represented under /sys/class/thermal. +Hwmon sysfs I/F extension is also available under /sys/class/hwmon +if hwmon is compiled in or built as a module. + +Thermal zone device sys I/F, created once it's registered:: + + /sys/class/thermal/thermal_zone[0-*]: + |---type: Type of the thermal zone + |---temp: Current temperature + |---mode: Working mode of the thermal zone + |---policy: Thermal governor used for this zone + |---available_policies: Available thermal governors for this zone + |---trip_point_[0-*]_temp: Trip point temperature + |---trip_point_[0-*]_type: Trip point type + |---trip_point_[0-*]_hyst: Hysteresis value for this trip point + |---emul_temp: Emulated temperature set node + |---sustainable_power: Sustainable dissipatable power + |---k_po: Proportional term during temperature overshoot + |---k_pu: Proportional term during temperature undershoot + |---k_i: PID's integral term in the power allocator gov + |---k_d: PID's derivative term in the power allocator + |---integral_cutoff: Offset above which errors are accumulated + |---slope: Slope constant applied as linear extrapolation + |---offset: Offset constant applied as linear extrapolation + +Thermal cooling device sys I/F, created once it's registered:: + + /sys/class/thermal/cooling_device[0-*]: + |---type: Type of the cooling device(processor/fan/...) + |---max_state: Maximum cooling state of the cooling device + |---cur_state: Current cooling state of the cooling device + |---stats: Directory containing cooling device's statistics + |---stats/reset: Writing any value resets the statistics + |---stats/time_in_state_ms: Time (msec) spent in various cooling states + |---stats/total_trans: Total number of times cooling state is changed + |---stats/trans_table: Cooing state transition table + + +Then next two dynamic attributes are created/removed in pairs. They represent +the relationship between a thermal zone and its associated cooling device. +They are created/removed for each successful execution of +thermal_zone_bind_cooling_device/thermal_zone_unbind_cooling_device. + +:: + + /sys/class/thermal/thermal_zone[0-*]: + |---cdev[0-*]: [0-*]th cooling device in current thermal zone + |---cdev[0-*]_trip_point: Trip point that cdev[0-*] is associated with + |---cdev[0-*]_weight: Influence of the cooling device in + this thermal zone + +Besides the thermal zone device sysfs I/F and cooling device sysfs I/F, +the generic thermal driver also creates a hwmon sysfs I/F for each _type_ +of thermal zone device. E.g. the generic thermal driver registers one hwmon +class device and build the associated hwmon sysfs I/F for all the registered +ACPI thermal zones. + +:: + + /sys/class/hwmon/hwmon[0-*]: + |---name: The type of the thermal zone devices + |---temp[1-*]_input: The current temperature of thermal zone [1-*] + |---temp[1-*]_critical: The critical trip point of thermal zone [1-*] + +Please read Documentation/hwmon/sysfs-interface.rst for additional information. + +Thermal zone attributes +----------------------- + +type + Strings which represent the thermal zone type. + This is given by thermal zone driver as part of registration. + E.g: "acpitz" indicates it's an ACPI thermal device. + In order to keep it consistent with hwmon sys attribute; this should + be a short, lowercase string, not containing spaces nor dashes. + RO, Required + +temp + Current temperature as reported by thermal zone (sensor). + Unit: millidegree Celsius + RO, Required + +mode + One of the predefined values in [enabled, disabled]. + This file gives information about the algorithm that is currently + managing the thermal zone. It can be either default kernel based + algorithm or user space application. + + enabled + enable Kernel Thermal management. + disabled + Preventing kernel thermal zone driver actions upon + trip points so that user application can take full + charge of the thermal management. + + RW, Optional + +policy + One of the various thermal governors used for a particular zone. + + RW, Required + +available_policies + Available thermal governors which can be used for a particular zone. + + RO, Required + +`trip_point_[0-*]_temp` + The temperature above which trip point will be fired. + + Unit: millidegree Celsius + + RO, Optional + +`trip_point_[0-*]_type` + Strings which indicate the type of the trip point. + + E.g. it can be one of critical, hot, passive, `active[0-*]` for ACPI + thermal zone. + + RO, Optional + +`trip_point_[0-*]_hyst` + The hysteresis value for a trip point, represented as an integer + Unit: Celsius + RW, Optional + +`cdev[0-*]` + Sysfs link to the thermal cooling device node where the sys I/F + for cooling device throttling control represents. + + RO, Optional + +`cdev[0-*]_trip_point` + The trip point in this thermal zone which `cdev[0-*]` is associated + with; -1 means the cooling device is not associated with any trip + point. + + RO, Optional + +`cdev[0-*]_weight` + The influence of `cdev[0-*]` in this thermal zone. This value + is relative to the rest of cooling devices in the thermal + zone. For example, if a cooling device has a weight double + than that of other, it's twice as effective in cooling the + thermal zone. + + RW, Optional + +passive + Attribute is only present for zones in which the passive cooling + policy is not supported by native thermal driver. Default is zero + and can be set to a temperature (in millidegrees) to enable a + passive trip point for the zone. Activation is done by polling with + an interval of 1 second. + + Unit: millidegrees Celsius + + Valid values: 0 (disabled) or greater than 1000 + + RW, Optional + +emul_temp + Interface to set the emulated temperature method in thermal zone + (sensor). After setting this temperature, the thermal zone may pass + this temperature to platform emulation function if registered or + cache it locally. This is useful in debugging different temperature + threshold and its associated cooling action. This is write only node + and writing 0 on this node should disable emulation. + Unit: millidegree Celsius + + WO, Optional + + WARNING: + Be careful while enabling this option on production systems, + because userland can easily disable the thermal policy by simply + flooding this sysfs node with low temperature values. + +sustainable_power + An estimate of the sustained power that can be dissipated by + the thermal zone. Used by the power allocator governor. For + more information see Documentation/driver-api/thermal/power_allocator.rst + + Unit: milliwatts + + RW, Optional + +k_po + The proportional term of the power allocator governor's PID + controller during temperature overshoot. Temperature overshoot + is when the current temperature is above the "desired + temperature" trip point. For more information see + Documentation/driver-api/thermal/power_allocator.rst + + RW, Optional + +k_pu + The proportional term of the power allocator governor's PID + controller during temperature undershoot. Temperature undershoot + is when the current temperature is below the "desired + temperature" trip point. For more information see + Documentation/driver-api/thermal/power_allocator.rst + + RW, Optional + +k_i + The integral term of the power allocator governor's PID + controller. This term allows the PID controller to compensate + for long term drift. For more information see + Documentation/driver-api/thermal/power_allocator.rst + + RW, Optional + +k_d + The derivative term of the power allocator governor's PID + controller. For more information see + Documentation/driver-api/thermal/power_allocator.rst + + RW, Optional + +integral_cutoff + Temperature offset from the desired temperature trip point + above which the integral term of the power allocator + governor's PID controller starts accumulating errors. For + example, if integral_cutoff is 0, then the integral term only + accumulates error when temperature is above the desired + temperature trip point. For more information see + Documentation/driver-api/thermal/power_allocator.rst + + Unit: millidegree Celsius + + RW, Optional + +slope + The slope constant used in a linear extrapolation model + to determine a hotspot temperature based off the sensor's + raw readings. It is up to the device driver to determine + the usage of these values. + + RW, Optional + +offset + The offset constant used in a linear extrapolation model + to determine a hotspot temperature based off the sensor's + raw readings. It is up to the device driver to determine + the usage of these values. + + RW, Optional + +Cooling device attributes +------------------------- + +type + String which represents the type of device, e.g: + + - for generic ACPI: should be "Fan", "Processor" or "LCD" + - for memory controller device on intel_menlow platform: + should be "Memory controller". + + RO, Required + +max_state + The maximum permissible cooling state of this cooling device. + + RO, Required + +cur_state + The current cooling state of this cooling device. + The value can any integer numbers between 0 and max_state: + + - cur_state == 0 means no cooling + - cur_state == max_state means the maximum cooling. + + RW, Required + +stats/reset + Writing any value resets the cooling device's statistics. + WO, Required + +stats/time_in_state_ms: + The amount of time spent by the cooling device in various cooling + states. The output will have "

    : - main(int argc,char *argv[]) - { - 800005bc: eb bf f0 58 00 24 stmg %r11,%r15,88(%r15) - 800005c2: b9 04 00 1f lgr %r1,%r15 - 800005c6: a7 fb ff 60 aghi %r15,-160 - 800005ca: e3 10 f0 00 00 24 stg %r1,0(%r15) - return(test(5)); - 800005d0: a7 29 00 05 lghi %r2,5 - # brasl allows jumps > 64k & is overkill here bras would do fune - 800005d4: c0 e5 ff ff ff ee brasl %r14,800005b0 - 800005da: e3 40 f1 10 00 04 lg %r4,272(%r15) - 800005e0: eb bf f0 f8 00 04 lmg %r11,%r15,248(%r15) - 800005e6: 07 f4 br %r4 - } - - - -Compiling programs for debugging on Linux for s/390 & z/Architecture -==================================================================== --gdwarf-2 now works it should be considered the default debugging -format for s/390 & z/Architecture as it is more reliable for debugging -shared libraries, normal -g debugging works much better now -Thanks to the IBM java compiler developers bug reports. - -This is typically done adding/appending the flags -g or -gdwarf-2 to the -CFLAGS & LDFLAGS variables Makefile of the program concerned. - -If using gdb & you would like accurate displays of registers & -stack traces compile without optimisation i.e make sure -that there is no -O2 or similar on the CFLAGS line of the Makefile & -the emitted gcc commands, obviously this will produce worse code -( not advisable for shipment ) but it is an aid to the debugging process. - -This aids debugging because the compiler will copy parameters passed in -in registers onto the stack so backtracing & looking at passed in -parameters will work, however some larger programs which use inline functions -will not compile without optimisation. - -Debugging with optimisation has since much improved after fixing -some bugs, please make sure you are using gdb-5.0 or later developed -after Nov'2000. - - - -Debugging under VM -================== - -Notes ------ -Addresses & values in the VM debugger are always hex never decimal -Address ranges are of the format - or -. -For example, the address range 0x2000 to 0x3000 can be described as 2000-3000 -or 2000.1000 - -The VM Debugger is case insensitive. - -VM's strengths are usually other debuggers weaknesses you can get at any -resource no matter how sensitive e.g. memory management resources, change -address translation in the PSW. For kernel hacking you will reap dividends if -you get good at it. - -The VM Debugger displays operators but not operands, and also the debugger -displays useful information on the same line as the author of the code probably -felt that it was a good idea not to go over the 80 columns on the screen. -This isn't as unintuitive as it may seem as the s/390 instructions are easy to -decode mentally and you can make a good guess at a lot of them as all the -operands are nibble (half byte aligned). -So if you have an objdump listing by hand, it is quite easy to follow, and if -you don't have an objdump listing keep a copy of the s/390 Reference Summary -or alternatively the s/390 principles of operation next to you. -e.g. even I can guess that -0001AFF8' LR 180F CC 0 -is a ( load register ) lr r0,r15 - -Also it is very easy to tell the length of a 390 instruction from the 2 most -significant bits in the instruction (not that this info is really useful except -if you are trying to make sense of a hexdump of code). -Here is a table - -======================= ================== -Bits Instruction Length -======================= ================== -00 2 Bytes -01 4 Bytes -10 4 Bytes -11 6 Bytes -======================= ================== - -The debugger also displays other useful info on the same line such as the -addresses being operated on destination addresses of branches & condition codes. -e.g.:: - - 00019736' AHI A7DAFF0E CC 1 - 000198BA' BRC A7840004 -> 000198C2' CC 0 - 000198CE' STM 900EF068 >> 0FA95E78 CC 2 - - - -Useful VM debugger commands ---------------------------- - -I suppose I'd better mention this before I start -to list the current active traces do:: - - Q TR - -there can be a maximum of 255 of these per set -( more about trace sets later ). - -To stop traces issue a:: - - TR END. - -To delete a particular breakpoint issue:: - - TR DEL - -The PA1 key drops to CP mode so you can issue debugger commands, -Doing alt c (on my 3270 console at least ) clears the screen. - -hitting b comes back to the running operating system -from cp mode ( in our case linux ). - -It is typically useful to add shortcuts to your profile.exec file -if you have one ( this is roughly equivalent to autoexec.bat in DOS ). -file here are a few from mine:: - - /* this gives me command history on issuing f12 */ - set pf12 retrieve - /* this continues */ - set pf8 imm b - /* goes to trace set a */ - set pf1 imm tr goto a - /* goes to trace set b */ - set pf2 imm tr goto b - /* goes to trace set c */ - set pf3 imm tr goto c - - - -Instruction Tracing -------------------- -Setting a simple breakpoint:: - - TR I PSWA
    - -To debug a particular function try:: - - TR I R - TR I on its own will single step. - TR I DATA will trace for particular mnemonics - -e.g.:: - - TR I DATA 4D R 0197BC.4000 - -will trace for BAS'es ( opcode 4D ) in the range 0197BC.4000 - -if you were inclined you could add traces for all branch instructions & -suffix them with the run prefix so you would have a backtrace on screen -when a program crashes:: - - TR BR will trace branches into or out of an address. - -e.g.:: - - TR BR INTO 0 - -is often quite useful if a program is getting awkward & deciding -to branch to 0 & crashing as this will stop at the address before in jumps to 0. - -:: - - TR I R
    RUN cmd d g - -single steps a range of addresses but stays running & -displays the gprs on each step. - - - -Displaying & modifying Registers --------------------------------- -D G - will display all the gprs - -Adding a extra G to all the commands is necessary to access the full 64 bit -content in VM on z/Architecture. Obviously this isn't required for access -registers as these are still 32 bit. - -e.g. - -DGG - instead of DG - -D X - will display all the control registers -D AR - will display all the access registers -D AR4-7 - will display access registers 4 to 7 -CPU ALL D G - will display the GRPS of all CPUS in the configuration -D PSW - will display the current PSW -st PSW 2000 - will put the value 2000 into the PSW & cause crash your machine. -D PREFIX - displays the prefix offset - - -Displaying Memory ------------------ -To display memory mapped using the current PSW's mapping try:: - - D - -To make VM display a message each time it hits a particular address and -continue try: - -D I - will disassemble/display a range of instructions. - -ST addr 32 bit word - will store a 32 bit aligned address -D T - will display the EBCDIC in an address (if you are that way inclined) -D R - will display real addresses ( without DAT ) but with prefixing. - -There are other complex options to display if you need to get at say home space -but are in primary space the easiest thing to do is to temporarily -modify the PSW to the other addressing mode, display the stuff & then -restore it. - - - -Hints ------ -If you want to issue a debugger command without halting your virtual machine -with the PA1 key try prefixing the command with #CP e.g.:: - - #cp tr i pswa 2000 - -also suffixing most debugger commands with RUN will cause them not -to stop just display the mnemonic at the current instruction on the console. - -If you have several breakpoints you want to put into your program & -you get fed up of cross referencing with System.map -you can do the following trick for several symbols. - -:: - - grep do_signal System.map - -which emits the following among other things:: - - 0001f4e0 T do_signal - -now you can do:: - - TR I PSWA 0001f4e0 cmd msg * do_signal - -This sends a message to your own console each time do_signal is entered. -( As an aside I wrote a perl script once which automatically generated a REXX -script with breakpoints on every kernel procedure, this isn't a good idea -because there are thousands of these routines & VM can only set 255 breakpoints -at a time so you nearly had to spend as long pruning the file down as you would -entering the msgs by hand), however, the trick might be useful for a single -object file. In the 3270 terminal emulator x3270 there is a very useful option -in the file menu called "Save Screen In File" - this is very good for keeping a -copy of traces. - -From CMS help will give you online help on a particular command. -e.g.:: - - HELP DISPLAY - -Also CP has a file called profile.exec which automatically gets called -on startup of CMS ( like autoexec.bat ), keeping on a DOS analogy session -CP has a feature similar to doskey, it may be useful for you to -use profile.exec to define some keystrokes. - -SET PF9 IMM B - This does a single step in VM on pressing F8. - -SET PF10 ^ - This sets up the ^ key. - which can be used for ^c (ctrl-c),^z (ctrl-z) which can't be typed - directly into some 3270 consoles. - -SET PF11 ^- - This types the starting keystrokes for a sysrq see SysRq below. -SET PF12 RETRIEVE - This retrieves command history on pressing F12. - - -Sometimes in VM the display is set up to scroll automatically this -can be very annoying if there are messages you wish to look at -to stop this do - -TERM MORE 255 255 - This will nearly stop automatic screen updates, however it will - cause a denial of service if lots of messages go to the 3270 console, - so it would be foolish to use this as the default on a production machine. - - -Tracing particular processes ----------------------------- -The kernel's text segment is intentionally at an address in memory that it will -very seldom collide with text segments of user programs ( thanks Martin ), -this simplifies debugging the kernel. -However it is quite common for user processes to have addresses which collide -this can make debugging a particular process under VM painful under normal -circumstances as the process may change when doing a:: - - TR I R
    . - -Thankfully after reading VM's online help I figured out how to debug -I particular process. - -Your first problem is to find the STD ( segment table designation ) -of the program you wish to debug. -There are several ways you can do this here are a few - -Run:: - - objdump --syms | grep main - -To get the address of main in the program. Then:: - - tr i pswa
    - -Start the program, if VM drops to CP on what looks like the entry -point of the main function this is most likely the process you wish to debug. -Now do a D X13 or D XG13 on z/Architecture. - -On 31 bit the STD is bits 1-19 ( the STO segment table origin ) -& 25-31 ( the STL segment table length ) of CR13. - -now type:: - - TR I R STD 0.7fffffff - -e.g.:: - - TR I R STD 8F32E1FF 0.7fffffff - -Another very useful variation is:: - - TR STORE INTO STD
    - -for finding out when a particular variable changes. - -An alternative way of finding the STD of a currently running process -is to do the following, ( this method is more complex but -could be quite convenient if you aren't updating the kernel much & -so your kernel structures will stay constant for a reasonable period of -time ). - -:: - - grep task /proc//status - -from this you should see something like:: - - task: 0f160000 ksp: 0f161de8 pt_regs: 0f161f68 - -This now gives you a pointer to the task structure. - -Now make:: - - CC:="s390-gcc -g" kernel/sched.s - -To get the task_struct stabinfo. - -( task_struct is defined in include/linux/sched.h ). - -Now we want to look at -task->active_mm->pgd - -on my machine the active_mm in the task structure stab is -active_mm:(4,12),672,32 - -its offset is 672/8=84=0x54 - -the pgd member in the mm_struct stab is -pgd:(4,6)=*(29,5),96,32 -so its offset is 96/8=12=0xc - -so we'll:: - - hexdump -s 0xf160054 /dev/mem | more - -i.e. task_struct+active_mm offset -to look at the active_mm member:: - - f160054 0fee cc60 0019 e334 0000 0000 0000 0011 - -:: - - hexdump -s 0x0feecc6c /dev/mem | more - -i.e. active_mm+pgd offset:: - - feecc6c 0f2c 0000 0000 0001 0000 0001 0000 0010 - -we get something like -now do:: - - TR I R STD 0.7fffffff - -i.e. the 0x7f is added because the pgd only -gives the page table origin & we need to set the low bits -to the maximum possible segment table length. - -:: - - TR I R STD 0f2c007f 0.7fffffff - -on z/Architecture you'll probably need to do:: - - TR I R STD 0.ffffffffffffffff - -to set the TableType to 0x1 & the Table length to 3. - - - -Tracing Program Exceptions --------------------------- -If you get a crash which says something like -illegal operation or specification exception followed by a register dump -You can restart linux & trace these using the tr prog trace -option. - - -The most common ones you will normally be tracing for is: - -- 1=operation exception -- 2=privileged operation exception -- 4=protection exception -- 5=addressing exception -- 6=specification exception -- 10=segment translation exception -- 11=page translation exception - -The full list of these is on page 22 of the current s/390 Reference Summary. -e.g. - -tr prog 10 will trace segment translation exceptions. - -tr prog on its own will trace all program interruption codes. - -Trace Sets ----------- -On starting VM you are initially in the INITIAL trace set. -You can do a Q TR to verify this. -If you have a complex tracing situation where you wish to wait for instance -till a driver is open before you start tracing IO, but know in your -heart that you are going to have to make several runs through the code till you -have a clue whats going on. - -What you can do is:: - - TR I PSWA - -hit b to continue till breakpoint - -reach the breakpoint - -now do your:: - - TR GOTO B - TR IO 7c08-7c09 inst int run - -or whatever the IO channels you wish to trace are & hit b - -To got back to the initial trace set do:: - - TR GOTO INITIAL - -& the TR I PSWA will be the only active breakpoint again. - - -Tracing linux syscalls under VM -------------------------------- -Syscalls are implemented on Linux for S390 by the Supervisor call instruction -(SVC). There 256 possibilities of these as the instruction is made up of a 0xA -opcode and the second byte being the syscall number. They are traced using the -simple command:: - - TR SVC - -the syscalls are defined in linux/arch/s390/include/asm/unistd.h -e.g. to trace all file opens just do:: - - TR SVC 5 ( as this is the syscall number of open ) - - -SMP Specific commands ---------------------- -To find out how many cpus you have -Q CPUS displays all the CPU's available to your virtual machine -To find the cpu that the current cpu VM debugger commands are being directed at -do Q CPU to change the current cpu VM debugger commands are being directed at -do:: - - CPU - -On a SMP guest issue a command to all CPUs try prefixing the command with cpu -all. To issue a command to a particular cpu try cpu e.g.:: - - CPU 01 TR I R 2000.3000 - -If you are running on a guest with several cpus & you have a IO related problem -& cannot follow the flow of code but you know it isn't smp related. - -from the bash prompt issue:: - - shutdown -h now or halt. - -do a:: - - Q CPUS - -to find out how many cpus you have detach each one of them from cp except -cpu 0 by issuing a:: - - DETACH CPU 01-(number of cpus in configuration) - -& boot linux again. - -TR SIGP - will trace inter processor signal processor instructions. - -DEFINE CPU 01-(number in configuration) - will get your guests cpus back. - - -Help for displaying ascii textstrings -------------------------------------- -On the very latest VM Nucleus'es VM can now display ascii -( thanks Neale for the hint ) by doing:: - - D TX. - -e.g.:: - - D TX0.100 - -Alternatively -============= -Under older VM debuggers (I love EBDIC too) you can use following little -program which converts a command line of hex digits to ascii text. It can be -compiled under linux and you can copy the hex digits from your x3270 terminal -to your xterm if you are debugging from a linuxbox. - -This is quite useful when looking at a parameter passed in as a text string -under VM ( unless you are good at decoding ASCII in your head ). - -e.g. consider tracing an open syscall:: - - TR SVC 5 - -We have stopped at a breakpoint:: - - 000151B0' SVC 0A05 -> 0001909A' CC 0 - -D 20.8 to check the SVC old psw in the prefix area and see was it from userspace -(for the layout of the prefix area consult the "Fixed Storage Locations" -chapter of the s/390 Reference Summary if you have it available). - -:: - - V00000020 070C2000 800151B2 - -The problem state bit wasn't set & it's also too early in the boot sequence -for it to be a userspace SVC if it was we would have to temporarily switch the -psw to user space addressing so we could get at the first parameter of the open -in gpr2. - -Next do a:: - - D G2 - GPR 2 = 00014CB4 - -Now display what gpr2 is pointing to:: - - D 00014CB4.20 - V00014CB4 2F646576 2F636F6E 736F6C65 00001BF5 - V00014CC4 FC00014C B4001001 E0001000 B8070707 - -Now copy the text till the first 00 hex ( which is the end of the string -to an xterm & do hex2ascii on it:: - - hex2ascii 2F646576 2F636F6E 736F6C65 00 - -outputs:: - - Decoded Hex:=/ d e v / c o n s o l e 0x00 - -We were opening the console device, - -You can compile the code below yourself for practice :-), - -:: - - /* - * hex2ascii.c - * a useful little tool for converting a hexadecimal command line to ascii - * - * Author(s): Denis Joseph Barrow (djbarrow@de.ibm.com,barrow_dj@yahoo.com) - * (C) 2000 IBM Deutschland Entwicklung GmbH, IBM Corporation. - */ - #include - - int main(int argc,char *argv[]) - { - int cnt1,cnt2,len,toggle=0; - int startcnt=1; - unsigned char c,hex; - - if(argc>1&&(strcmp(argv[1],"-a")==0)) - startcnt=2; - printf("Decoded Hex:="); - for(cnt1=startcnt;cnt1='0'&&c<='9') - c=c-'0'; - if(c>='A'&&c<='F') - c=c-'A'+10; - if(c>='a'&&c<='f') - c=c-'a'+10; - switch(toggle) - { - case 0: - hex=c<<4; - toggle=1; - break; - case 1: - hex+=c; - if(hex<32||hex>127) - { - if(startcnt==1) - printf("0x%02X ",(int)hex); - else - printf("."); - } - else - { - printf("%c",hex); - if(startcnt==1) - printf(" "); - } - toggle=0; - break; - } - } - } - printf("\n"); - } - - - - -Stack tracing under VM ----------------------- -A basic backtrace ------------------ - -Here are the tricks I use 9 out of 10 times it works pretty well, - -When your backchain reaches a dead end --------------------------------------- -This can happen when an exception happens in the kernel and the kernel is -entered twice. If you reach the NULL pointer at the end of the back chain you -should be able to sniff further back if you follow the following tricks. -1) A kernel address should be easy to recognise since it is in -primary space & the problem state bit isn't set & also -The Hi bit of the address is set. -2) Another backchain should also be easy to recognise since it is an -address pointing to another address approximately 100 bytes or 0x70 hex -behind the current stackpointer. - - -Here is some practice. - -boot the kernel & hit PA1 at some random time - -d g to display the gprs, this should display something like:: - - GPR 0 = 00000001 00156018 0014359C 00000000 - GPR 4 = 00000001 001B8888 000003E0 00000000 - GPR 8 = 00100080 00100084 00000000 000FE000 - GPR 12 = 00010400 8001B2DC 8001B36A 000FFED8 - -Note that GPR14 is a return address but as we are real men we are going to -trace the stack. -display 0x40 bytes after the stack pointer:: - - V000FFED8 000FFF38 8001B838 80014C8E 000FFF38 - V000FFEE8 00000000 00000000 000003E0 00000000 - V000FFEF8 00100080 00100084 00000000 000FE000 - V000FFF08 00010400 8001B2DC 8001B36A 000FFED8 - - -Ah now look at whats in sp+56 (sp+0x38) this is 8001B36A our saved r14 if -you look above at our stackframe & also agrees with GPR14. - -now backchain:: - - d 000FFF38.40 - -we now are taking the contents of SP to get our first backchain:: - - V000FFF38 000FFFA0 00000000 00014995 00147094 - V000FFF48 00147090 001470A0 000003E0 00000000 - V000FFF58 00100080 00100084 00000000 001BF1D0 - V000FFF68 00010400 800149BA 80014CA6 000FFF38 - -This displays a 2nd return address of 80014CA6 - -now do:: - - d 000FFFA0.40 - -for our 3rd backchain:: - - V000FFFA0 04B52002 0001107F 00000000 00000000 - V000FFFB0 00000000 00000000 FF000000 0001107F - V000FFFC0 00000000 00000000 00000000 00000000 - V000FFFD0 00010400 80010802 8001085A 000FFFA0 - - -our 3rd return address is 8001085A - -as the 04B52002 looks suspiciously like rubbish it is fair to assume that the -kernel entry routines for the sake of optimisation don't set up a backchain. - -now look at System.map to see if the addresses make any sense:: - - grep -i 0001b3 System.map - -outputs among other things:: - - 0001b304 T cpu_idle - -so 8001B36A -is cpu_idle+0x66 ( quiet the cpu is asleep, don't wake it ) - -:: - - grep -i 00014 System.map - -produces among other things:: - - 00014a78 T start_kernel - -so 0014CA6 is start_kernel+some hex number I can't add in my head. - -:: - - grep -i 00108 System.map - -this produces:: - - 00010800 T _stext - -so 8001085A is _stext+0x5a - -Congrats you've done your first backchain. - - - -s/390 & z/Architecture IO Overview -================================== - -I am not going to give a course in 390 IO architecture as this would take me -quite a while and I'm no expert. Instead I'll give a 390 IO architecture -summary for Dummies. If you have the s/390 principles of operation available -read this instead. If nothing else you may find a few useful keywords in here -and be able to use them on a web search engine to find more useful information. - -Unlike other bus architectures modern 390 systems do their IO using mostly -fibre optics and devices such as tapes and disks can be shared between several -mainframes. Also S390 can support up to 65536 devices while a high end PC based -system might be choking with around 64. - -Here is some of the common IO terminology: - -Subchannel: - This is the logical number most IO commands use to talk to an IO device. There - can be up to 0x10000 (65536) of these in a configuration, typically there are a - few hundred. Under VM for simplicity they are allocated contiguously, however - on the native hardware they are not. They typically stay consistent between - boots provided no new hardware is inserted or removed. - - Under Linux for s390 we use these as IRQ's and also when issuing an IO command - (CLEAR SUBCHANNEL, HALT SUBCHANNEL, MODIFY SUBCHANNEL, RESUME SUBCHANNEL, - START SUBCHANNEL, STORE SUBCHANNEL and TEST SUBCHANNEL). We use this as the ID - of the device we wish to talk to. The most important of these instructions are - START SUBCHANNEL (to start IO), TEST SUBCHANNEL (to check whether the IO - completed successfully) and HALT SUBCHANNEL (to kill IO). A subchannel can have - up to 8 channel paths to a device, this offers redundancy if one is not - available. - -Device Number: - This number remains static and is closely tied to the hardware. There are 65536 - of these, made up of a CHPID (Channel Path ID, the most significant 8 bits) and - another lsb 8 bits. These remain static even if more devices are inserted or - removed from the hardware. There is a 1 to 1 mapping between subchannels and - device numbers, provided devices aren't inserted or removed. - -Channel Control Words: - CCWs are linked lists of instructions initially pointed to by an operation - request block (ORB), which is initially given to Start Subchannel (SSCH) - command along with the subchannel number for the IO subsystem to process - while the CPU continues executing normal code. - CCWs come in two flavours, Format 0 (24 bit for backward compatibility) and - Format 1 (31 bit). These are typically used to issue read and write (and many - other) instructions. They consist of a length field and an absolute address - field. - - Each IO typically gets 1 or 2 interrupts, one for channel end (primary status) - when the channel is idle, and the second for device end (secondary status). - Sometimes you get both concurrently. You check how the IO went on by issuing a - TEST SUBCHANNEL at each interrupt, from which you receive an Interruption - response block (IRB). If you get channel and device end status in the IRB - without channel checks etc. your IO probably went okay. If you didn't you - probably need to examine the IRB, extended status word etc. - If an error occurs, more sophisticated control units have a facility known as - concurrent sense. This means that if an error occurs Extended sense information - will be presented in the Extended status word in the IRB. If not you have to - issue a subsequent SENSE CCW command after the test subchannel. - - -TPI (Test pending interrupt) can also be used for polled IO, but in -multitasking multiprocessor systems it isn't recommended except for -checking special cases (i.e. non looping checks for pending IO etc.). - -Store Subchannel and Modify Subchannel can be used to examine and modify -operating characteristics of a subchannel (e.g. channel paths). - -Other IO related Terms: - -Sysplex: - S390's Clustering Technology -QDIO: - S390's new high speed IO architecture to support devices such as gigabit - ethernet, this architecture is also designed to be forward compatible with - upcoming 64 bit machines. - - -General Concepts ----------------- - -Input Output Processors (IOP's) are responsible for communicating between -the mainframe CPU's & the channel & relieve the mainframe CPU's from the -burden of communicating with IO devices directly, this allows the CPU's to -concentrate on data processing. - -IOP's can use one or more links ( known as channel paths ) to talk to each -IO device. It first checks for path availability & chooses an available one, -then starts ( & sometimes terminates IO ). -There are two types of channel path: ESCON & the Parallel IO interface. - -IO devices are attached to control units, control units provide the -logic to interface the channel paths & channel path IO protocols to -the IO devices, they can be integrated with the devices or housed separately -& often talk to several similar devices ( typical examples would be raid -controllers or a control unit which connects to 1000 3270 terminals ):: - - - +---------------------------------------------------------------+ - | +-----+ +-----+ +-----+ +-----+ +----------+ +----------+ | - | | CPU | | CPU | | CPU | | CPU | | Main | | Expanded | | - | | | | | | | | | | Memory | | Storage | | - | +-----+ +-----+ +-----+ +-----+ +----------+ +----------+ | - |---------------------------------------------------------------+ - | IOP | IOP | IOP | - |--------------------------------------------------------------- - | C | C | C | C | C | C | C | C | C | C | C | C | C | C | C | C | - ---------------------------------------------------------------- - || || - || Bus & Tag Channel Path || ESCON - || ====================== || Channel - || || || || Path - +----------+ +----------+ +----------+ - | | | | | | - | CU | | CU | | CU | - | | | | | | - +----------+ +----------+ +----------+ - | | | | | - +----------+ +----------+ +----------+ +----------+ +----------+ - |I/O Device| |I/O Device| |I/O Device| |I/O Device| |I/O Device| - +----------+ +----------+ +----------+ +----------+ +----------+ - CPU = Central Processing Unit - C = Channel - IOP = IP Processor - CU = Control Unit - -The 390 IO systems come in 2 flavours the current 390 machines support both - -The Older 360 & 370 Interface,sometimes called the Parallel I/O interface, -sometimes called Bus-and Tag & sometimes Original Equipment Manufacturers -Interface (OEMI). - -This byte wide Parallel channel path/bus has parity & data on the "Bus" cable -and control lines on the "Tag" cable. These can operate in byte multiplex mode -for sharing between several slow devices or burst mode and monopolize the -channel for the whole burst. Up to 256 devices can be addressed on one of these -cables. These cables are about one inch in diameter. The maximum unextended -length supported by these cables is 125 Meters but this can be extended up to -2km with a fibre optic channel extended such as a 3044. The maximum burst speed -supported is 4.5 megabytes per second. However, some really old processors -support only transfer rates of 3.0, 2.0 & 1.0 MB/sec. -One of these paths can be daisy chained to up to 8 control units. - - -ESCON if fibre optic it is also called FICON -Was introduced by IBM in 1990. Has 2 fibre optic cables and uses either leds or -lasers for communication at a signaling rate of up to 200 megabits/sec. As -10bits are transferred for every 8 bits info this drops to 160 megabits/sec -and to 18.6 Megabytes/sec once control info and CRC are added. ESCON only -operates in burst mode. - -ESCONs typical max cable length is 3km for the led version and 20km for the -laser version known as XDF (extended distance facility). This can be further -extended by using an ESCON director which triples the above mentioned ranges. -Unlike Bus & Tag as ESCON is serial it uses a packet switching architecture, -the standard Bus & Tag control protocol is however present within the packets. -Up to 256 devices can be attached to each control unit that uses one of these -interfaces. - -Common 390 Devices include: -Network adapters typically OSA2,3172's,2116's & OSA-E gigabit ethernet adapters, -Consoles 3270 & 3215 (a teletype emulated under linux for a line mode console). -DASD's direct access storage devices ( otherwise known as hard disks ). -Tape Drives. -CTC ( Channel to Channel Adapters ), -ESCON or Parallel Cables used as a very high speed serial link -between 2 machines. - - -Debugging IO on s/390 & z/Architecture under VM -=============================================== - -Now we are ready to go on with IO tracing commands under VM - -A few self explanatory queries:: - - Q OSA - Q CTC - Q DISK ( This command is CMS specific ) - Q DASD - -Q OSA on my machine returns:: - - OSA 7C08 ON OSA 7C08 SUBCHANNEL = 0000 - OSA 7C09 ON OSA 7C09 SUBCHANNEL = 0001 - OSA 7C14 ON OSA 7C14 SUBCHANNEL = 0002 - OSA 7C15 ON OSA 7C15 SUBCHANNEL = 0003 - -If you have a guest with certain privileges you may be able to see devices -which don't belong to you. To avoid this, add the option V. -e.g.:: - - Q V OSA - -Now using the device numbers returned by this command we will -Trace the io starting up on the first device 7c08 & 7c09 -In our simplest case we can trace the -start subchannels -like TR SSCH 7C08-7C09 -or the halt subchannels -or TR HSCH 7C08-7C09 -MSCH's ,STSCH's I think you can guess the rest - -A good trick is tracing all the IO's and CCWS and spooling them into the reader -of another VM guest so he can ftp the logfile back to his own machine. I'll do -a small bit of this and give you a look at the output. - -1) Spool stdout to VM reader:: - - SP PRT TO (another vm guest ) or * for the local vm guest - -2) Fill the reader with the trace:: - - TR IO 7c08-7c09 INST INT CCW PRT RUN - -3) Start up linux:: - - i 00c -4) Finish the trace:: - - TR END - -5) close the reader:: - - C PRT - -6) list reader contents:: - - RDRLIST - -7) copy it to linux4's minidisk:: - - RECEIVE / LOG TXT A1 ( replace - -8) -filel & press F11 to look at it -You should see something like:: - - 00020942' SSCH B2334000 0048813C CC 0 SCH 0000 DEV 7C08 - CPA 000FFDF0 PARM 00E2C9C4 KEY 0 FPI C0 LPM 80 - CCW 000FFDF0 E4200100 00487FE8 0000 E4240100 ........ - IDAL 43D8AFE8 - IDAL 0FB76000 - 00020B0A' I/O DEV 7C08 -> 000197BC' SCH 0000 PARM 00E2C9C4 - 00021628' TSCH B2354000 >> 00488164 CC 0 SCH 0000 DEV 7C08 - CCWA 000FFDF8 DEV STS 0C SCH STS 00 CNT 00EC - KEY 0 FPI C0 CC 0 CTLS 4007 - 00022238' STSCH B2344000 >> 00488108 CC 0 SCH 0000 DEV 7C08 - -If you don't like messing up your readed ( because you possibly booted from it ) -you can alternatively spool it to another readers guest. - - -Other common VM device related commands ---------------------------------------------- -These commands are listed only because they have -been of use to me in the past & may be of use to -you too. For more complete info on each of the commands -use type HELP from CMS. - -detaching devices:: - - DET - ATT - -attach a device to guest * for your own guest - -READY - cause VM to issue a fake interrupt. - -The VARY command is normally only available to VM administrators:: - - VARY ON PATH TO - VARY OFF PATH FROM - -This is used to switch on or off channel paths to devices. - -Q CHPID - This displays state of devices using this channel path - -D SCHIB - This displays the subchannel information SCHIB block for the device. - this I believe is also only available to administrators. - -DEFINE CTC - defines a virtual CTC channel to channel connection - 2 need to be defined on each guest for the CTC driver to use. - -COUPLE devno userid remote devno - Joins a local virtual device to a remote virtual device - ( commonly used for the CTC driver ). - -Building a VM ramdisk under CMS which linux can use:: - - def vfb- - -blocksize is commonly 4096 for linux. - -Formatting it:: - - format (blksize - -Sharing a disk between multiple guests:: - - LINK userid devno1 devno2 mode password - - - -GDB on S390 -=========== -N.B. if compiling for debugging gdb works better without optimisation -( see Compiling programs for debugging ) - -invocation ----------- -gdb - -Online help ------------ -help: gives help on commands - -e.g.:: - - help - help display - -Note gdb's online help is very good use it. - - -Assembly --------- -info registers: - displays registers other than floating point. - -info all-registers: - displays floating points as well. - -disassemble: - disassembles - -e.g.:: - - disassemble without parameters will disassemble the current function - disassemble $pc $pc+10 - -Viewing & modifying variables ------------------------------ -print or p: - displays variable or register - -e.g. p/x $sp will display the stack pointer - -display: - prints variable or register each time program stops - -e.g.:: - - display/x $pc will display the program counter - display argc - -undisplay: - undo's display's - -info breakpoints: - shows all current breakpoints - -info stack: - shows stack back trace (if this doesn't work too well, I'll show - you the stacktrace by hand below). - -info locals: - displays local variables. - -info args: - display current procedure arguments. - -set args: - will set argc & argv each time the victim program is invoked - -e.g.:: - - set =value - set argc=100 - set $pc=0 - - - -Modifying execution -------------------- -step: - steps n lines of sourcecode - -step - steps 1 line. - -step 100 - steps 100 lines of code. - -next: - like step except this will not step into subroutines - -stepi: - steps a single machine code instruction. - -e.g.:: - - stepi 100 - -nexti: - steps a single machine code instruction but will not step into - subroutines. - -finish: - will run until exit of the current routine - -run: - (re)starts a program - -cont: - continues a program - -quit: - exits gdb. - - -breakpoints ------------- - -break - sets a breakpoint - -e.g.:: - - break main - break *$pc - break *0x400618 - -Here's a really useful one for large programs - -rbr - Set a breakpoint for all functions matching REGEXP - -e.g.:: - - rbr 390 - -will set a breakpoint with all functions with 390 in their name. - -info breakpoints - lists all breakpoints - -delete: - delete breakpoint by number or delete them all - -e.g. - -delete 1 - will delete the first breakpoint - - -delete - will delete them all - -watch: - This will set a watchpoint ( usually hardware assisted ), - -This will watch a variable till it changes - -e.g. - -watch cnt - will watch the variable cnt till it changes. - -As an aside unfortunately gdb's, architecture independent watchpoint code -is inconsistent & not very good, watchpoints usually work but not always. - -info watchpoints: - Display currently active watchpoints - -condition: ( another useful one ) - Specify breakpoint number N to break only if COND is true. - -Usage is `condition N COND`, where N is an integer and COND is an -expression to be evaluated whenever breakpoint N is reached. - - - -User defined functions/macros ------------------------------ -define: ( Note this is very very useful,simple & powerful ) - -usage define end - -examples which you should consider putting into .gdbinit in your home -directory:: - - define d - stepi - disassemble $pc $pc+10 - end - define e - nexti - disassemble $pc $pc+10 - end - - -Other hard to classify stuff ----------------------------- -signal n: - sends the victim program a signal. - -e.g. `signal 3` will send a SIGQUIT. - -info signals: - what gdb does when the victim receives certain signals. - -list: - -e.g.: - -list - lists current function source -list 1,10 - list first 10 lines of current file. - -list test.c:1,10 - - -directory: - Adds directories to be searched for source if gdb cannot find the source. - (note it is a bit sensitive about slashes) - -e.g. To add the root of the filesystem to the searchpath do:: - - directory // - - -call -This calls a function in the victim program, this is pretty powerful -e.g. -(gdb) call printf("hello world") -outputs: -$1 = 11 - -You might now be thinking that the line above didn't work, something extra had -to be done. -(gdb) call fflush(stdout) -hello world$2 = 0 -As an aside the debugger also calls malloc & free under the hood -to make space for the "hello world" string. - - - -hints ------ -1) command completion works just like bash - ( if you are a bad typist like me this really helps ) - -e.g. hit br & cursor up & down :-). - -2) if you have a debugging problem that takes a few steps to recreate -put the steps into a file called .gdbinit in your current working directory -if you have defined a few extra useful user defined commands put these in -your home directory & they will be read each time gdb is launched. - -A typical .gdbinit file might be.:: - - break main - run - break runtime_exception - cont - - -stack chaining in gdb by hand ------------------------------ -This is done using a the same trick described for VM:: - - p/x (*($sp+56))&0x7fffffff - -get the first backchain. - -For z/Architecture -Replace 56 with 112 & ignore the &0x7fffffff -in the macros below & do nasty casts to longs like the following -as gdb unfortunately deals with printed arguments as ints which -messes up everything. - -i.e. here is a 3rd backchain dereference:: - - p/x *(long *)(***(long ***)$sp+112) - - -this outputs:: - - $5 = 0x528f18 - -on my machine. - -Now you can use:: - - info symbol (*($sp+56))&0x7fffffff - -you might see something like:: - - rl_getc + 36 in section .text - -telling you what is located at address 0x528f18 -Now do:: - - p/x (*(*$sp+56))&0x7fffffff - -This outputs:: - - $6 = 0x528ed0 - -Now do:: - - info symbol (*(*$sp+56))&0x7fffffff - rl_read_key + 180 in section .text - -now do:: - - p/x (*(**$sp+56))&0x7fffffff - -& so on. - -Disassembling instructions without debug info ---------------------------------------------- -gdb typically complains if there is a lack of debugging -symbols in the disassemble command with -"No function contains specified address." To get around -this do:: - - x/xi
    - -e.g.:: - - x/20xi 0x400730 - - - -Note: - Remember gdb has history just like bash you don't need to retype the - whole line just use the up & down arrows. - - - -For more info -------------- -From your linuxbox do:: - - man gdb - -or:: - - info gdb. - -core dumps ----------- - -What a core dump ? -^^^^^^^^^^^^^^^^^^ - -A core dump is a file generated by the kernel (if allowed) which contains the -registers and all active pages of the program which has crashed. - -From this file gdb will allow you to look at the registers, stack trace and -memory of the program as if it just crashed on your system. It is usually -called core and created in the current working directory. - -This is very useful in that a customer can mail a core dump to a technical -support department and the technical support department can reconstruct what -happened. Provided they have an identical copy of this program with debugging -symbols compiled in and the source base of this build is available. - -In short it is far more useful than something like a crash log could ever hope -to be. - -Why have I never seen one ? -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Probably because you haven't used the command:: - - ulimit -c unlimited in bash - -to allow core dumps, now do:: - - ulimit -a - -to verify that the limit was accepted. - -A sample core dump - To create this I'm going to do:: - - ulimit -c unlimited - gdb - -to launch gdb (my victim app. ) now be bad & do the following from another -telnet/xterm session to the same machine:: - - ps -aux | grep gdb - kill -SIGSEGV - -or alternatively use `killall -SIGSEGV gdb` if you have the killall command. - -Now look at the core dump:: - - ./gdb core - -Displays the following:: - - GNU gdb 4.18 - Copyright 1998 Free Software Foundation, Inc. - GDB is free software, covered by the GNU General Public License, and you are - welcome to change it and/or distribute copies of it under certain conditions. - Type "show copying" to see the conditions. - There is absolutely no warranty for GDB. Type "show warranty" for details. - This GDB was configured as "s390-ibm-linux"... - Core was generated by `./gdb'. - Program terminated with signal 11, Segmentation fault. - Reading symbols from /usr/lib/libncurses.so.4...done. - Reading symbols from /lib/libm.so.6...done. - Reading symbols from /lib/libc.so.6...done. - Reading symbols from /lib/ld-linux.so.2...done. - #0 0x40126d1a in read () from /lib/libc.so.6 - Setting up the environment for debugging gdb. - Breakpoint 1 at 0x4dc6f8: file utils.c, line 471. - Breakpoint 2 at 0x4d87a4: file top.c, line 2609. - (top-gdb) info stack - #0 0x40126d1a in read () from /lib/libc.so.6 - #1 0x528f26 in rl_getc (stream=0x7ffffde8) at input.c:402 - #2 0x528ed0 in rl_read_key () at input.c:381 - #3 0x5167e6 in readline_internal_char () at readline.c:454 - #4 0x5168ee in readline_internal_charloop () at readline.c:507 - #5 0x51692c in readline_internal () at readline.c:521 - #6 0x5164fe in readline (prompt=0x7ffff810) - at readline.c:349 - #7 0x4d7a8a in command_line_input (prompt=0x564420 "(gdb) ", repeat=1, - annotation_suffix=0x4d6b44 "prompt") at top.c:2091 - #8 0x4d6cf0 in command_loop () at top.c:1345 - #9 0x4e25bc in main (argc=1, argv=0x7ffffdf4) at main.c:635 - - -LDD -=== -This is a program which lists the shared libraries which a library needs, -Note you also get the relocations of the shared library text segments which -help when using objdump --source. - -e.g.:: - - ldd ./gdb - -outputs:: - - libncurses.so.4 => /usr/lib/libncurses.so.4 (0x40018000) - libm.so.6 => /lib/libm.so.6 (0x4005e000) - libc.so.6 => /lib/libc.so.6 (0x40084000) - /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) - - -Debugging shared libraries -========================== -Most programs use shared libraries, however it can be very painful -when you single step instruction into a function like printf for the -first time & you end up in functions like _dl_runtime_resolve this is -the ld.so doing lazy binding, lazy binding is a concept in ELF where -shared library functions are not loaded into memory unless they are -actually used, great for saving memory but a pain to debug. - -To get around this either relink the program -static or exit gdb type -export LD_BIND_NOW=true this will stop lazy binding & restart the gdb'ing -the program in question. - - - -Debugging modules -================= -As modules are dynamically loaded into the kernel their address can be -anywhere to get around this use the -m option with insmod to emit a load -map which can be piped into a file if required. - -The proc file system -==================== -What is it ?. -It is a filesystem created by the kernel with files which are created on demand -by the kernel if read, or can be used to modify kernel parameters, -it is a powerful concept. - -e.g.:: - - cat /proc/sys/net/ipv4/ip_forward - -On my machine outputs:: - - 0 - -telling me ip_forwarding is not on to switch it on I can do:: - - echo 1 > /proc/sys/net/ipv4/ip_forward - -cat it again:: - - cat /proc/sys/net/ipv4/ip_forward - -On my machine now outputs:: - - 1 - -IP forwarding is on. - -There is a lot of useful info in here best found by going in and having a look -around, so I'll take you through some entries I consider important. - -All the processes running on the machine have their own entry defined by -/proc/ - -So lets have a look at the init process:: - - cd /proc/1 - cat cmdline - -emits:: - - init [2] - -:: - - cd /proc/1/fd - -This contains numerical entries of all the open files, -some of these you can cat e.g. stdout (2):: - - cat /proc/29/maps - -on my machine emits:: - - 00400000-00478000 r-xp 00000000 5f:00 4103 /bin/bash - 00478000-0047e000 rw-p 00077000 5f:00 4103 /bin/bash - 0047e000-00492000 rwxp 00000000 00:00 0 - 40000000-40015000 r-xp 00000000 5f:00 14382 /lib/ld-2.1.2.so - 40015000-40016000 rw-p 00014000 5f:00 14382 /lib/ld-2.1.2.so - 40016000-40017000 rwxp 00000000 00:00 0 - 40017000-40018000 rw-p 00000000 00:00 0 - 40018000-4001b000 r-xp 00000000 5f:00 14435 /lib/libtermcap.so.2.0.8 - 4001b000-4001c000 rw-p 00002000 5f:00 14435 /lib/libtermcap.so.2.0.8 - 4001c000-4010d000 r-xp 00000000 5f:00 14387 /lib/libc-2.1.2.so - 4010d000-40111000 rw-p 000f0000 5f:00 14387 /lib/libc-2.1.2.so - 40111000-40114000 rw-p 00000000 00:00 0 - 40114000-4011e000 r-xp 00000000 5f:00 14408 /lib/libnss_files-2.1.2.so - 4011e000-4011f000 rw-p 00009000 5f:00 14408 /lib/libnss_files-2.1.2.so - 7fffd000-80000000 rwxp ffffe000 00:00 0 - - -Showing us the shared libraries init uses where they are in memory -& memory access permissions for each virtual memory area. - -/proc/1/cwd is a softlink to the current working directory. - -/proc/1/root is the root of the filesystem for this process. - -/proc/1/mem is the current running processes memory which you -can read & write to like a file. - -strace uses this sometimes as it is a bit faster than the -rather inefficient ptrace interface for peeking at DATA. - -:: - - cat status - - Name: init - State: S (sleeping) - Pid: 1 - PPid: 0 - Uid: 0 0 0 0 - Gid: 0 0 0 0 - Groups: - VmSize: 408 kB - VmLck: 0 kB - VmRSS: 208 kB - VmData: 24 kB - VmStk: 8 kB - VmExe: 368 kB - VmLib: 0 kB - SigPnd: 0000000000000000 - SigBlk: 0000000000000000 - SigIgn: 7fffffffd7f0d8fc - SigCgt: 00000000280b2603 - CapInh: 00000000fffffeff - CapPrm: 00000000ffffffff - CapEff: 00000000fffffeff - - User PSW: 070de000 80414146 - task: 004b6000 tss: 004b62d8 ksp: 004b7ca8 pt_regs: 004b7f68 - User GPRS: - 00000400 00000000 0000000b 7ffffa90 - 00000000 00000000 00000000 0045d9f4 - 0045cafc 7ffffa90 7fffff18 0045cb08 - 00010400 804039e8 80403af8 7ffff8b0 - User ACRS: - 00000000 00000000 00000000 00000000 - 00000001 00000000 00000000 00000000 - 00000000 00000000 00000000 00000000 - 00000000 00000000 00000000 00000000 - Kernel BackChain CallChain BackChain CallChain - 004b7ca8 8002bd0c 004b7d18 8002b92c - 004b7db8 8005cd50 004b7e38 8005d12a - 004b7f08 80019114 - -Showing among other things memory usage & status of some signals & -the processes'es registers from the kernel task_structure -as well as a backchain which may be useful if a process crashes -in the kernel for some unknown reason. - -Some driver debugging techniques -================================ -debug feature -------------- -Some of our drivers now support a "debug feature" in -/proc/s390dbf see s390dbf.txt in the linux/Documentation directory -for more info. - -e.g. -to switch on the lcs "debug feature":: - - echo 5 > /proc/s390dbf/lcs/level - -& then after the error occurred:: - - cat /proc/s390dbf/lcs/sprintf >/logfile - -the logfile now contains some information which may help -tech support resolve a problem in the field. - - - -high level debugging network drivers ------------------------------------- -ifconfig is a quite useful command -it gives the current state of network drivers. - -If you suspect your network device driver is dead -one way to check is type:: - - ifconfig - -e.g. tr0 - -You should see something like:: - - ifconfig tr0 - tr0 Link encap:16/4 Mbps Token Ring (New) HWaddr 00:04:AC:20:8E:48 - inet addr:9.164.185.132 Bcast:9.164.191.255 Mask:255.255.224.0 - UP BROADCAST RUNNING MULTICAST MTU:2000 Metric:1 - RX packets:246134 errors:0 dropped:0 overruns:0 frame:0 - TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 - collisions:0 txqueuelen:100 - -if the device doesn't say up -try:: - - /etc/rc.d/init.d/network start - -( this starts the network stack & hopefully calls ifconfig tr0 up ). -ifconfig looks at the output of /proc/net/dev and presents it in a more -presentable form. - -Now ping the device from a machine in the same subnet. - -if the RX packets count & TX packets counts don't increment you probably -have problems. - -next:: - - cat /proc/net/arp - -Do you see any hardware addresses in the cache if not you may have problems. -Next try:: - - ping -c 5 - -i.e. the Bcast field above in the output of -ifconfig. Do you see any replies from machines other than the local machine -if not you may have problems. also if the TX packets count in ifconfig -hasn't incremented either you have serious problems in your driver -(e.g. the txbusy field of the network device being stuck on ) -or you may have multiple network devices connected. - - -chandev -------- -There is a new device layer for channel devices, some -drivers e.g. lcs are registered with this layer. - -If the device uses the channel device layer you'll be -able to find what interrupts it uses & the current state -of the device. - -See the manpage chandev.8 &type cat /proc/chandev for more info. - - -SysRq -===== -This is now supported by linux for s/390 & z/Architecture. - -To enable it do compile the kernel with:: - - Kernel Hacking -> Magic SysRq Key Enabled - -Then:: - - echo "1" > /proc/sys/kernel/sysrq - -also type:: - - echo "8" >/proc/sys/kernel/printk - -To make printk output go to console. - -On 390 all commands are prefixed with:: - - ^- - -e.g.:: - - ^-t will show tasks. - ^-? or some unknown command will display help. - -The sysrq key reading is very picky ( I have to type the keys in an -xterm session & paste them into the x3270 console ) -& it may be wise to predefine the keys as described in the VM hints above - -This is particularly useful for syncing disks unmounting & rebooting -if the machine gets partially hung. - -Read Documentation/admin-guide/sysrq.rst for more info - -References: -=========== -- Enterprise Systems Architecture Reference Summary -- Enterprise Systems Architecture Principles of Operation -- Hartmut Penners s390 stack frame sheet. -- IBM Mainframe Channel Attachment a technology brief from a CISCO webpage -- Various bits of man & info pages of Linux. -- Linux & GDB source. -- Various info & man pages. -- CMS Help on tracing commands. -- Linux for s/390 Elf Application Binary Interface -- Linux for z/Series Elf Application Binary Interface ( Both Highly Recommended ) -- z/Architecture Principles of Operation SA22-7832-00 -- Enterprise Systems Architecture/390 Reference Summary SA22-7209-01 & the -- Enterprise Systems Architecture/390 Principles of Operation SA22-7201-05 - -Special Thanks -============== -Special thanks to Neale Ferguson who maintains a much -prettier HTML version of this page at -http://linuxvm.org/penguinvm/ -Bob Grainger Stefan Bader & others for reporting bugs diff --git a/Documentation/s390/index.rst b/Documentation/s390/index.rst index 4602312909d3..f7af2061e406 100644 --- a/Documentation/s390/index.rst +++ b/Documentation/s390/index.rst @@ -7,7 +7,6 @@ s390 Architecture cds 3270 - debugging390 driver-model monreader qeth @@ -15,7 +14,6 @@ s390 Architecture vfio-ap vfio-ccw zfcpdump - dasd common_io text_files diff --git a/Documentation/scheduler/sched-bwc.rst b/Documentation/scheduler/sched-bwc.rst index 3a9064219656..9801d6b284b1 100644 --- a/Documentation/scheduler/sched-bwc.rst +++ b/Documentation/scheduler/sched-bwc.rst @@ -9,15 +9,16 @@ CFS bandwidth control is a CONFIG_FAIR_GROUP_SCHED extension which allows the specification of the maximum CPU bandwidth available to a group or hierarchy. The bandwidth allowed for a group is specified using a quota and period. Within -each given "period" (microseconds), a group is allowed to consume only up to -"quota" microseconds of CPU time. When the CPU bandwidth consumption of a -group exceeds this limit (for that period), the tasks belonging to its -hierarchy will be throttled and are not allowed to run again until the next -period. +each given "period" (microseconds), a task group is allocated up to "quota" +microseconds of CPU time. That quota is assigned to per-cpu run queues in +slices as threads in the cgroup become runnable. Once all quota has been +assigned any additional requests for quota will result in those threads being +throttled. Throttled threads will not be able to run again until the next +period when the quota is replenished. -A group's unused runtime is globally tracked, being refreshed with quota units -above at each period boundary. As threads consume this bandwidth it is -transferred to cpu-local "silos" on a demand basis. The amount transferred +A group's unassigned quota is globally tracked, being refreshed back to +cfs_quota units at each period boundary. As threads consume this bandwidth it +is transferred to cpu-local "silos" on a demand basis. The amount transferred within each of these updates is tunable and described as the "slice". Management @@ -35,12 +36,12 @@ The default values are:: A value of -1 for cpu.cfs_quota_us indicates that the group does not have any bandwidth restriction in place, such a group is described as an unconstrained -bandwidth group. This represents the traditional work-conserving behavior for +bandwidth group. This represents the traditional work-conserving behavior for CFS. Writing any (valid) positive value(s) will enact the specified bandwidth limit. -The minimum quota allowed for the quota or period is 1ms. There is also an -upper bound on the period length of 1s. Additional restrictions exist when +The minimum quota allowed for the quota or period is 1ms. There is also an +upper bound on the period length of 1s. Additional restrictions exist when bandwidth limits are used in a hierarchical fashion, these are explained in more detail below. @@ -53,8 +54,8 @@ unthrottled if it is in a constrained state. System wide settings -------------------- For efficiency run-time is transferred between the global pool and CPU local -"silos" in a batch fashion. This greatly reduces global accounting pressure -on large systems. The amount transferred each time such an update is required +"silos" in a batch fashion. This greatly reduces global accounting pressure +on large systems. The amount transferred each time such an update is required is described as the "slice". This is tunable via procfs:: @@ -97,6 +98,51 @@ There are two ways in which a group may become throttled: In case b) above, even though the child may have runtime remaining it will not be allowed to until the parent's runtime is refreshed. +CFS Bandwidth Quota Caveats +--------------------------- +Once a slice is assigned to a cpu it does not expire. However all but 1ms of +the slice may be returned to the global pool if all threads on that cpu become +unrunnable. This is configured at compile time by the min_cfs_rq_runtime +variable. This is a performance tweak that helps prevent added contention on +the global lock. + +The fact that cpu-local slices do not expire results in some interesting corner +cases that should be understood. + +For cgroup cpu constrained applications that are cpu limited this is a +relatively moot point because they will naturally consume the entirety of their +quota as well as the entirety of each cpu-local slice in each period. As a +result it is expected that nr_periods roughly equal nr_throttled, and that +cpuacct.usage will increase roughly equal to cfs_quota_us in each period. + +For highly-threaded, non-cpu bound applications this non-expiration nuance +allows applications to briefly burst past their quota limits by the amount of +unused slice on each cpu that the task group is running on (typically at most +1ms per cpu or as defined by min_cfs_rq_runtime). This slight burst only +applies if quota had been assigned to a cpu and then not fully used or returned +in previous periods. This burst amount will not be transferred between cores. +As a result, this mechanism still strictly limits the task group to quota +average usage, albeit over a longer time window than a single period. This +also limits the burst ability to no more than 1ms per cpu. This provides +better more predictable user experience for highly threaded applications with +small quota limits on high core count machines. It also eliminates the +propensity to throttle these applications while simultanously using less than +quota amounts of cpu. Another way to say this, is that by allowing the unused +portion of a slice to remain valid across periods we have decreased the +possibility of wastefully expiring quota on cpu-local silos that don't need a +full slice's amount of cpu time. + +The interaction between cpu-bound and non-cpu-bound-interactive applications +should also be considered, especially when single core usage hits 100%. If you +gave each of these applications half of a cpu-core and they both got scheduled +on the same CPU it is theoretically possible that the non-cpu bound application +will use up to 1ms additional quota in some periods, thereby preventing the +cpu-bound application from fully using its quota by that same amount. In these +instances it will be up to the CFS algorithm (see sched-design-CFS.rst) to +decide which application is chosen to run, as they will both be runnable and +have remaining quota. This runtime discrepancy will be made up in the following +periods when the interactive application idles. + Examples -------- 1. Limit a group to 1 CPU worth of runtime:: diff --git a/Documentation/security/IMA-templates.rst b/Documentation/security/IMA-templates.rst index 3d1cca287aa4..c5a8432972ef 100644 --- a/Documentation/security/IMA-templates.rst +++ b/Documentation/security/IMA-templates.rst @@ -68,8 +68,10 @@ descriptors by adding their identifier to the format string - 'd-ng': the digest of the event, calculated with an arbitrary hash algorithm (field format: [:]digest, where the digest prefix is shown only if the hash algorithm is not SHA1 or MD5); + - 'd-modsig': the digest of the event without the appended modsig; - 'n-ng': the name of the event, without size limitations; - 'sig': the file signature; + - 'modsig' the appended file signature; - 'buf': the buffer data that was used to generate the hash without size limitations; @@ -79,6 +81,7 @@ Below, there is the list of defined template descriptors: - "ima-ng" (default): its format is ``d-ng|n-ng``; - "ima-sig": its format is ``d-ng|n-ng|sig``; - "ima-buf": its format is ``d-ng|n-ng|buf``; + - "ima-modsig": its format is ``d-ng|n-ng|sig|d-modsig|modsig``; Use diff --git a/Documentation/security/tpm/index.rst b/Documentation/security/tpm/index.rst index 3296533e54cf..fc40e9f23c85 100644 --- a/Documentation/security/tpm/index.rst +++ b/Documentation/security/tpm/index.rst @@ -4,5 +4,7 @@ Trusted Platform Module documentation .. toctree:: + tpm_event_log tpm_vtpm_proxy xen-tpmfront + tpm_ftpm_tee diff --git a/Documentation/security/tpm/tpm_event_log.rst b/Documentation/security/tpm/tpm_event_log.rst new file mode 100644 index 000000000000..f00f7a1d5e92 --- /dev/null +++ b/Documentation/security/tpm/tpm_event_log.rst @@ -0,0 +1,55 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============= +TPM Event Log +============= + +This document briefly describes what TPM log is and how it is handed +over from the preboot firmware to the operating system. + +Introduction +============ + +The preboot firmware maintains an event log that gets new entries every +time something gets hashed by it to any of the PCR registers. The events +are segregated by their type and contain the value of the hashed PCR +register. Typically, the preboot firmware will hash the components to +who execution is to be handed over or actions relevant to the boot +process. + +The main application for this is remote attestation and the reason why +it is useful is nicely put in the very first section of [1]: + +"Attestation is used to provide information about the platform’s state +to a challenger. However, PCR contents are difficult to interpret; +therefore, attestation is typically more useful when the PCR contents +are accompanied by a measurement log. While not trusted on their own, +the measurement log contains a richer set of information than do the PCR +contents. The PCR contents are used to provide the validation of the +measurement log." + +UEFI event log +============== + +UEFI provided event log has a few somewhat weird quirks. + +Before calling ExitBootServices() Linux EFI stub copies the event log to +a custom configuration table defined by the stub itself. Unfortunately, +the events generated by ExitBootServices() don't end up in the table. + +The firmware provides so called final events configuration table to sort +out this issue. Events gets mirrored to this table after the first time +EFI_TCG2_PROTOCOL.GetEventLog() gets called. + +This introduces another problem: nothing guarantees that it is not called +before the Linux EFI stub gets to run. Thus, it needs to calculate and save the +final events table size while the stub is still running to the custom +configuration table so that the TPM driver can later on skip these events when +concatenating two halves of the event log from the custom configuration table +and the final events table. + +References +========== + +- [1] https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/ +- [2] The final concatenation is done in drivers/char/tpm/eventlog/efi.c diff --git a/Documentation/security/tpm/tpm_ftpm_tee.rst b/Documentation/security/tpm/tpm_ftpm_tee.rst new file mode 100644 index 000000000000..8c2bae16e3d9 --- /dev/null +++ b/Documentation/security/tpm/tpm_ftpm_tee.rst @@ -0,0 +1,27 @@ +============================================= +Firmware TPM Driver +============================================= + +This document describes the firmware Trusted Platform Module (fTPM) +device driver. + +Introduction +============ + +This driver is a shim for firmware implemented in ARM's TrustZone +environment. The driver allows programs to interact with the TPM in the same +way they would interact with a hardware TPM. + +Design +====== + +The driver acts as a thin layer that passes commands to and from a TPM +implemented in firmware. The driver itself doesn't contain much logic and is +used more like a dumb pipe between firmware and kernel/userspace. + +The firmware itself is based on the following paper: +https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/ftpm1.pdf + +When the driver is loaded it will expose ``/dev/tpmX`` character devices to +userspace which will enable userspace to communicate with the firmware TPM +through this device. diff --git a/Documentation/sound/alsa-configuration.rst b/Documentation/sound/alsa-configuration.rst index 4a3cecc8ad38..02aacd69ab96 100644 --- a/Documentation/sound/alsa-configuration.rst +++ b/Documentation/sound/alsa-configuration.rst @@ -1001,6 +1001,8 @@ position_fix 2 = POSBUF: use position buffer, 3 = VIACOMBO: VIA-specific workaround for capture, 4 = COMBO: use LPIB for playback, auto for capture stream + 5 = SKL+: apply the delay calculation available on recent Intel chips + 6 = FIFO: correct the position with the fixed FIFO size, for recent AMD chips probe_mask Bitmask to probe codecs (default = -1, meaning all slots); When the bit 8 (0x100) is set, the lower 8 bits are used diff --git a/Documentation/sound/hd-audio/models.rst b/Documentation/sound/hd-audio/models.rst index 7d7c191102a7..11298f0ce44d 100644 --- a/Documentation/sound/hd-audio/models.rst +++ b/Documentation/sound/hd-audio/models.rst @@ -260,6 +260,9 @@ alc295-hp-x360 HP Spectre X360 fixups alc-sense-combo Headset button support for Chrome platform +huawei-mbx-stereo + Enable initialization verbs for Huawei MBX stereo speakers; + might be risky, try this at your own risk ALC66x/67x/892 ============== diff --git a/Documentation/sound/hd-audio/notes.rst b/Documentation/sound/hd-audio/notes.rst index 9f7347830ba4..0f3109d9abc8 100644 --- a/Documentation/sound/hd-audio/notes.rst +++ b/Documentation/sound/hd-audio/notes.rst @@ -66,6 +66,11 @@ by comparing both LPIB and position-buffer values. ``position_fix=4`` is another combination available for all controllers, and uses LPIB for the playback and the position-buffer for the capture streams. +``position_fix=5`` is specific to Intel platforms, so far, for Skylake +and onward. It applies the delay calculation for the precise position +reporting. +``position_fix=6`` is to correct the position with the fixed FIFO +size, mainly targeted for the recent AMD controllers. 0 is the default value for all other controllers, the automatic check and fallback to LPIB as described in the above. If you get a problem of repeated sounds, this option might diff --git a/Documentation/sound/index.rst b/Documentation/sound/index.rst index 47b89f014e69..4d7d42acf6df 100644 --- a/Documentation/sound/index.rst +++ b/Documentation/sound/index.rst @@ -12,7 +12,7 @@ Linux Sound Subsystem Documentation hd-audio/index cards/index -.. only:: subproject +.. only:: subproject and html Indices ======= diff --git a/Documentation/sphinx/automarkup.py b/Documentation/sphinx/automarkup.py index 77e89c1956d7..5b6119ff69f4 100644 --- a/Documentation/sphinx/automarkup.py +++ b/Documentation/sphinx/automarkup.py @@ -25,8 +25,9 @@ RE_function = re.compile(r'([\w_][\w\d_]+\(\))') # to the creation of incorrect and confusing cross references. So # just don't even try with these names. # -Skipfuncs = [ 'open', 'close', 'read', 'write', 'fcntl', 'mmap' - 'select', 'poll', 'fork', 'execve', 'clone', 'ioctl'] +Skipfuncs = [ 'open', 'close', 'read', 'write', 'fcntl', 'mmap', + 'select', 'poll', 'fork', 'execve', 'clone', 'ioctl', + 'socket' ] # # Find all occurrences of function() and try to replace them with diff --git a/Documentation/spi/butterfly b/Documentation/spi/butterfly deleted file mode 100644 index 9927af7a629c..000000000000 --- a/Documentation/spi/butterfly +++ /dev/null @@ -1,68 +0,0 @@ -spi_butterfly - parport-to-butterfly adapter driver -=================================================== - -This is a hardware and software project that includes building and using -a parallel port adapter cable, together with an "AVR Butterfly" to run -firmware for user interfacing and/or sensors. A Butterfly is a $US20 -battery powered card with an AVR microcontroller and lots of goodies: -sensors, LCD, flash, toggle stick, and more. You can use AVR-GCC to -develop firmware for this, and flash it using this adapter cable. - -You can make this adapter from an old printer cable and solder things -directly to the Butterfly. Or (if you have the parts and skills) you -can come up with something fancier, providing ciruit protection to the -Butterfly and the printer port, or with a better power supply than two -signal pins from the printer port. Or for that matter, you can use -similar cables to talk to many AVR boards, even a breadboard. - -This is more powerful than "ISP programming" cables since it lets kernel -SPI protocol drivers interact with the AVR, and could even let the AVR -issue interrupts to them. Later, your protocol driver should work -easily with a "real SPI controller", instead of this bitbanger. - - -The first cable connections will hook Linux up to one SPI bus, with the -AVR and a DataFlash chip; and to the AVR reset line. This is all you -need to reflash the firmware, and the pins are the standard Atmel "ISP" -connector pins (used also on non-Butterfly AVR boards). On the parport -side this is like "sp12" programming cables. - - Signal Butterfly Parport (DB-25) - ------ --------- --------------- - SCK = J403.PB1/SCK = pin 2/D0 - RESET = J403.nRST = pin 3/D1 - VCC = J403.VCC_EXT = pin 8/D6 - MOSI = J403.PB2/MOSI = pin 9/D7 - MISO = J403.PB3/MISO = pin 11/S7,nBUSY - GND = J403.GND = pin 23/GND - -Then to let Linux master that bus to talk to the DataFlash chip, you must -(a) flash new firmware that disables SPI (set PRR.2, and disable pullups -by clearing PORTB.[0-3]); (b) configure the mtd_dataflash driver; and -(c) cable in the chipselect. - - Signal Butterfly Parport (DB-25) - ------ --------- --------------- - VCC = J400.VCC_EXT = pin 7/D5 - SELECT = J400.PB0/nSS = pin 17/C3,nSELECT - GND = J400.GND = pin 24/GND - -Or you could flash firmware making the AVR into an SPI slave (keeping the -DataFlash in reset) and tweak the spi_butterfly driver to make it bind to -the driver for your custom SPI-based protocol. - -The "USI" controller, using J405, can also be used for a second SPI bus. -That would let you talk to the AVR using custom SPI-with-USI firmware, -while letting either Linux or the AVR use the DataFlash. There are plenty -of spare parport pins to wire this one up, such as: - - Signal Butterfly Parport (DB-25) - ------ --------- --------------- - SCK = J403.PE4/USCK = pin 5/D3 - MOSI = J403.PE5/DI = pin 6/D4 - MISO = J403.PE6/DO = pin 12/S5,nPAPEROUT - GND = J403.GND = pin 22/GND - - IRQ = J402.PF4 = pin 10/S6,ACK - GND = J402.GND(P2) = pin 25/GND - diff --git a/Documentation/spi/butterfly.rst b/Documentation/spi/butterfly.rst new file mode 100644 index 000000000000..e614a589547c --- /dev/null +++ b/Documentation/spi/butterfly.rst @@ -0,0 +1,74 @@ +=================================================== +spi_butterfly - parport-to-butterfly adapter driver +=================================================== + +This is a hardware and software project that includes building and using +a parallel port adapter cable, together with an "AVR Butterfly" to run +firmware for user interfacing and/or sensors. A Butterfly is a $US20 +battery powered card with an AVR microcontroller and lots of goodies: +sensors, LCD, flash, toggle stick, and more. You can use AVR-GCC to +develop firmware for this, and flash it using this adapter cable. + +You can make this adapter from an old printer cable and solder things +directly to the Butterfly. Or (if you have the parts and skills) you +can come up with something fancier, providing ciruit protection to the +Butterfly and the printer port, or with a better power supply than two +signal pins from the printer port. Or for that matter, you can use +similar cables to talk to many AVR boards, even a breadboard. + +This is more powerful than "ISP programming" cables since it lets kernel +SPI protocol drivers interact with the AVR, and could even let the AVR +issue interrupts to them. Later, your protocol driver should work +easily with a "real SPI controller", instead of this bitbanger. + + +The first cable connections will hook Linux up to one SPI bus, with the +AVR and a DataFlash chip; and to the AVR reset line. This is all you +need to reflash the firmware, and the pins are the standard Atmel "ISP" +connector pins (used also on non-Butterfly AVR boards). On the parport +side this is like "sp12" programming cables. + + ====== ============= =================== + Signal Butterfly Parport (DB-25) + ====== ============= =================== + SCK J403.PB1/SCK pin 2/D0 + RESET J403.nRST pin 3/D1 + VCC J403.VCC_EXT pin 8/D6 + MOSI J403.PB2/MOSI pin 9/D7 + MISO J403.PB3/MISO pin 11/S7,nBUSY + GND J403.GND pin 23/GND + ====== ============= =================== + +Then to let Linux master that bus to talk to the DataFlash chip, you must +(a) flash new firmware that disables SPI (set PRR.2, and disable pullups +by clearing PORTB.[0-3]); (b) configure the mtd_dataflash driver; and +(c) cable in the chipselect. + + ====== ============ =================== + Signal Butterfly Parport (DB-25) + ====== ============ =================== + VCC J400.VCC_EXT pin 7/D5 + SELECT J400.PB0/nSS pin 17/C3,nSELECT + GND J400.GND pin 24/GND + ====== ============ =================== + +Or you could flash firmware making the AVR into an SPI slave (keeping the +DataFlash in reset) and tweak the spi_butterfly driver to make it bind to +the driver for your custom SPI-based protocol. + +The "USI" controller, using J405, can also be used for a second SPI bus. +That would let you talk to the AVR using custom SPI-with-USI firmware, +while letting either Linux or the AVR use the DataFlash. There are plenty +of spare parport pins to wire this one up, such as: + + ====== ============= =================== + Signal Butterfly Parport (DB-25) + ====== ============= =================== + SCK J403.PE4/USCK pin 5/D3 + MOSI J403.PE5/DI pin 6/D4 + MISO J403.PE6/DO pin 12/S5,nPAPEROUT + GND J403.GND pin 22/GND + + IRQ J402.PF4 pin 10/S6,ACK + GND J402.GND(P2) pin 25/GND + ====== ============= =================== diff --git a/Documentation/spi/index.rst b/Documentation/spi/index.rst new file mode 100644 index 000000000000..06c34ea11bcf --- /dev/null +++ b/Documentation/spi/index.rst @@ -0,0 +1,22 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================= +Serial Peripheral Interface (SPI) +================================= + +.. toctree:: + :maxdepth: 1 + + spi-summary + spidev + butterfly + pxa2xx + spi-lm70llp + spi-sc18is602 + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/spi/pxa2xx b/Documentation/spi/pxa2xx deleted file mode 100644 index 551325b66b23..000000000000 --- a/Documentation/spi/pxa2xx +++ /dev/null @@ -1,235 +0,0 @@ -PXA2xx SPI on SSP driver HOWTO -=================================================== -This a mini howto on the pxa2xx_spi driver. The driver turns a PXA2xx -synchronous serial port into a SPI master controller -(see Documentation/spi/spi-summary). The driver has the following features - -- Support for any PXA2xx SSP -- SSP PIO and SSP DMA data transfers. -- External and Internal (SSPFRM) chip selects. -- Per slave device (chip) configuration. -- Full suspend, freeze, resume support. - -The driver is built around a "spi_message" fifo serviced by workqueue and a -tasklet. The workqueue, "pump_messages", drives message fifo and the tasklet -(pump_transfer) is responsible for queuing SPI transactions and setting up and -launching the dma/interrupt driven transfers. - -Declaring PXA2xx Master Controllers ------------------------------------ -Typically a SPI master is defined in the arch/.../mach-*/board-*.c as a -"platform device". The master configuration is passed to the driver via a table -found in include/linux/spi/pxa2xx_spi.h: - -struct pxa2xx_spi_controller { - u16 num_chipselect; - u8 enable_dma; -}; - -The "pxa2xx_spi_controller.num_chipselect" field is used to determine the number of -slave device (chips) attached to this SPI master. - -The "pxa2xx_spi_controller.enable_dma" field informs the driver that SSP DMA should -be used. This caused the driver to acquire two DMA channels: rx_channel and -tx_channel. The rx_channel has a higher DMA service priority the tx_channel. -See the "PXA2xx Developer Manual" section "DMA Controller". - -NSSP MASTER SAMPLE ------------------- -Below is a sample configuration using the PXA255 NSSP. - -static struct resource pxa_spi_nssp_resources[] = { - [0] = { - .start = __PREG(SSCR0_P(2)), /* Start address of NSSP */ - .end = __PREG(SSCR0_P(2)) + 0x2c, /* Range of registers */ - .flags = IORESOURCE_MEM, - }, - [1] = { - .start = IRQ_NSSP, /* NSSP IRQ */ - .end = IRQ_NSSP, - .flags = IORESOURCE_IRQ, - }, -}; - -static struct pxa2xx_spi_controller pxa_nssp_master_info = { - .num_chipselect = 1, /* Matches the number of chips attached to NSSP */ - .enable_dma = 1, /* Enables NSSP DMA */ -}; - -static struct platform_device pxa_spi_nssp = { - .name = "pxa2xx-spi", /* MUST BE THIS VALUE, so device match driver */ - .id = 2, /* Bus number, MUST MATCH SSP number 1..n */ - .resource = pxa_spi_nssp_resources, - .num_resources = ARRAY_SIZE(pxa_spi_nssp_resources), - .dev = { - .platform_data = &pxa_nssp_master_info, /* Passed to driver */ - }, -}; - -static struct platform_device *devices[] __initdata = { - &pxa_spi_nssp, -}; - -static void __init board_init(void) -{ - (void)platform_add_device(devices, ARRAY_SIZE(devices)); -} - -Declaring Slave Devices ------------------------ -Typically each SPI slave (chip) is defined in the arch/.../mach-*/board-*.c -using the "spi_board_info" structure found in "linux/spi/spi.h". See -"Documentation/spi/spi-summary" for additional information. - -Each slave device attached to the PXA must provide slave specific configuration -information via the structure "pxa2xx_spi_chip" found in -"include/linux/spi/pxa2xx_spi.h". The pxa2xx_spi master controller driver -will uses the configuration whenever the driver communicates with the slave -device. All fields are optional. - -struct pxa2xx_spi_chip { - u8 tx_threshold; - u8 rx_threshold; - u8 dma_burst_size; - u32 timeout; - u8 enable_loopback; - void (*cs_control)(u32 command); -}; - -The "pxa2xx_spi_chip.tx_threshold" and "pxa2xx_spi_chip.rx_threshold" fields are -used to configure the SSP hardware fifo. These fields are critical to the -performance of pxa2xx_spi driver and misconfiguration will result in rx -fifo overruns (especially in PIO mode transfers). Good default values are - - .tx_threshold = 8, - .rx_threshold = 8, - -The range is 1 to 16 where zero indicates "use default". - -The "pxa2xx_spi_chip.dma_burst_size" field is used to configure PXA2xx DMA -engine and is related the "spi_device.bits_per_word" field. Read and understand -the PXA2xx "Developer Manual" sections on the DMA controller and SSP Controllers -to determine the correct value. An SSP configured for byte-wide transfers would -use a value of 8. The driver will determine a reasonable default if -dma_burst_size == 0. - -The "pxa2xx_spi_chip.timeout" fields is used to efficiently handle -trailing bytes in the SSP receiver fifo. The correct value for this field is -dependent on the SPI bus speed ("spi_board_info.max_speed_hz") and the specific -slave device. Please note that the PXA2xx SSP 1 does not support trailing byte -timeouts and must busy-wait any trailing bytes. - -The "pxa2xx_spi_chip.enable_loopback" field is used to place the SSP porting -into internal loopback mode. In this mode the SSP controller internally -connects the SSPTX pin to the SSPRX pin. This is useful for initial setup -testing. - -The "pxa2xx_spi_chip.cs_control" field is used to point to a board specific -function for asserting/deasserting a slave device chip select. If the field is -NULL, the pxa2xx_spi master controller driver assumes that the SSP port is -configured to use SSPFRM instead. - -NOTE: the SPI driver cannot control the chip select if SSPFRM is used, so the -chipselect is dropped after each spi_transfer. Most devices need chip select -asserted around the complete message. Use SSPFRM as a GPIO (through cs_control) -to accommodate these chips. - - -NSSP SLAVE SAMPLE ------------------ -The pxa2xx_spi_chip structure is passed to the pxa2xx_spi driver in the -"spi_board_info.controller_data" field. Below is a sample configuration using -the PXA255 NSSP. - -/* Chip Select control for the CS8415A SPI slave device */ -static void cs8415a_cs_control(u32 command) -{ - if (command & PXA2XX_CS_ASSERT) - GPCR(2) = GPIO_bit(2); - else - GPSR(2) = GPIO_bit(2); -} - -/* Chip Select control for the CS8405A SPI slave device */ -static void cs8405a_cs_control(u32 command) -{ - if (command & PXA2XX_CS_ASSERT) - GPCR(3) = GPIO_bit(3); - else - GPSR(3) = GPIO_bit(3); -} - -static struct pxa2xx_spi_chip cs8415a_chip_info = { - .tx_threshold = 8, /* SSP hardward FIFO threshold */ - .rx_threshold = 8, /* SSP hardward FIFO threshold */ - .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */ - .timeout = 235, /* See Intel documentation */ - .cs_control = cs8415a_cs_control, /* Use external chip select */ -}; - -static struct pxa2xx_spi_chip cs8405a_chip_info = { - .tx_threshold = 8, /* SSP hardward FIFO threshold */ - .rx_threshold = 8, /* SSP hardward FIFO threshold */ - .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */ - .timeout = 235, /* See Intel documentation */ - .cs_control = cs8405a_cs_control, /* Use external chip select */ -}; - -static struct spi_board_info streetracer_spi_board_info[] __initdata = { - { - .modalias = "cs8415a", /* Name of spi_driver for this device */ - .max_speed_hz = 3686400, /* Run SSP as fast a possbile */ - .bus_num = 2, /* Framework bus number */ - .chip_select = 0, /* Framework chip select */ - .platform_data = NULL; /* No spi_driver specific config */ - .controller_data = &cs8415a_chip_info, /* Master chip config */ - .irq = STREETRACER_APCI_IRQ, /* Slave device interrupt */ - }, - { - .modalias = "cs8405a", /* Name of spi_driver for this device */ - .max_speed_hz = 3686400, /* Run SSP as fast a possbile */ - .bus_num = 2, /* Framework bus number */ - .chip_select = 1, /* Framework chip select */ - .controller_data = &cs8405a_chip_info, /* Master chip config */ - .irq = STREETRACER_APCI_IRQ, /* Slave device interrupt */ - }, -}; - -static void __init streetracer_init(void) -{ - spi_register_board_info(streetracer_spi_board_info, - ARRAY_SIZE(streetracer_spi_board_info)); -} - - -DMA and PIO I/O Support ------------------------ -The pxa2xx_spi driver supports both DMA and interrupt driven PIO message -transfers. The driver defaults to PIO mode and DMA transfers must be enabled -by setting the "enable_dma" flag in the "pxa2xx_spi_controller" structure. The DMA -mode supports both coherent and stream based DMA mappings. - -The following logic is used to determine the type of I/O to be used on -a per "spi_transfer" basis: - -if !enable_dma then - always use PIO transfers - -if spi_message.len > 8191 then - print "rate limited" warning - use PIO transfers - -if spi_message.is_dma_mapped and rx_dma_buf != 0 and tx_dma_buf != 0 then - use coherent DMA mode - -if rx_buf and tx_buf are aligned on 8 byte boundary then - use streaming DMA mode - -otherwise - use PIO transfer - -THANKS TO ---------- - -David Brownell and others for mentoring the development of this driver. - diff --git a/Documentation/spi/pxa2xx.rst b/Documentation/spi/pxa2xx.rst new file mode 100644 index 000000000000..882d3cc72cc2 --- /dev/null +++ b/Documentation/spi/pxa2xx.rst @@ -0,0 +1,240 @@ +============================== +PXA2xx SPI on SSP driver HOWTO +============================== + +This a mini howto on the pxa2xx_spi driver. The driver turns a PXA2xx +synchronous serial port into a SPI master controller +(see Documentation/spi/spi-summary.rst). The driver has the following features + +- Support for any PXA2xx SSP +- SSP PIO and SSP DMA data transfers. +- External and Internal (SSPFRM) chip selects. +- Per slave device (chip) configuration. +- Full suspend, freeze, resume support. + +The driver is built around a "spi_message" fifo serviced by workqueue and a +tasklet. The workqueue, "pump_messages", drives message fifo and the tasklet +(pump_transfer) is responsible for queuing SPI transactions and setting up and +launching the dma/interrupt driven transfers. + +Declaring PXA2xx Master Controllers +----------------------------------- +Typically a SPI master is defined in the arch/.../mach-*/board-*.c as a +"platform device". The master configuration is passed to the driver via a table +found in include/linux/spi/pxa2xx_spi.h:: + + struct pxa2xx_spi_controller { + u16 num_chipselect; + u8 enable_dma; + }; + +The "pxa2xx_spi_controller.num_chipselect" field is used to determine the number of +slave device (chips) attached to this SPI master. + +The "pxa2xx_spi_controller.enable_dma" field informs the driver that SSP DMA should +be used. This caused the driver to acquire two DMA channels: rx_channel and +tx_channel. The rx_channel has a higher DMA service priority the tx_channel. +See the "PXA2xx Developer Manual" section "DMA Controller". + +NSSP MASTER SAMPLE +------------------ +Below is a sample configuration using the PXA255 NSSP:: + + static struct resource pxa_spi_nssp_resources[] = { + [0] = { + .start = __PREG(SSCR0_P(2)), /* Start address of NSSP */ + .end = __PREG(SSCR0_P(2)) + 0x2c, /* Range of registers */ + .flags = IORESOURCE_MEM, + }, + [1] = { + .start = IRQ_NSSP, /* NSSP IRQ */ + .end = IRQ_NSSP, + .flags = IORESOURCE_IRQ, + }, + }; + + static struct pxa2xx_spi_controller pxa_nssp_master_info = { + .num_chipselect = 1, /* Matches the number of chips attached to NSSP */ + .enable_dma = 1, /* Enables NSSP DMA */ + }; + + static struct platform_device pxa_spi_nssp = { + .name = "pxa2xx-spi", /* MUST BE THIS VALUE, so device match driver */ + .id = 2, /* Bus number, MUST MATCH SSP number 1..n */ + .resource = pxa_spi_nssp_resources, + .num_resources = ARRAY_SIZE(pxa_spi_nssp_resources), + .dev = { + .platform_data = &pxa_nssp_master_info, /* Passed to driver */ + }, + }; + + static struct platform_device *devices[] __initdata = { + &pxa_spi_nssp, + }; + + static void __init board_init(void) + { + (void)platform_add_device(devices, ARRAY_SIZE(devices)); + } + +Declaring Slave Devices +----------------------- +Typically each SPI slave (chip) is defined in the arch/.../mach-*/board-*.c +using the "spi_board_info" structure found in "linux/spi/spi.h". See +"Documentation/spi/spi-summary.rst" for additional information. + +Each slave device attached to the PXA must provide slave specific configuration +information via the structure "pxa2xx_spi_chip" found in +"include/linux/spi/pxa2xx_spi.h". The pxa2xx_spi master controller driver +will uses the configuration whenever the driver communicates with the slave +device. All fields are optional. + +:: + + struct pxa2xx_spi_chip { + u8 tx_threshold; + u8 rx_threshold; + u8 dma_burst_size; + u32 timeout; + u8 enable_loopback; + void (*cs_control)(u32 command); + }; + +The "pxa2xx_spi_chip.tx_threshold" and "pxa2xx_spi_chip.rx_threshold" fields are +used to configure the SSP hardware fifo. These fields are critical to the +performance of pxa2xx_spi driver and misconfiguration will result in rx +fifo overruns (especially in PIO mode transfers). Good default values are:: + + .tx_threshold = 8, + .rx_threshold = 8, + +The range is 1 to 16 where zero indicates "use default". + +The "pxa2xx_spi_chip.dma_burst_size" field is used to configure PXA2xx DMA +engine and is related the "spi_device.bits_per_word" field. Read and understand +the PXA2xx "Developer Manual" sections on the DMA controller and SSP Controllers +to determine the correct value. An SSP configured for byte-wide transfers would +use a value of 8. The driver will determine a reasonable default if +dma_burst_size == 0. + +The "pxa2xx_spi_chip.timeout" fields is used to efficiently handle +trailing bytes in the SSP receiver fifo. The correct value for this field is +dependent on the SPI bus speed ("spi_board_info.max_speed_hz") and the specific +slave device. Please note that the PXA2xx SSP 1 does not support trailing byte +timeouts and must busy-wait any trailing bytes. + +The "pxa2xx_spi_chip.enable_loopback" field is used to place the SSP porting +into internal loopback mode. In this mode the SSP controller internally +connects the SSPTX pin to the SSPRX pin. This is useful for initial setup +testing. + +The "pxa2xx_spi_chip.cs_control" field is used to point to a board specific +function for asserting/deasserting a slave device chip select. If the field is +NULL, the pxa2xx_spi master controller driver assumes that the SSP port is +configured to use SSPFRM instead. + +NOTE: the SPI driver cannot control the chip select if SSPFRM is used, so the +chipselect is dropped after each spi_transfer. Most devices need chip select +asserted around the complete message. Use SSPFRM as a GPIO (through cs_control) +to accommodate these chips. + + +NSSP SLAVE SAMPLE +----------------- +The pxa2xx_spi_chip structure is passed to the pxa2xx_spi driver in the +"spi_board_info.controller_data" field. Below is a sample configuration using +the PXA255 NSSP. + +:: + + /* Chip Select control for the CS8415A SPI slave device */ + static void cs8415a_cs_control(u32 command) + { + if (command & PXA2XX_CS_ASSERT) + GPCR(2) = GPIO_bit(2); + else + GPSR(2) = GPIO_bit(2); + } + + /* Chip Select control for the CS8405A SPI slave device */ + static void cs8405a_cs_control(u32 command) + { + if (command & PXA2XX_CS_ASSERT) + GPCR(3) = GPIO_bit(3); + else + GPSR(3) = GPIO_bit(3); + } + + static struct pxa2xx_spi_chip cs8415a_chip_info = { + .tx_threshold = 8, /* SSP hardward FIFO threshold */ + .rx_threshold = 8, /* SSP hardward FIFO threshold */ + .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */ + .timeout = 235, /* See Intel documentation */ + .cs_control = cs8415a_cs_control, /* Use external chip select */ + }; + + static struct pxa2xx_spi_chip cs8405a_chip_info = { + .tx_threshold = 8, /* SSP hardward FIFO threshold */ + .rx_threshold = 8, /* SSP hardward FIFO threshold */ + .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */ + .timeout = 235, /* See Intel documentation */ + .cs_control = cs8405a_cs_control, /* Use external chip select */ + }; + + static struct spi_board_info streetracer_spi_board_info[] __initdata = { + { + .modalias = "cs8415a", /* Name of spi_driver for this device */ + .max_speed_hz = 3686400, /* Run SSP as fast a possbile */ + .bus_num = 2, /* Framework bus number */ + .chip_select = 0, /* Framework chip select */ + .platform_data = NULL; /* No spi_driver specific config */ + .controller_data = &cs8415a_chip_info, /* Master chip config */ + .irq = STREETRACER_APCI_IRQ, /* Slave device interrupt */ + }, + { + .modalias = "cs8405a", /* Name of spi_driver for this device */ + .max_speed_hz = 3686400, /* Run SSP as fast a possbile */ + .bus_num = 2, /* Framework bus number */ + .chip_select = 1, /* Framework chip select */ + .controller_data = &cs8405a_chip_info, /* Master chip config */ + .irq = STREETRACER_APCI_IRQ, /* Slave device interrupt */ + }, + }; + + static void __init streetracer_init(void) + { + spi_register_board_info(streetracer_spi_board_info, + ARRAY_SIZE(streetracer_spi_board_info)); + } + + +DMA and PIO I/O Support +----------------------- +The pxa2xx_spi driver supports both DMA and interrupt driven PIO message +transfers. The driver defaults to PIO mode and DMA transfers must be enabled +by setting the "enable_dma" flag in the "pxa2xx_spi_controller" structure. The DMA +mode supports both coherent and stream based DMA mappings. + +The following logic is used to determine the type of I/O to be used on +a per "spi_transfer" basis:: + + if !enable_dma then + always use PIO transfers + + if spi_message.len > 8191 then + print "rate limited" warning + use PIO transfers + + if spi_message.is_dma_mapped and rx_dma_buf != 0 and tx_dma_buf != 0 then + use coherent DMA mode + + if rx_buf and tx_buf are aligned on 8 byte boundary then + use streaming DMA mode + + otherwise + use PIO transfer + +THANKS TO +--------- + +David Brownell and others for mentoring the development of this driver. diff --git a/Documentation/spi/spi-lm70llp b/Documentation/spi/spi-lm70llp deleted file mode 100644 index 463f6d01fa15..000000000000 --- a/Documentation/spi/spi-lm70llp +++ /dev/null @@ -1,79 +0,0 @@ -spi_lm70llp : LM70-LLP parport-to-SPI adapter -============================================== - -Supported board/chip: - * National Semiconductor LM70 LLP evaluation board - Datasheet: http://www.national.com/pf/LM/LM70.html - -Author: - Kaiwan N Billimoria - -Description ------------ -This driver provides glue code connecting a National Semiconductor LM70 LLP -temperature sensor evaluation board to the kernel's SPI core subsystem. - -This is a SPI master controller driver. It can be used in conjunction with -(layered under) the LM70 logical driver (a "SPI protocol driver"). -In effect, this driver turns the parallel port interface on the eval board -into a SPI bus with a single device, which will be driven by the generic -LM70 driver (drivers/hwmon/lm70.c). - - -Hardware Interfacing --------------------- -The schematic for this particular board (the LM70EVAL-LLP) is -available (on page 4) here: - - http://www.national.com/appinfo/tempsensors/files/LM70LLPEVALmanual.pdf - -The hardware interfacing on the LM70 LLP eval board is as follows: - - Parallel LM70 LLP - Port Direction JP2 Header - ----------- --------- ---------------- - D0 2 - - - D1 3 --> V+ 5 - D2 4 --> V+ 5 - D3 5 --> V+ 5 - D4 6 --> V+ 5 - D5 7 --> nCS 8 - D6 8 --> SCLK 3 - D7 9 --> SI/O 5 - GND 25 - GND 7 - Select 13 <-- SI/O 1 - ----------- --------- ---------------- - -Note that since the LM70 uses a "3-wire" variant of SPI, the SI/SO pin -is connected to both pin D7 (as Master Out) and Select (as Master In) -using an arrangement that lets either the parport or the LM70 pull the -pin low. This can't be shared with true SPI devices, but other 3-wire -devices might share the same SI/SO pin. - -The bitbanger routine in this driver (lm70_txrx) is called back from -the bound "hwmon/lm70" protocol driver through its sysfs hook, using a -spi_write_then_read() call. It performs Mode 0 (SPI/Microwire) bitbanging. -The lm70 driver then inteprets the resulting digital temperature value -and exports it through sysfs. - -A "gotcha": National Semiconductor's LM70 LLP eval board circuit schematic -shows that the SI/O line from the LM70 chip is connected to the base of a -transistor Q1 (and also a pullup, and a zener diode to D7); while the -collector is tied to VCC. - -Interpreting this circuit, when the LM70 SI/O line is High (or tristate -and not grounded by the host via D7), the transistor conducts and switches -the collector to zero, which is reflected on pin 13 of the DB25 parport -connector. When SI/O is Low (driven by the LM70 or the host) on the other -hand, the transistor is cut off and the voltage tied to it's collector is -reflected on pin 13 as a High level. - -So: the getmiso inline routine in this driver takes this fact into account, -inverting the value read at pin 13. - - -Thanks to ---------- -o David Brownell for mentoring the SPI-side driver development. -o Dr.Craig Hollabaugh for the (early) "manual" bitbanging driver version. -o Nadir Billimoria for help interpreting the circuit schematic. diff --git a/Documentation/spi/spi-lm70llp.rst b/Documentation/spi/spi-lm70llp.rst new file mode 100644 index 000000000000..07631aef4343 --- /dev/null +++ b/Documentation/spi/spi-lm70llp.rst @@ -0,0 +1,84 @@ +============================================== +spi_lm70llp : LM70-LLP parport-to-SPI adapter +============================================== + +Supported board/chip: + + * National Semiconductor LM70 LLP evaluation board + + Datasheet: http://www.national.com/pf/LM/LM70.html + +Author: + Kaiwan N Billimoria + +Description +----------- +This driver provides glue code connecting a National Semiconductor LM70 LLP +temperature sensor evaluation board to the kernel's SPI core subsystem. + +This is a SPI master controller driver. It can be used in conjunction with +(layered under) the LM70 logical driver (a "SPI protocol driver"). +In effect, this driver turns the parallel port interface on the eval board +into a SPI bus with a single device, which will be driven by the generic +LM70 driver (drivers/hwmon/lm70.c). + + +Hardware Interfacing +-------------------- +The schematic for this particular board (the LM70EVAL-LLP) is +available (on page 4) here: + + http://www.national.com/appinfo/tempsensors/files/LM70LLPEVALmanual.pdf + +The hardware interfacing on the LM70 LLP eval board is as follows: + + ======== == ========= ========== + Parallel LM70 LLP + Port . Direction JP2 Header + ======== == ========= ========== + D0 2 - - + D1 3 --> V+ 5 + D2 4 --> V+ 5 + D3 5 --> V+ 5 + D4 6 --> V+ 5 + D5 7 --> nCS 8 + D6 8 --> SCLK 3 + D7 9 --> SI/O 5 + GND 25 - GND 7 + Select 13 <-- SI/O 1 + ======== == ========= ========== + +Note that since the LM70 uses a "3-wire" variant of SPI, the SI/SO pin +is connected to both pin D7 (as Master Out) and Select (as Master In) +using an arrangement that lets either the parport or the LM70 pull the +pin low. This can't be shared with true SPI devices, but other 3-wire +devices might share the same SI/SO pin. + +The bitbanger routine in this driver (lm70_txrx) is called back from +the bound "hwmon/lm70" protocol driver through its sysfs hook, using a +spi_write_then_read() call. It performs Mode 0 (SPI/Microwire) bitbanging. +The lm70 driver then inteprets the resulting digital temperature value +and exports it through sysfs. + +A "gotcha": National Semiconductor's LM70 LLP eval board circuit schematic +shows that the SI/O line from the LM70 chip is connected to the base of a +transistor Q1 (and also a pullup, and a zener diode to D7); while the +collector is tied to VCC. + +Interpreting this circuit, when the LM70 SI/O line is High (or tristate +and not grounded by the host via D7), the transistor conducts and switches +the collector to zero, which is reflected on pin 13 of the DB25 parport +connector. When SI/O is Low (driven by the LM70 or the host) on the other +hand, the transistor is cut off and the voltage tied to it's collector is +reflected on pin 13 as a High level. + +So: the getmiso inline routine in this driver takes this fact into account, +inverting the value read at pin 13. + + +Thanks to +--------- + +- David Brownell for mentoring the SPI-side driver development. +- Dr.Craig Hollabaugh for the (early) "manual" bitbanging driver version. +- Nadir Billimoria for help interpreting the circuit schematic. diff --git a/Documentation/spi/spi-sc18is602 b/Documentation/spi/spi-sc18is602 deleted file mode 100644 index a45702865a38..000000000000 --- a/Documentation/spi/spi-sc18is602 +++ /dev/null @@ -1,36 +0,0 @@ -Kernel driver spi-sc18is602 -=========================== - -Supported chips: - * NXP SI18IS602/602B/603 - Datasheet: http://www.nxp.com/documents/data_sheet/SC18IS602_602B_603.pdf - -Author: - Guenter Roeck - - -Description ------------ - -This driver provides connects a NXP SC18IS602/603 I2C-bus to SPI bridge to the -kernel's SPI core subsystem. - -The driver does not probe for supported chips, since the SI18IS602/603 does not -support Chip ID registers. You will have to instantiate the devices explicitly. -Please see Documentation/i2c/instantiating-devices for details. - - -Usage Notes ------------ - -This driver requires the I2C adapter driver to support raw I2C messages. I2C -adapter drivers which can only handle the SMBus protocol are not supported. - -The maximum SPI message size supported by SC18IS602/603 is 200 bytes. Attempts -to initiate longer transfers will fail with -EINVAL. EEPROM read operations and -similar large accesses have to be split into multiple chunks of no more than -200 bytes per SPI message (128 bytes of data per message is recommended). This -means that programs such as "cp" or "od", which automatically use large block -sizes to access a device, can not be used directly to read data from EEPROM. -Programs such as dd, where the block size can be specified, should be used -instead. diff --git a/Documentation/spi/spi-sc18is602.rst b/Documentation/spi/spi-sc18is602.rst new file mode 100644 index 000000000000..2a31dc722321 --- /dev/null +++ b/Documentation/spi/spi-sc18is602.rst @@ -0,0 +1,39 @@ +=========================== +Kernel driver spi-sc18is602 +=========================== + +Supported chips: + + * NXP SI18IS602/602B/603 + + Datasheet: http://www.nxp.com/documents/data_sheet/SC18IS602_602B_603.pdf + +Author: + Guenter Roeck + + +Description +----------- + +This driver provides connects a NXP SC18IS602/603 I2C-bus to SPI bridge to the +kernel's SPI core subsystem. + +The driver does not probe for supported chips, since the SI18IS602/603 does not +support Chip ID registers. You will have to instantiate the devices explicitly. +Please see Documentation/i2c/instantiating-devices.rst for details. + + +Usage Notes +----------- + +This driver requires the I2C adapter driver to support raw I2C messages. I2C +adapter drivers which can only handle the SMBus protocol are not supported. + +The maximum SPI message size supported by SC18IS602/603 is 200 bytes. Attempts +to initiate longer transfers will fail with -EINVAL. EEPROM read operations and +similar large accesses have to be split into multiple chunks of no more than +200 bytes per SPI message (128 bytes of data per message is recommended). This +means that programs such as "cp" or "od", which automatically use large block +sizes to access a device, can not be used directly to read data from EEPROM. +Programs such as dd, where the block size can be specified, should be used +instead. diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary deleted file mode 100644 index 1a63194b74d7..000000000000 --- a/Documentation/spi/spi-summary +++ /dev/null @@ -1,631 +0,0 @@ -Overview of Linux kernel SPI support -==================================== - -02-Feb-2012 - -What is SPI? ------------- -The "Serial Peripheral Interface" (SPI) is a synchronous four wire serial -link used to connect microcontrollers to sensors, memory, and peripherals. -It's a simple "de facto" standard, not complicated enough to acquire a -standardization body. SPI uses a master/slave configuration. - -The three signal wires hold a clock (SCK, often on the order of 10 MHz), -and parallel data lines with "Master Out, Slave In" (MOSI) or "Master In, -Slave Out" (MISO) signals. (Other names are also used.) There are four -clocking modes through which data is exchanged; mode-0 and mode-3 are most -commonly used. Each clock cycle shifts data out and data in; the clock -doesn't cycle except when there is a data bit to shift. Not all data bits -are used though; not every protocol uses those full duplex capabilities. - -SPI masters use a fourth "chip select" line to activate a given SPI slave -device, so those three signal wires may be connected to several chips -in parallel. All SPI slaves support chipselects; they are usually active -low signals, labeled nCSx for slave 'x' (e.g. nCS0). Some devices have -other signals, often including an interrupt to the master. - -Unlike serial busses like USB or SMBus, even low level protocols for -SPI slave functions are usually not interoperable between vendors -(except for commodities like SPI memory chips). - - - SPI may be used for request/response style device protocols, as with - touchscreen sensors and memory chips. - - - It may also be used to stream data in either direction (half duplex), - or both of them at the same time (full duplex). - - - Some devices may use eight bit words. Others may use different word - lengths, such as streams of 12-bit or 20-bit digital samples. - - - Words are usually sent with their most significant bit (MSB) first, - but sometimes the least significant bit (LSB) goes first instead. - - - Sometimes SPI is used to daisy-chain devices, like shift registers. - -In the same way, SPI slaves will only rarely support any kind of automatic -discovery/enumeration protocol. The tree of slave devices accessible from -a given SPI master will normally be set up manually, with configuration -tables. - -SPI is only one of the names used by such four-wire protocols, and -most controllers have no problem handling "MicroWire" (think of it as -half-duplex SPI, for request/response protocols), SSP ("Synchronous -Serial Protocol"), PSP ("Programmable Serial Protocol"), and other -related protocols. - -Some chips eliminate a signal line by combining MOSI and MISO, and -limiting themselves to half-duplex at the hardware level. In fact -some SPI chips have this signal mode as a strapping option. These -can be accessed using the same programming interface as SPI, but of -course they won't handle full duplex transfers. You may find such -chips described as using "three wire" signaling: SCK, data, nCSx. -(That data line is sometimes called MOMI or SISO.) - -Microcontrollers often support both master and slave sides of the SPI -protocol. This document (and Linux) supports both the master and slave -sides of SPI interactions. - - -Who uses it? On what kinds of systems? ---------------------------------------- -Linux developers using SPI are probably writing device drivers for embedded -systems boards. SPI is used to control external chips, and it is also a -protocol supported by every MMC or SD memory card. (The older "DataFlash" -cards, predating MMC cards but using the same connectors and card shape, -support only SPI.) Some PC hardware uses SPI flash for BIOS code. - -SPI slave chips range from digital/analog converters used for analog -sensors and codecs, to memory, to peripherals like USB controllers -or Ethernet adapters; and more. - -Most systems using SPI will integrate a few devices on a mainboard. -Some provide SPI links on expansion connectors; in cases where no -dedicated SPI controller exists, GPIO pins can be used to create a -low speed "bitbanging" adapter. Very few systems will "hotplug" an SPI -controller; the reasons to use SPI focus on low cost and simple operation, -and if dynamic reconfiguration is important, USB will often be a more -appropriate low-pincount peripheral bus. - -Many microcontrollers that can run Linux integrate one or more I/O -interfaces with SPI modes. Given SPI support, they could use MMC or SD -cards without needing a special purpose MMC/SD/SDIO controller. - - -I'm confused. What are these four SPI "clock modes"? ------------------------------------------------------ -It's easy to be confused here, and the vendor documentation you'll -find isn't necessarily helpful. The four modes combine two mode bits: - - - CPOL indicates the initial clock polarity. CPOL=0 means the - clock starts low, so the first (leading) edge is rising, and - the second (trailing) edge is falling. CPOL=1 means the clock - starts high, so the first (leading) edge is falling. - - - CPHA indicates the clock phase used to sample data; CPHA=0 says - sample on the leading edge, CPHA=1 means the trailing edge. - - Since the signal needs to stablize before it's sampled, CPHA=0 - implies that its data is written half a clock before the first - clock edge. The chipselect may have made it become available. - -Chip specs won't always say "uses SPI mode X" in as many words, -but their timing diagrams will make the CPOL and CPHA modes clear. - -In the SPI mode number, CPOL is the high order bit and CPHA is the -low order bit. So when a chip's timing diagram shows the clock -starting low (CPOL=0) and data stabilized for sampling during the -trailing clock edge (CPHA=1), that's SPI mode 1. - -Note that the clock mode is relevant as soon as the chipselect goes -active. So the master must set the clock to inactive before selecting -a slave, and the slave can tell the chosen polarity by sampling the -clock level when its select line goes active. That's why many devices -support for example both modes 0 and 3: they don't care about polarity, -and always clock data in/out on rising clock edges. - - -How do these driver programming interfaces work? ------------------------------------------------- -The header file includes kerneldoc, as does the -main source code, and you should certainly read that chapter of the -kernel API document. This is just an overview, so you get the big -picture before those details. - -SPI requests always go into I/O queues. Requests for a given SPI device -are always executed in FIFO order, and complete asynchronously through -completion callbacks. There are also some simple synchronous wrappers -for those calls, including ones for common transaction types like writing -a command and then reading its response. - -There are two types of SPI driver, here called: - - Controller drivers ... controllers may be built into System-On-Chip - processors, and often support both Master and Slave roles. - These drivers touch hardware registers and may use DMA. - Or they can be PIO bitbangers, needing just GPIO pins. - - Protocol drivers ... these pass messages through the controller - driver to communicate with a Slave or Master device on the - other side of an SPI link. - -So for example one protocol driver might talk to the MTD layer to export -data to filesystems stored on SPI flash like DataFlash; and others might -control audio interfaces, present touchscreen sensors as input interfaces, -or monitor temperature and voltage levels during industrial processing. -And those might all be sharing the same controller driver. - -A "struct spi_device" encapsulates the controller-side interface between -those two types of drivers. - -There is a minimal core of SPI programming interfaces, focussing on -using the driver model to connect controller and protocol drivers using -device tables provided by board specific initialization code. SPI -shows up in sysfs in several locations: - - /sys/devices/.../CTLR ... physical node for a given SPI controller - - /sys/devices/.../CTLR/spiB.C ... spi_device on bus "B", - chipselect C, accessed through CTLR. - - /sys/bus/spi/devices/spiB.C ... symlink to that physical - .../CTLR/spiB.C device - - /sys/devices/.../CTLR/spiB.C/modalias ... identifies the driver - that should be used with this device (for hotplug/coldplug) - - /sys/bus/spi/drivers/D ... driver for one or more spi*.* devices - - /sys/class/spi_master/spiB ... symlink (or actual device node) to - a logical node which could hold class related state for the SPI - master controller managing bus "B". All spiB.* devices share one - physical SPI bus segment, with SCLK, MOSI, and MISO. - - /sys/devices/.../CTLR/slave ... virtual file for (un)registering the - slave device for an SPI slave controller. - Writing the driver name of an SPI slave handler to this file - registers the slave device; writing "(null)" unregisters the slave - device. - Reading from this file shows the name of the slave device ("(null)" - if not registered). - - /sys/class/spi_slave/spiB ... symlink (or actual device node) to - a logical node which could hold class related state for the SPI - slave controller on bus "B". When registered, a single spiB.* - device is present here, possible sharing the physical SPI bus - segment with other SPI slave devices. - -Note that the actual location of the controller's class state depends -on whether you enabled CONFIG_SYSFS_DEPRECATED or not. At this time, -the only class-specific state is the bus number ("B" in "spiB"), so -those /sys/class entries are only useful to quickly identify busses. - - -How does board-specific init code declare SPI devices? ------------------------------------------------------- -Linux needs several kinds of information to properly configure SPI devices. -That information is normally provided by board-specific code, even for -chips that do support some of automated discovery/enumeration. - -DECLARE CONTROLLERS - -The first kind of information is a list of what SPI controllers exist. -For System-on-Chip (SOC) based boards, these will usually be platform -devices, and the controller may need some platform_data in order to -operate properly. The "struct platform_device" will include resources -like the physical address of the controller's first register and its IRQ. - -Platforms will often abstract the "register SPI controller" operation, -maybe coupling it with code to initialize pin configurations, so that -the arch/.../mach-*/board-*.c files for several boards can all share the -same basic controller setup code. This is because most SOCs have several -SPI-capable controllers, and only the ones actually usable on a given -board should normally be set up and registered. - -So for example arch/.../mach-*/board-*.c files might have code like: - - #include /* for mysoc_spi_data */ - - /* if your mach-* infrastructure doesn't support kernels that can - * run on multiple boards, pdata wouldn't benefit from "__init". - */ - static struct mysoc_spi_data pdata __initdata = { ... }; - - static __init board_init(void) - { - ... - /* this board only uses SPI controller #2 */ - mysoc_register_spi(2, &pdata); - ... - } - -And SOC-specific utility code might look something like: - - #include - - static struct platform_device spi2 = { ... }; - - void mysoc_register_spi(unsigned n, struct mysoc_spi_data *pdata) - { - struct mysoc_spi_data *pdata2; - - pdata2 = kmalloc(sizeof *pdata2, GFP_KERNEL); - *pdata2 = pdata; - ... - if (n == 2) { - spi2->dev.platform_data = pdata2; - register_platform_device(&spi2); - - /* also: set up pin modes so the spi2 signals are - * visible on the relevant pins ... bootloaders on - * production boards may already have done this, but - * developer boards will often need Linux to do it. - */ - } - ... - } - -Notice how the platform_data for boards may be different, even if the -same SOC controller is used. For example, on one board SPI might use -an external clock, where another derives the SPI clock from current -settings of some master clock. - - -DECLARE SLAVE DEVICES - -The second kind of information is a list of what SPI slave devices exist -on the target board, often with some board-specific data needed for the -driver to work correctly. - -Normally your arch/.../mach-*/board-*.c files would provide a small table -listing the SPI devices on each board. (This would typically be only a -small handful.) That might look like: - - static struct ads7846_platform_data ads_info = { - .vref_delay_usecs = 100, - .x_plate_ohms = 580, - .y_plate_ohms = 410, - }; - - static struct spi_board_info spi_board_info[] __initdata = { - { - .modalias = "ads7846", - .platform_data = &ads_info, - .mode = SPI_MODE_0, - .irq = GPIO_IRQ(31), - .max_speed_hz = 120000 /* max sample rate at 3V */ * 16, - .bus_num = 1, - .chip_select = 0, - }, - }; - -Again, notice how board-specific information is provided; each chip may need -several types. This example shows generic constraints like the fastest SPI -clock to allow (a function of board voltage in this case) or how an IRQ pin -is wired, plus chip-specific constraints like an important delay that's -changed by the capacitance at one pin. - -(There's also "controller_data", information that may be useful to the -controller driver. An example would be peripheral-specific DMA tuning -data or chipselect callbacks. This is stored in spi_device later.) - -The board_info should provide enough information to let the system work -without the chip's driver being loaded. The most troublesome aspect of -that is likely the SPI_CS_HIGH bit in the spi_device.mode field, since -sharing a bus with a device that interprets chipselect "backwards" is -not possible until the infrastructure knows how to deselect it. - -Then your board initialization code would register that table with the SPI -infrastructure, so that it's available later when the SPI master controller -driver is registered: - - spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info)); - -Like with other static board-specific setup, you won't unregister those. - -The widely used "card" style computers bundle memory, cpu, and little else -onto a card that's maybe just thirty square centimeters. On such systems, -your arch/.../mach-.../board-*.c file would primarily provide information -about the devices on the mainboard into which such a card is plugged. That -certainly includes SPI devices hooked up through the card connectors! - - -NON-STATIC CONFIGURATIONS - -Developer boards often play by different rules than product boards, and one -example is the potential need to hotplug SPI devices and/or controllers. - -For those cases you might need to use spi_busnum_to_master() to look -up the spi bus master, and will likely need spi_new_device() to provide the -board info based on the board that was hotplugged. Of course, you'd later -call at least spi_unregister_device() when that board is removed. - -When Linux includes support for MMC/SD/SDIO/DataFlash cards through SPI, those -configurations will also be dynamic. Fortunately, such devices all support -basic device identification probes, so they should hotplug normally. - - -How do I write an "SPI Protocol Driver"? ----------------------------------------- -Most SPI drivers are currently kernel drivers, but there's also support -for userspace drivers. Here we talk only about kernel drivers. - -SPI protocol drivers somewhat resemble platform device drivers: - - static struct spi_driver CHIP_driver = { - .driver = { - .name = "CHIP", - .owner = THIS_MODULE, - .pm = &CHIP_pm_ops, - }, - - .probe = CHIP_probe, - .remove = CHIP_remove, - }; - -The driver core will automatically attempt to bind this driver to any SPI -device whose board_info gave a modalias of "CHIP". Your probe() code -might look like this unless you're creating a device which is managing -a bus (appearing under /sys/class/spi_master). - - static int CHIP_probe(struct spi_device *spi) - { - struct CHIP *chip; - struct CHIP_platform_data *pdata; - - /* assuming the driver requires board-specific data: */ - pdata = &spi->dev.platform_data; - if (!pdata) - return -ENODEV; - - /* get memory for driver's per-chip state */ - chip = kzalloc(sizeof *chip, GFP_KERNEL); - if (!chip) - return -ENOMEM; - spi_set_drvdata(spi, chip); - - ... etc - return 0; - } - -As soon as it enters probe(), the driver may issue I/O requests to -the SPI device using "struct spi_message". When remove() returns, -or after probe() fails, the driver guarantees that it won't submit -any more such messages. - - - An spi_message is a sequence of protocol operations, executed - as one atomic sequence. SPI driver controls include: - - + when bidirectional reads and writes start ... by how its - sequence of spi_transfer requests is arranged; - - + which I/O buffers are used ... each spi_transfer wraps a - buffer for each transfer direction, supporting full duplex - (two pointers, maybe the same one in both cases) and half - duplex (one pointer is NULL) transfers; - - + optionally defining short delays after transfers ... using - the spi_transfer.delay_usecs setting (this delay can be the - only protocol effect, if the buffer length is zero); - - + whether the chipselect becomes inactive after a transfer and - any delay ... by using the spi_transfer.cs_change flag; - - + hinting whether the next message is likely to go to this same - device ... using the spi_transfer.cs_change flag on the last - transfer in that atomic group, and potentially saving costs - for chip deselect and select operations. - - - Follow standard kernel rules, and provide DMA-safe buffers in - your messages. That way controller drivers using DMA aren't forced - to make extra copies unless the hardware requires it (e.g. working - around hardware errata that force the use of bounce buffering). - - If standard dma_map_single() handling of these buffers is inappropriate, - you can use spi_message.is_dma_mapped to tell the controller driver - that you've already provided the relevant DMA addresses. - - - The basic I/O primitive is spi_async(). Async requests may be - issued in any context (irq handler, task, etc) and completion - is reported using a callback provided with the message. - After any detected error, the chip is deselected and processing - of that spi_message is aborted. - - - There are also synchronous wrappers like spi_sync(), and wrappers - like spi_read(), spi_write(), and spi_write_then_read(). These - may be issued only in contexts that may sleep, and they're all - clean (and small, and "optional") layers over spi_async(). - - - The spi_write_then_read() call, and convenience wrappers around - it, should only be used with small amounts of data where the - cost of an extra copy may be ignored. It's designed to support - common RPC-style requests, such as writing an eight bit command - and reading a sixteen bit response -- spi_w8r16() being one its - wrappers, doing exactly that. - -Some drivers may need to modify spi_device characteristics like the -transfer mode, wordsize, or clock rate. This is done with spi_setup(), -which would normally be called from probe() before the first I/O is -done to the device. However, that can also be called at any time -that no message is pending for that device. - -While "spi_device" would be the bottom boundary of the driver, the -upper boundaries might include sysfs (especially for sensor readings), -the input layer, ALSA, networking, MTD, the character device framework, -or other Linux subsystems. - -Note that there are two types of memory your driver must manage as part -of interacting with SPI devices. - - - I/O buffers use the usual Linux rules, and must be DMA-safe. - You'd normally allocate them from the heap or free page pool. - Don't use the stack, or anything that's declared "static". - - - The spi_message and spi_transfer metadata used to glue those - I/O buffers into a group of protocol transactions. These can - be allocated anywhere it's convenient, including as part of - other allocate-once driver data structures. Zero-init these. - -If you like, spi_message_alloc() and spi_message_free() convenience -routines are available to allocate and zero-initialize an spi_message -with several transfers. - - -How do I write an "SPI Master Controller Driver"? -------------------------------------------------- -An SPI controller will probably be registered on the platform_bus; write -a driver to bind to the device, whichever bus is involved. - -The main task of this type of driver is to provide an "spi_master". -Use spi_alloc_master() to allocate the master, and spi_master_get_devdata() -to get the driver-private data allocated for that device. - - struct spi_master *master; - struct CONTROLLER *c; - - master = spi_alloc_master(dev, sizeof *c); - if (!master) - return -ENODEV; - - c = spi_master_get_devdata(master); - -The driver will initialize the fields of that spi_master, including the -bus number (maybe the same as the platform device ID) and three methods -used to interact with the SPI core and SPI protocol drivers. It will -also initialize its own internal state. (See below about bus numbering -and those methods.) - -After you initialize the spi_master, then use spi_register_master() to -publish it to the rest of the system. At that time, device nodes for the -controller and any predeclared spi devices will be made available, and -the driver model core will take care of binding them to drivers. - -If you need to remove your SPI controller driver, spi_unregister_master() -will reverse the effect of spi_register_master(). - - -BUS NUMBERING - -Bus numbering is important, since that's how Linux identifies a given -SPI bus (shared SCK, MOSI, MISO). Valid bus numbers start at zero. On -SOC systems, the bus numbers should match the numbers defined by the chip -manufacturer. For example, hardware controller SPI2 would be bus number 2, -and spi_board_info for devices connected to it would use that number. - -If you don't have such hardware-assigned bus number, and for some reason -you can't just assign them, then provide a negative bus number. That will -then be replaced by a dynamically assigned number. You'd then need to treat -this as a non-static configuration (see above). - - -SPI MASTER METHODS - - master->setup(struct spi_device *spi) - This sets up the device clock rate, SPI mode, and word sizes. - Drivers may change the defaults provided by board_info, and then - call spi_setup(spi) to invoke this routine. It may sleep. - - Unless each SPI slave has its own configuration registers, don't - change them right away ... otherwise drivers could corrupt I/O - that's in progress for other SPI devices. - - ** BUG ALERT: for some reason the first version of - ** many spi_master drivers seems to get this wrong. - ** When you code setup(), ASSUME that the controller - ** is actively processing transfers for another device. - - master->cleanup(struct spi_device *spi) - Your controller driver may use spi_device.controller_state to hold - state it dynamically associates with that device. If you do that, - be sure to provide the cleanup() method to free that state. - - master->prepare_transfer_hardware(struct spi_master *master) - This will be called by the queue mechanism to signal to the driver - that a message is coming in soon, so the subsystem requests the - driver to prepare the transfer hardware by issuing this call. - This may sleep. - - master->unprepare_transfer_hardware(struct spi_master *master) - This will be called by the queue mechanism to signal to the driver - that there are no more messages pending in the queue and it may - relax the hardware (e.g. by power management calls). This may sleep. - - master->transfer_one_message(struct spi_master *master, - struct spi_message *mesg) - The subsystem calls the driver to transfer a single message while - queuing transfers that arrive in the meantime. When the driver is - finished with this message, it must call - spi_finalize_current_message() so the subsystem can issue the next - message. This may sleep. - - master->transfer_one(struct spi_master *master, struct spi_device *spi, - struct spi_transfer *transfer) - The subsystem calls the driver to transfer a single transfer while - queuing transfers that arrive in the meantime. When the driver is - finished with this transfer, it must call - spi_finalize_current_transfer() so the subsystem can issue the next - transfer. This may sleep. Note: transfer_one and transfer_one_message - are mutually exclusive; when both are set, the generic subsystem does - not call your transfer_one callback. - - Return values: - negative errno: error - 0: transfer is finished - 1: transfer is still in progress - - master->set_cs_timing(struct spi_device *spi, u8 setup_clk_cycles, - u8 hold_clk_cycles, u8 inactive_clk_cycles) - This method allows SPI client drivers to request SPI master controller - for configuring device specific CS setup, hold and inactive timing - requirements. - - DEPRECATED METHODS - - master->transfer(struct spi_device *spi, struct spi_message *message) - This must not sleep. Its responsibility is to arrange that the - transfer happens and its complete() callback is issued. The two - will normally happen later, after other transfers complete, and - if the controller is idle it will need to be kickstarted. This - method is not used on queued controllers and must be NULL if - transfer_one_message() and (un)prepare_transfer_hardware() are - implemented. - - -SPI MESSAGE QUEUE - -If you are happy with the standard queueing mechanism provided by the -SPI subsystem, just implement the queued methods specified above. Using -the message queue has the upside of centralizing a lot of code and -providing pure process-context execution of methods. The message queue -can also be elevated to realtime priority on high-priority SPI traffic. - -Unless the queueing mechanism in the SPI subsystem is selected, the bulk -of the driver will be managing the I/O queue fed by the now deprecated -function transfer(). - -That queue could be purely conceptual. For example, a driver used only -for low-frequency sensor access might be fine using synchronous PIO. - -But the queue will probably be very real, using message->queue, PIO, -often DMA (especially if the root filesystem is in SPI flash), and -execution contexts like IRQ handlers, tasklets, or workqueues (such -as keventd). Your driver can be as fancy, or as simple, as you need. -Such a transfer() method would normally just add the message to a -queue, and then start some asynchronous transfer engine (unless it's -already running). - - -THANKS TO ---------- -Contributors to Linux-SPI discussions include (in alphabetical order, -by last name): - -Mark Brown -David Brownell -Russell King -Grant Likely -Dmitry Pervushin -Stephen Street -Mark Underwood -Andrew Victor -Linus Walleij -Vitaly Wool diff --git a/Documentation/spi/spi-summary.rst b/Documentation/spi/spi-summary.rst new file mode 100644 index 000000000000..f1daffe10d78 --- /dev/null +++ b/Documentation/spi/spi-summary.rst @@ -0,0 +1,644 @@ +==================================== +Overview of Linux kernel SPI support +==================================== + +02-Feb-2012 + +What is SPI? +------------ +The "Serial Peripheral Interface" (SPI) is a synchronous four wire serial +link used to connect microcontrollers to sensors, memory, and peripherals. +It's a simple "de facto" standard, not complicated enough to acquire a +standardization body. SPI uses a master/slave configuration. + +The three signal wires hold a clock (SCK, often on the order of 10 MHz), +and parallel data lines with "Master Out, Slave In" (MOSI) or "Master In, +Slave Out" (MISO) signals. (Other names are also used.) There are four +clocking modes through which data is exchanged; mode-0 and mode-3 are most +commonly used. Each clock cycle shifts data out and data in; the clock +doesn't cycle except when there is a data bit to shift. Not all data bits +are used though; not every protocol uses those full duplex capabilities. + +SPI masters use a fourth "chip select" line to activate a given SPI slave +device, so those three signal wires may be connected to several chips +in parallel. All SPI slaves support chipselects; they are usually active +low signals, labeled nCSx for slave 'x' (e.g. nCS0). Some devices have +other signals, often including an interrupt to the master. + +Unlike serial busses like USB or SMBus, even low level protocols for +SPI slave functions are usually not interoperable between vendors +(except for commodities like SPI memory chips). + + - SPI may be used for request/response style device protocols, as with + touchscreen sensors and memory chips. + + - It may also be used to stream data in either direction (half duplex), + or both of them at the same time (full duplex). + + - Some devices may use eight bit words. Others may use different word + lengths, such as streams of 12-bit or 20-bit digital samples. + + - Words are usually sent with their most significant bit (MSB) first, + but sometimes the least significant bit (LSB) goes first instead. + + - Sometimes SPI is used to daisy-chain devices, like shift registers. + +In the same way, SPI slaves will only rarely support any kind of automatic +discovery/enumeration protocol. The tree of slave devices accessible from +a given SPI master will normally be set up manually, with configuration +tables. + +SPI is only one of the names used by such four-wire protocols, and +most controllers have no problem handling "MicroWire" (think of it as +half-duplex SPI, for request/response protocols), SSP ("Synchronous +Serial Protocol"), PSP ("Programmable Serial Protocol"), and other +related protocols. + +Some chips eliminate a signal line by combining MOSI and MISO, and +limiting themselves to half-duplex at the hardware level. In fact +some SPI chips have this signal mode as a strapping option. These +can be accessed using the same programming interface as SPI, but of +course they won't handle full duplex transfers. You may find such +chips described as using "three wire" signaling: SCK, data, nCSx. +(That data line is sometimes called MOMI or SISO.) + +Microcontrollers often support both master and slave sides of the SPI +protocol. This document (and Linux) supports both the master and slave +sides of SPI interactions. + + +Who uses it? On what kinds of systems? +--------------------------------------- +Linux developers using SPI are probably writing device drivers for embedded +systems boards. SPI is used to control external chips, and it is also a +protocol supported by every MMC or SD memory card. (The older "DataFlash" +cards, predating MMC cards but using the same connectors and card shape, +support only SPI.) Some PC hardware uses SPI flash for BIOS code. + +SPI slave chips range from digital/analog converters used for analog +sensors and codecs, to memory, to peripherals like USB controllers +or Ethernet adapters; and more. + +Most systems using SPI will integrate a few devices on a mainboard. +Some provide SPI links on expansion connectors; in cases where no +dedicated SPI controller exists, GPIO pins can be used to create a +low speed "bitbanging" adapter. Very few systems will "hotplug" an SPI +controller; the reasons to use SPI focus on low cost and simple operation, +and if dynamic reconfiguration is important, USB will often be a more +appropriate low-pincount peripheral bus. + +Many microcontrollers that can run Linux integrate one or more I/O +interfaces with SPI modes. Given SPI support, they could use MMC or SD +cards without needing a special purpose MMC/SD/SDIO controller. + + +I'm confused. What are these four SPI "clock modes"? +----------------------------------------------------- +It's easy to be confused here, and the vendor documentation you'll +find isn't necessarily helpful. The four modes combine two mode bits: + + - CPOL indicates the initial clock polarity. CPOL=0 means the + clock starts low, so the first (leading) edge is rising, and + the second (trailing) edge is falling. CPOL=1 means the clock + starts high, so the first (leading) edge is falling. + + - CPHA indicates the clock phase used to sample data; CPHA=0 says + sample on the leading edge, CPHA=1 means the trailing edge. + + Since the signal needs to stablize before it's sampled, CPHA=0 + implies that its data is written half a clock before the first + clock edge. The chipselect may have made it become available. + +Chip specs won't always say "uses SPI mode X" in as many words, +but their timing diagrams will make the CPOL and CPHA modes clear. + +In the SPI mode number, CPOL is the high order bit and CPHA is the +low order bit. So when a chip's timing diagram shows the clock +starting low (CPOL=0) and data stabilized for sampling during the +trailing clock edge (CPHA=1), that's SPI mode 1. + +Note that the clock mode is relevant as soon as the chipselect goes +active. So the master must set the clock to inactive before selecting +a slave, and the slave can tell the chosen polarity by sampling the +clock level when its select line goes active. That's why many devices +support for example both modes 0 and 3: they don't care about polarity, +and always clock data in/out on rising clock edges. + + +How do these driver programming interfaces work? +------------------------------------------------ +The header file includes kerneldoc, as does the +main source code, and you should certainly read that chapter of the +kernel API document. This is just an overview, so you get the big +picture before those details. + +SPI requests always go into I/O queues. Requests for a given SPI device +are always executed in FIFO order, and complete asynchronously through +completion callbacks. There are also some simple synchronous wrappers +for those calls, including ones for common transaction types like writing +a command and then reading its response. + +There are two types of SPI driver, here called: + + Controller drivers ... + controllers may be built into System-On-Chip + processors, and often support both Master and Slave roles. + These drivers touch hardware registers and may use DMA. + Or they can be PIO bitbangers, needing just GPIO pins. + + Protocol drivers ... + these pass messages through the controller + driver to communicate with a Slave or Master device on the + other side of an SPI link. + +So for example one protocol driver might talk to the MTD layer to export +data to filesystems stored on SPI flash like DataFlash; and others might +control audio interfaces, present touchscreen sensors as input interfaces, +or monitor temperature and voltage levels during industrial processing. +And those might all be sharing the same controller driver. + +A "struct spi_device" encapsulates the controller-side interface between +those two types of drivers. + +There is a minimal core of SPI programming interfaces, focussing on +using the driver model to connect controller and protocol drivers using +device tables provided by board specific initialization code. SPI +shows up in sysfs in several locations:: + + /sys/devices/.../CTLR ... physical node for a given SPI controller + + /sys/devices/.../CTLR/spiB.C ... spi_device on bus "B", + chipselect C, accessed through CTLR. + + /sys/bus/spi/devices/spiB.C ... symlink to that physical + .../CTLR/spiB.C device + + /sys/devices/.../CTLR/spiB.C/modalias ... identifies the driver + that should be used with this device (for hotplug/coldplug) + + /sys/bus/spi/drivers/D ... driver for one or more spi*.* devices + + /sys/class/spi_master/spiB ... symlink (or actual device node) to + a logical node which could hold class related state for the SPI + master controller managing bus "B". All spiB.* devices share one + physical SPI bus segment, with SCLK, MOSI, and MISO. + + /sys/devices/.../CTLR/slave ... virtual file for (un)registering the + slave device for an SPI slave controller. + Writing the driver name of an SPI slave handler to this file + registers the slave device; writing "(null)" unregisters the slave + device. + Reading from this file shows the name of the slave device ("(null)" + if not registered). + + /sys/class/spi_slave/spiB ... symlink (or actual device node) to + a logical node which could hold class related state for the SPI + slave controller on bus "B". When registered, a single spiB.* + device is present here, possible sharing the physical SPI bus + segment with other SPI slave devices. + +Note that the actual location of the controller's class state depends +on whether you enabled CONFIG_SYSFS_DEPRECATED or not. At this time, +the only class-specific state is the bus number ("B" in "spiB"), so +those /sys/class entries are only useful to quickly identify busses. + + +How does board-specific init code declare SPI devices? +------------------------------------------------------ +Linux needs several kinds of information to properly configure SPI devices. +That information is normally provided by board-specific code, even for +chips that do support some of automated discovery/enumeration. + +Declare Controllers +^^^^^^^^^^^^^^^^^^^ + +The first kind of information is a list of what SPI controllers exist. +For System-on-Chip (SOC) based boards, these will usually be platform +devices, and the controller may need some platform_data in order to +operate properly. The "struct platform_device" will include resources +like the physical address of the controller's first register and its IRQ. + +Platforms will often abstract the "register SPI controller" operation, +maybe coupling it with code to initialize pin configurations, so that +the arch/.../mach-*/board-*.c files for several boards can all share the +same basic controller setup code. This is because most SOCs have several +SPI-capable controllers, and only the ones actually usable on a given +board should normally be set up and registered. + +So for example arch/.../mach-*/board-*.c files might have code like:: + + #include /* for mysoc_spi_data */ + + /* if your mach-* infrastructure doesn't support kernels that can + * run on multiple boards, pdata wouldn't benefit from "__init". + */ + static struct mysoc_spi_data pdata __initdata = { ... }; + + static __init board_init(void) + { + ... + /* this board only uses SPI controller #2 */ + mysoc_register_spi(2, &pdata); + ... + } + +And SOC-specific utility code might look something like:: + + #include + + static struct platform_device spi2 = { ... }; + + void mysoc_register_spi(unsigned n, struct mysoc_spi_data *pdata) + { + struct mysoc_spi_data *pdata2; + + pdata2 = kmalloc(sizeof *pdata2, GFP_KERNEL); + *pdata2 = pdata; + ... + if (n == 2) { + spi2->dev.platform_data = pdata2; + register_platform_device(&spi2); + + /* also: set up pin modes so the spi2 signals are + * visible on the relevant pins ... bootloaders on + * production boards may already have done this, but + * developer boards will often need Linux to do it. + */ + } + ... + } + +Notice how the platform_data for boards may be different, even if the +same SOC controller is used. For example, on one board SPI might use +an external clock, where another derives the SPI clock from current +settings of some master clock. + +Declare Slave Devices +^^^^^^^^^^^^^^^^^^^^^ + +The second kind of information is a list of what SPI slave devices exist +on the target board, often with some board-specific data needed for the +driver to work correctly. + +Normally your arch/.../mach-*/board-*.c files would provide a small table +listing the SPI devices on each board. (This would typically be only a +small handful.) That might look like:: + + static struct ads7846_platform_data ads_info = { + .vref_delay_usecs = 100, + .x_plate_ohms = 580, + .y_plate_ohms = 410, + }; + + static struct spi_board_info spi_board_info[] __initdata = { + { + .modalias = "ads7846", + .platform_data = &ads_info, + .mode = SPI_MODE_0, + .irq = GPIO_IRQ(31), + .max_speed_hz = 120000 /* max sample rate at 3V */ * 16, + .bus_num = 1, + .chip_select = 0, + }, + }; + +Again, notice how board-specific information is provided; each chip may need +several types. This example shows generic constraints like the fastest SPI +clock to allow (a function of board voltage in this case) or how an IRQ pin +is wired, plus chip-specific constraints like an important delay that's +changed by the capacitance at one pin. + +(There's also "controller_data", information that may be useful to the +controller driver. An example would be peripheral-specific DMA tuning +data or chipselect callbacks. This is stored in spi_device later.) + +The board_info should provide enough information to let the system work +without the chip's driver being loaded. The most troublesome aspect of +that is likely the SPI_CS_HIGH bit in the spi_device.mode field, since +sharing a bus with a device that interprets chipselect "backwards" is +not possible until the infrastructure knows how to deselect it. + +Then your board initialization code would register that table with the SPI +infrastructure, so that it's available later when the SPI master controller +driver is registered:: + + spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info)); + +Like with other static board-specific setup, you won't unregister those. + +The widely used "card" style computers bundle memory, cpu, and little else +onto a card that's maybe just thirty square centimeters. On such systems, +your ``arch/.../mach-.../board-*.c`` file would primarily provide information +about the devices on the mainboard into which such a card is plugged. That +certainly includes SPI devices hooked up through the card connectors! + + +Non-static Configurations +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Developer boards often play by different rules than product boards, and one +example is the potential need to hotplug SPI devices and/or controllers. + +For those cases you might need to use spi_busnum_to_master() to look +up the spi bus master, and will likely need spi_new_device() to provide the +board info based on the board that was hotplugged. Of course, you'd later +call at least spi_unregister_device() when that board is removed. + +When Linux includes support for MMC/SD/SDIO/DataFlash cards through SPI, those +configurations will also be dynamic. Fortunately, such devices all support +basic device identification probes, so they should hotplug normally. + + +How do I write an "SPI Protocol Driver"? +---------------------------------------- +Most SPI drivers are currently kernel drivers, but there's also support +for userspace drivers. Here we talk only about kernel drivers. + +SPI protocol drivers somewhat resemble platform device drivers:: + + static struct spi_driver CHIP_driver = { + .driver = { + .name = "CHIP", + .owner = THIS_MODULE, + .pm = &CHIP_pm_ops, + }, + + .probe = CHIP_probe, + .remove = CHIP_remove, + }; + +The driver core will automatically attempt to bind this driver to any SPI +device whose board_info gave a modalias of "CHIP". Your probe() code +might look like this unless you're creating a device which is managing +a bus (appearing under /sys/class/spi_master). + +:: + + static int CHIP_probe(struct spi_device *spi) + { + struct CHIP *chip; + struct CHIP_platform_data *pdata; + + /* assuming the driver requires board-specific data: */ + pdata = &spi->dev.platform_data; + if (!pdata) + return -ENODEV; + + /* get memory for driver's per-chip state */ + chip = kzalloc(sizeof *chip, GFP_KERNEL); + if (!chip) + return -ENOMEM; + spi_set_drvdata(spi, chip); + + ... etc + return 0; + } + +As soon as it enters probe(), the driver may issue I/O requests to +the SPI device using "struct spi_message". When remove() returns, +or after probe() fails, the driver guarantees that it won't submit +any more such messages. + + - An spi_message is a sequence of protocol operations, executed + as one atomic sequence. SPI driver controls include: + + + when bidirectional reads and writes start ... by how its + sequence of spi_transfer requests is arranged; + + + which I/O buffers are used ... each spi_transfer wraps a + buffer for each transfer direction, supporting full duplex + (two pointers, maybe the same one in both cases) and half + duplex (one pointer is NULL) transfers; + + + optionally defining short delays after transfers ... using + the spi_transfer.delay_usecs setting (this delay can be the + only protocol effect, if the buffer length is zero); + + + whether the chipselect becomes inactive after a transfer and + any delay ... by using the spi_transfer.cs_change flag; + + + hinting whether the next message is likely to go to this same + device ... using the spi_transfer.cs_change flag on the last + transfer in that atomic group, and potentially saving costs + for chip deselect and select operations. + + - Follow standard kernel rules, and provide DMA-safe buffers in + your messages. That way controller drivers using DMA aren't forced + to make extra copies unless the hardware requires it (e.g. working + around hardware errata that force the use of bounce buffering). + + If standard dma_map_single() handling of these buffers is inappropriate, + you can use spi_message.is_dma_mapped to tell the controller driver + that you've already provided the relevant DMA addresses. + + - The basic I/O primitive is spi_async(). Async requests may be + issued in any context (irq handler, task, etc) and completion + is reported using a callback provided with the message. + After any detected error, the chip is deselected and processing + of that spi_message is aborted. + + - There are also synchronous wrappers like spi_sync(), and wrappers + like spi_read(), spi_write(), and spi_write_then_read(). These + may be issued only in contexts that may sleep, and they're all + clean (and small, and "optional") layers over spi_async(). + + - The spi_write_then_read() call, and convenience wrappers around + it, should only be used with small amounts of data where the + cost of an extra copy may be ignored. It's designed to support + common RPC-style requests, such as writing an eight bit command + and reading a sixteen bit response -- spi_w8r16() being one its + wrappers, doing exactly that. + +Some drivers may need to modify spi_device characteristics like the +transfer mode, wordsize, or clock rate. This is done with spi_setup(), +which would normally be called from probe() before the first I/O is +done to the device. However, that can also be called at any time +that no message is pending for that device. + +While "spi_device" would be the bottom boundary of the driver, the +upper boundaries might include sysfs (especially for sensor readings), +the input layer, ALSA, networking, MTD, the character device framework, +or other Linux subsystems. + +Note that there are two types of memory your driver must manage as part +of interacting with SPI devices. + + - I/O buffers use the usual Linux rules, and must be DMA-safe. + You'd normally allocate them from the heap or free page pool. + Don't use the stack, or anything that's declared "static". + + - The spi_message and spi_transfer metadata used to glue those + I/O buffers into a group of protocol transactions. These can + be allocated anywhere it's convenient, including as part of + other allocate-once driver data structures. Zero-init these. + +If you like, spi_message_alloc() and spi_message_free() convenience +routines are available to allocate and zero-initialize an spi_message +with several transfers. + + +How do I write an "SPI Master Controller Driver"? +------------------------------------------------- +An SPI controller will probably be registered on the platform_bus; write +a driver to bind to the device, whichever bus is involved. + +The main task of this type of driver is to provide an "spi_master". +Use spi_alloc_master() to allocate the master, and spi_master_get_devdata() +to get the driver-private data allocated for that device. + +:: + + struct spi_master *master; + struct CONTROLLER *c; + + master = spi_alloc_master(dev, sizeof *c); + if (!master) + return -ENODEV; + + c = spi_master_get_devdata(master); + +The driver will initialize the fields of that spi_master, including the +bus number (maybe the same as the platform device ID) and three methods +used to interact with the SPI core and SPI protocol drivers. It will +also initialize its own internal state. (See below about bus numbering +and those methods.) + +After you initialize the spi_master, then use spi_register_master() to +publish it to the rest of the system. At that time, device nodes for the +controller and any predeclared spi devices will be made available, and +the driver model core will take care of binding them to drivers. + +If you need to remove your SPI controller driver, spi_unregister_master() +will reverse the effect of spi_register_master(). + + +Bus Numbering +^^^^^^^^^^^^^ + +Bus numbering is important, since that's how Linux identifies a given +SPI bus (shared SCK, MOSI, MISO). Valid bus numbers start at zero. On +SOC systems, the bus numbers should match the numbers defined by the chip +manufacturer. For example, hardware controller SPI2 would be bus number 2, +and spi_board_info for devices connected to it would use that number. + +If you don't have such hardware-assigned bus number, and for some reason +you can't just assign them, then provide a negative bus number. That will +then be replaced by a dynamically assigned number. You'd then need to treat +this as a non-static configuration (see above). + + +SPI Master Methods +^^^^^^^^^^^^^^^^^^ + +``master->setup(struct spi_device *spi)`` + This sets up the device clock rate, SPI mode, and word sizes. + Drivers may change the defaults provided by board_info, and then + call spi_setup(spi) to invoke this routine. It may sleep. + + Unless each SPI slave has its own configuration registers, don't + change them right away ... otherwise drivers could corrupt I/O + that's in progress for other SPI devices. + + .. note:: + + BUG ALERT: for some reason the first version of + many spi_master drivers seems to get this wrong. + When you code setup(), ASSUME that the controller + is actively processing transfers for another device. + +``master->cleanup(struct spi_device *spi)`` + Your controller driver may use spi_device.controller_state to hold + state it dynamically associates with that device. If you do that, + be sure to provide the cleanup() method to free that state. + +``master->prepare_transfer_hardware(struct spi_master *master)`` + This will be called by the queue mechanism to signal to the driver + that a message is coming in soon, so the subsystem requests the + driver to prepare the transfer hardware by issuing this call. + This may sleep. + +``master->unprepare_transfer_hardware(struct spi_master *master)`` + This will be called by the queue mechanism to signal to the driver + that there are no more messages pending in the queue and it may + relax the hardware (e.g. by power management calls). This may sleep. + +``master->transfer_one_message(struct spi_master *master, struct spi_message *mesg)`` + The subsystem calls the driver to transfer a single message while + queuing transfers that arrive in the meantime. When the driver is + finished with this message, it must call + spi_finalize_current_message() so the subsystem can issue the next + message. This may sleep. + +``master->transfer_one(struct spi_master *master, struct spi_device *spi, struct spi_transfer *transfer)`` + The subsystem calls the driver to transfer a single transfer while + queuing transfers that arrive in the meantime. When the driver is + finished with this transfer, it must call + spi_finalize_current_transfer() so the subsystem can issue the next + transfer. This may sleep. Note: transfer_one and transfer_one_message + are mutually exclusive; when both are set, the generic subsystem does + not call your transfer_one callback. + + Return values: + + * negative errno: error + * 0: transfer is finished + * 1: transfer is still in progress + +``master->set_cs_timing(struct spi_device *spi, u8 setup_clk_cycles, u8 hold_clk_cycles, u8 inactive_clk_cycles)`` + This method allows SPI client drivers to request SPI master controller + for configuring device specific CS setup, hold and inactive timing + requirements. + +Deprecated Methods +^^^^^^^^^^^^^^^^^^ + +``master->transfer(struct spi_device *spi, struct spi_message *message)`` + This must not sleep. Its responsibility is to arrange that the + transfer happens and its complete() callback is issued. The two + will normally happen later, after other transfers complete, and + if the controller is idle it will need to be kickstarted. This + method is not used on queued controllers and must be NULL if + transfer_one_message() and (un)prepare_transfer_hardware() are + implemented. + + +SPI Message Queue +^^^^^^^^^^^^^^^^^ + +If you are happy with the standard queueing mechanism provided by the +SPI subsystem, just implement the queued methods specified above. Using +the message queue has the upside of centralizing a lot of code and +providing pure process-context execution of methods. The message queue +can also be elevated to realtime priority on high-priority SPI traffic. + +Unless the queueing mechanism in the SPI subsystem is selected, the bulk +of the driver will be managing the I/O queue fed by the now deprecated +function transfer(). + +That queue could be purely conceptual. For example, a driver used only +for low-frequency sensor access might be fine using synchronous PIO. + +But the queue will probably be very real, using message->queue, PIO, +often DMA (especially if the root filesystem is in SPI flash), and +execution contexts like IRQ handlers, tasklets, or workqueues (such +as keventd). Your driver can be as fancy, or as simple, as you need. +Such a transfer() method would normally just add the message to a +queue, and then start some asynchronous transfer engine (unless it's +already running). + + +THANKS TO +--------- +Contributors to Linux-SPI discussions include (in alphabetical order, +by last name): + +- Mark Brown +- David Brownell +- Russell King +- Grant Likely +- Dmitry Pervushin +- Stephen Street +- Mark Underwood +- Andrew Victor +- Linus Walleij +- Vitaly Wool diff --git a/Documentation/spi/spidev b/Documentation/spi/spidev deleted file mode 100644 index 3d14035b1766..000000000000 --- a/Documentation/spi/spidev +++ /dev/null @@ -1,149 +0,0 @@ -SPI devices have a limited userspace API, supporting basic half-duplex -read() and write() access to SPI slave devices. Using ioctl() requests, -full duplex transfers and device I/O configuration are also available. - - #include - #include - #include - #include - #include - -Some reasons you might want to use this programming interface include: - - * Prototyping in an environment that's not crash-prone; stray pointers - in userspace won't normally bring down any Linux system. - - * Developing simple protocols used to talk to microcontrollers acting - as SPI slaves, which you may need to change quite often. - -Of course there are drivers that can never be written in userspace, because -they need to access kernel interfaces (such as IRQ handlers or other layers -of the driver stack) that are not accessible to userspace. - - -DEVICE CREATION, DRIVER BINDING -=============================== -The simplest way to arrange to use this driver is to just list it in the -spi_board_info for a device as the driver it should use: the "modalias" -entry is "spidev", matching the name of the driver exposing this API. -Set up the other device characteristics (bits per word, SPI clocking, -chipselect polarity, etc) as usual, so you won't always need to override -them later. - -(Sysfs also supports userspace driven binding/unbinding of drivers to -devices. That mechanism might be supported here in the future.) - -When you do that, the sysfs node for the SPI device will include a child -device node with a "dev" attribute that will be understood by udev or mdev. -(Larger systems will have "udev". Smaller ones may configure "mdev" into -busybox; it's less featureful, but often enough.) For a SPI device with -chipselect C on bus B, you should see: - - /dev/spidevB.C ... character special device, major number 153 with - a dynamically chosen minor device number. This is the node - that userspace programs will open, created by "udev" or "mdev". - - /sys/devices/.../spiB.C ... as usual, the SPI device node will - be a child of its SPI master controller. - - /sys/class/spidev/spidevB.C ... created when the "spidev" driver - binds to that device. (Directory or symlink, based on whether - or not you enabled the "deprecated sysfs files" Kconfig option.) - -Do not try to manage the /dev character device special file nodes by hand. -That's error prone, and you'd need to pay careful attention to system -security issues; udev/mdev should already be configured securely. - -If you unbind the "spidev" driver from that device, those two "spidev" nodes -(in sysfs and in /dev) should automatically be removed (respectively by the -kernel and by udev/mdev). You can unbind by removing the "spidev" driver -module, which will affect all devices using this driver. You can also unbind -by having kernel code remove the SPI device, probably by removing the driver -for its SPI controller (so its spi_master vanishes). - -Since this is a standard Linux device driver -- even though it just happens -to expose a low level API to userspace -- it can be associated with any number -of devices at a time. Just provide one spi_board_info record for each such -SPI device, and you'll get a /dev device node for each device. - - -BASIC CHARACTER DEVICE API -========================== -Normal open() and close() operations on /dev/spidevB.D files work as you -would expect. - -Standard read() and write() operations are obviously only half-duplex, and -the chipselect is deactivated between those operations. Full-duplex access, -and composite operation without chipselect de-activation, is available using -the SPI_IOC_MESSAGE(N) request. - -Several ioctl() requests let your driver read or override the device's current -settings for data transfer parameters: - - SPI_IOC_RD_MODE, SPI_IOC_WR_MODE ... pass a pointer to a byte which will - return (RD) or assign (WR) the SPI transfer mode. Use the constants - SPI_MODE_0..SPI_MODE_3; or if you prefer you can combine SPI_CPOL - (clock polarity, idle high iff this is set) or SPI_CPHA (clock phase, - sample on trailing edge iff this is set) flags. - Note that this request is limited to SPI mode flags that fit in a - single byte. - - SPI_IOC_RD_MODE32, SPI_IOC_WR_MODE32 ... pass a pointer to a uin32_t - which will return (RD) or assign (WR) the full SPI transfer mode, - not limited to the bits that fit in one byte. - - SPI_IOC_RD_LSB_FIRST, SPI_IOC_WR_LSB_FIRST ... pass a pointer to a byte - which will return (RD) or assign (WR) the bit justification used to - transfer SPI words. Zero indicates MSB-first; other values indicate - the less common LSB-first encoding. In both cases the specified value - is right-justified in each word, so that unused (TX) or undefined (RX) - bits are in the MSBs. - - SPI_IOC_RD_BITS_PER_WORD, SPI_IOC_WR_BITS_PER_WORD ... pass a pointer to - a byte which will return (RD) or assign (WR) the number of bits in - each SPI transfer word. The value zero signifies eight bits. - - SPI_IOC_RD_MAX_SPEED_HZ, SPI_IOC_WR_MAX_SPEED_HZ ... pass a pointer to a - u32 which will return (RD) or assign (WR) the maximum SPI transfer - speed, in Hz. The controller can't necessarily assign that specific - clock speed. - -NOTES: - - - At this time there is no async I/O support; everything is purely - synchronous. - - - There's currently no way to report the actual bit rate used to - shift data to/from a given device. - - - From userspace, you can't currently change the chip select polarity; - that could corrupt transfers to other devices sharing the SPI bus. - Each SPI device is deselected when it's not in active use, allowing - other drivers to talk to other devices. - - - There's a limit on the number of bytes each I/O request can transfer - to the SPI device. It defaults to one page, but that can be changed - using a module parameter. - - - Because SPI has no low-level transfer acknowledgement, you usually - won't see any I/O errors when talking to a non-existent device. - - -FULL DUPLEX CHARACTER DEVICE API -================================ - -See the spidev_fdx.c sample program for one example showing the use of the -full duplex programming interface. (Although it doesn't perform a full duplex -transfer.) The model is the same as that used in the kernel spi_sync() -request; the individual transfers offer the same capabilities as are -available to kernel drivers (except that it's not asynchronous). - -The example shows one half-duplex RPC-style request and response message. -These requests commonly require that the chip not be deselected between -the request and response. Several such requests could be chained into -a single kernel request, even allowing the chip to be deselected after -each response. (Other protocol options include changing the word size -and bitrate for each transfer segment.) - -To make a full duplex request, provide both rx_buf and tx_buf for the -same transfer. It's even OK if those are the same buffer. diff --git a/Documentation/spi/spidev.rst b/Documentation/spi/spidev.rst new file mode 100644 index 000000000000..f05dbc5ccdbc --- /dev/null +++ b/Documentation/spi/spidev.rst @@ -0,0 +1,163 @@ +================= +SPI userspace API +================= + +SPI devices have a limited userspace API, supporting basic half-duplex +read() and write() access to SPI slave devices. Using ioctl() requests, +full duplex transfers and device I/O configuration are also available. + +:: + + #include + #include + #include + #include + #include + +Some reasons you might want to use this programming interface include: + + * Prototyping in an environment that's not crash-prone; stray pointers + in userspace won't normally bring down any Linux system. + + * Developing simple protocols used to talk to microcontrollers acting + as SPI slaves, which you may need to change quite often. + +Of course there are drivers that can never be written in userspace, because +they need to access kernel interfaces (such as IRQ handlers or other layers +of the driver stack) that are not accessible to userspace. + + +DEVICE CREATION, DRIVER BINDING +=============================== +The simplest way to arrange to use this driver is to just list it in the +spi_board_info for a device as the driver it should use: the "modalias" +entry is "spidev", matching the name of the driver exposing this API. +Set up the other device characteristics (bits per word, SPI clocking, +chipselect polarity, etc) as usual, so you won't always need to override +them later. + +(Sysfs also supports userspace driven binding/unbinding of drivers to +devices. That mechanism might be supported here in the future.) + +When you do that, the sysfs node for the SPI device will include a child +device node with a "dev" attribute that will be understood by udev or mdev. +(Larger systems will have "udev". Smaller ones may configure "mdev" into +busybox; it's less featureful, but often enough.) For a SPI device with +chipselect C on bus B, you should see: + + /dev/spidevB.C ... + character special device, major number 153 with + a dynamically chosen minor device number. This is the node + that userspace programs will open, created by "udev" or "mdev". + + /sys/devices/.../spiB.C ... + as usual, the SPI device node will + be a child of its SPI master controller. + + /sys/class/spidev/spidevB.C ... + created when the "spidev" driver + binds to that device. (Directory or symlink, based on whether + or not you enabled the "deprecated sysfs files" Kconfig option.) + +Do not try to manage the /dev character device special file nodes by hand. +That's error prone, and you'd need to pay careful attention to system +security issues; udev/mdev should already be configured securely. + +If you unbind the "spidev" driver from that device, those two "spidev" nodes +(in sysfs and in /dev) should automatically be removed (respectively by the +kernel and by udev/mdev). You can unbind by removing the "spidev" driver +module, which will affect all devices using this driver. You can also unbind +by having kernel code remove the SPI device, probably by removing the driver +for its SPI controller (so its spi_master vanishes). + +Since this is a standard Linux device driver -- even though it just happens +to expose a low level API to userspace -- it can be associated with any number +of devices at a time. Just provide one spi_board_info record for each such +SPI device, and you'll get a /dev device node for each device. + + +BASIC CHARACTER DEVICE API +========================== +Normal open() and close() operations on /dev/spidevB.D files work as you +would expect. + +Standard read() and write() operations are obviously only half-duplex, and +the chipselect is deactivated between those operations. Full-duplex access, +and composite operation without chipselect de-activation, is available using +the SPI_IOC_MESSAGE(N) request. + +Several ioctl() requests let your driver read or override the device's current +settings for data transfer parameters: + + SPI_IOC_RD_MODE, SPI_IOC_WR_MODE ... + pass a pointer to a byte which will + return (RD) or assign (WR) the SPI transfer mode. Use the constants + SPI_MODE_0..SPI_MODE_3; or if you prefer you can combine SPI_CPOL + (clock polarity, idle high iff this is set) or SPI_CPHA (clock phase, + sample on trailing edge iff this is set) flags. + Note that this request is limited to SPI mode flags that fit in a + single byte. + + SPI_IOC_RD_MODE32, SPI_IOC_WR_MODE32 ... + pass a pointer to a uin32_t + which will return (RD) or assign (WR) the full SPI transfer mode, + not limited to the bits that fit in one byte. + + SPI_IOC_RD_LSB_FIRST, SPI_IOC_WR_LSB_FIRST ... + pass a pointer to a byte + which will return (RD) or assign (WR) the bit justification used to + transfer SPI words. Zero indicates MSB-first; other values indicate + the less common LSB-first encoding. In both cases the specified value + is right-justified in each word, so that unused (TX) or undefined (RX) + bits are in the MSBs. + + SPI_IOC_RD_BITS_PER_WORD, SPI_IOC_WR_BITS_PER_WORD ... + pass a pointer to + a byte which will return (RD) or assign (WR) the number of bits in + each SPI transfer word. The value zero signifies eight bits. + + SPI_IOC_RD_MAX_SPEED_HZ, SPI_IOC_WR_MAX_SPEED_HZ ... + pass a pointer to a + u32 which will return (RD) or assign (WR) the maximum SPI transfer + speed, in Hz. The controller can't necessarily assign that specific + clock speed. + +NOTES: + + - At this time there is no async I/O support; everything is purely + synchronous. + + - There's currently no way to report the actual bit rate used to + shift data to/from a given device. + + - From userspace, you can't currently change the chip select polarity; + that could corrupt transfers to other devices sharing the SPI bus. + Each SPI device is deselected when it's not in active use, allowing + other drivers to talk to other devices. + + - There's a limit on the number of bytes each I/O request can transfer + to the SPI device. It defaults to one page, but that can be changed + using a module parameter. + + - Because SPI has no low-level transfer acknowledgement, you usually + won't see any I/O errors when talking to a non-existent device. + + +FULL DUPLEX CHARACTER DEVICE API +================================ + +See the spidev_fdx.c sample program for one example showing the use of the +full duplex programming interface. (Although it doesn't perform a full duplex +transfer.) The model is the same as that used in the kernel spi_sync() +request; the individual transfers offer the same capabilities as are +available to kernel drivers (except that it's not asynchronous). + +The example shows one half-duplex RPC-style request and response message. +These requests commonly require that the chip not be deselected between +the request and response. Several such requests could be chained into +a single kernel request, even allowing the chip to be deselected after +each response. (Other protocol options include changing the word size +and bitrate for each transfer segment.) + +To make a full duplex request, provide both rx_buf and tx_buf for the +same transfer. It's even OK if those are the same buffer. diff --git a/Documentation/thermal/index.rst b/Documentation/thermal/index.rst deleted file mode 100644 index 8c1c00146cad..000000000000 --- a/Documentation/thermal/index.rst +++ /dev/null @@ -1,18 +0,0 @@ -:orphan: - -======= -Thermal -======= - -.. toctree:: - :maxdepth: 1 - - cpu-cooling-api - sysfs-api - power_allocator - - exynos_thermal - exynos_thermal_emulation - intel_powerclamp - nouveau_thermal - x86_pkg_temperature_thermal diff --git a/Documentation/thermal/sysfs-api.rst b/Documentation/thermal/sysfs-api.rst deleted file mode 100644 index e4930761d3e5..000000000000 --- a/Documentation/thermal/sysfs-api.rst +++ /dev/null @@ -1,798 +0,0 @@ -=================================== -Generic Thermal Sysfs driver How To -=================================== - -Written by Sujith Thomas , Zhang Rui - -Updated: 2 January 2008 - -Copyright (c) 2008 Intel Corporation - - -0. Introduction -=============== - -The generic thermal sysfs provides a set of interfaces for thermal zone -devices (sensors) and thermal cooling devices (fan, processor...) to register -with the thermal management solution and to be a part of it. - -This how-to focuses on enabling new thermal zone and cooling devices to -participate in thermal management. -This solution is platform independent and any type of thermal zone devices -and cooling devices should be able to make use of the infrastructure. - -The main task of the thermal sysfs driver is to expose thermal zone attributes -as well as cooling device attributes to the user space. -An intelligent thermal management application can make decisions based on -inputs from thermal zone attributes (the current temperature and trip point -temperature) and throttle appropriate devices. - -- `[0-*]` denotes any positive number starting from 0 -- `[1-*]` denotes any positive number starting from 1 - -1. thermal sysfs driver interface functions -=========================================== - -1.1 thermal zone device interface ---------------------------------- - - :: - - struct thermal_zone_device - *thermal_zone_device_register(char *type, - int trips, int mask, void *devdata, - struct thermal_zone_device_ops *ops, - const struct thermal_zone_params *tzp, - int passive_delay, int polling_delay)) - - This interface function adds a new thermal zone device (sensor) to - /sys/class/thermal folder as `thermal_zone[0-*]`. It tries to bind all the - thermal cooling devices registered at the same time. - - type: - the thermal zone type. - trips: - the total number of trip points this thermal zone supports. - mask: - Bit string: If 'n'th bit is set, then trip point 'n' is writeable. - devdata: - device private data - ops: - thermal zone device call-backs. - - .bind: - bind the thermal zone device with a thermal cooling device. - .unbind: - unbind the thermal zone device with a thermal cooling device. - .get_temp: - get the current temperature of the thermal zone. - .set_trips: - set the trip points window. Whenever the current temperature - is updated, the trip points immediately below and above the - current temperature are found. - .get_mode: - get the current mode (enabled/disabled) of the thermal zone. - - - "enabled" means the kernel thermal management is - enabled. - - "disabled" will prevent kernel thermal driver action - upon trip points so that user applications can take - charge of thermal management. - .set_mode: - set the mode (enabled/disabled) of the thermal zone. - .get_trip_type: - get the type of certain trip point. - .get_trip_temp: - get the temperature above which the certain trip point - will be fired. - .set_emul_temp: - set the emulation temperature which helps in debugging - different threshold temperature points. - tzp: - thermal zone platform parameters. - passive_delay: - number of milliseconds to wait between polls when - performing passive cooling. - polling_delay: - number of milliseconds to wait between polls when checking - whether trip points have been crossed (0 for interrupt driven systems). - - :: - - void thermal_zone_device_unregister(struct thermal_zone_device *tz) - - This interface function removes the thermal zone device. - It deletes the corresponding entry from /sys/class/thermal folder and - unbinds all the thermal cooling devices it uses. - - :: - - struct thermal_zone_device - *thermal_zone_of_sensor_register(struct device *dev, int sensor_id, - void *data, - const struct thermal_zone_of_device_ops *ops) - - This interface adds a new sensor to a DT thermal zone. - This function will search the list of thermal zones described in - device tree and look for the zone that refer to the sensor device - pointed by dev->of_node as temperature providers. For the zone - pointing to the sensor node, the sensor will be added to the DT - thermal zone device. - - The parameters for this interface are: - - dev: - Device node of sensor containing valid node pointer in - dev->of_node. - sensor_id: - a sensor identifier, in case the sensor IP has more - than one sensors - data: - a private pointer (owned by the caller) that will be - passed back, when a temperature reading is needed. - ops: - `struct thermal_zone_of_device_ops *`. - - ============== ======================================= - get_temp a pointer to a function that reads the - sensor temperature. This is mandatory - callback provided by sensor driver. - set_trips a pointer to a function that sets a - temperature window. When this window is - left the driver must inform the thermal - core via thermal_zone_device_update. - get_trend a pointer to a function that reads the - sensor temperature trend. - set_emul_temp a pointer to a function that sets - sensor emulated temperature. - ============== ======================================= - - The thermal zone temperature is provided by the get_temp() function - pointer of thermal_zone_of_device_ops. When called, it will - have the private pointer @data back. - - It returns error pointer if fails otherwise valid thermal zone device - handle. Caller should check the return handle with IS_ERR() for finding - whether success or not. - - :: - - void thermal_zone_of_sensor_unregister(struct device *dev, - struct thermal_zone_device *tzd) - - This interface unregisters a sensor from a DT thermal zone which was - successfully added by interface thermal_zone_of_sensor_register(). - This function removes the sensor callbacks and private data from the - thermal zone device registered with thermal_zone_of_sensor_register() - interface. It will also silent the zone by remove the .get_temp() and - get_trend() thermal zone device callbacks. - - :: - - struct thermal_zone_device - *devm_thermal_zone_of_sensor_register(struct device *dev, - int sensor_id, - void *data, - const struct thermal_zone_of_device_ops *ops) - - This interface is resource managed version of - thermal_zone_of_sensor_register(). - - All details of thermal_zone_of_sensor_register() described in - section 1.1.3 is applicable here. - - The benefit of using this interface to register sensor is that it - is not require to explicitly call thermal_zone_of_sensor_unregister() - in error path or during driver unbinding as this is done by driver - resource manager. - - :: - - void devm_thermal_zone_of_sensor_unregister(struct device *dev, - struct thermal_zone_device *tzd) - - This interface is resource managed version of - thermal_zone_of_sensor_unregister(). - All details of thermal_zone_of_sensor_unregister() described in - section 1.1.4 is applicable here. - Normally this function will not need to be called and the resource - management code will ensure that the resource is freed. - - :: - - int thermal_zone_get_slope(struct thermal_zone_device *tz) - - This interface is used to read the slope attribute value - for the thermal zone device, which might be useful for platform - drivers for temperature calculations. - - :: - - int thermal_zone_get_offset(struct thermal_zone_device *tz) - - This interface is used to read the offset attribute value - for the thermal zone device, which might be useful for platform - drivers for temperature calculations. - -1.2 thermal cooling device interface ------------------------------------- - - - :: - - struct thermal_cooling_device - *thermal_cooling_device_register(char *name, - void *devdata, struct thermal_cooling_device_ops *) - - This interface function adds a new thermal cooling device (fan/processor/...) - to /sys/class/thermal/ folder as `cooling_device[0-*]`. It tries to bind itself - to all the thermal zone devices registered at the same time. - - name: - the cooling device name. - devdata: - device private data. - ops: - thermal cooling devices call-backs. - - .get_max_state: - get the Maximum throttle state of the cooling device. - .get_cur_state: - get the Currently requested throttle state of the - cooling device. - .set_cur_state: - set the Current throttle state of the cooling device. - - :: - - void thermal_cooling_device_unregister(struct thermal_cooling_device *cdev) - - This interface function removes the thermal cooling device. - It deletes the corresponding entry from /sys/class/thermal folder and - unbinds itself from all the thermal zone devices using it. - -1.3 interface for binding a thermal zone device with a thermal cooling device ------------------------------------------------------------------------------ - - :: - - int thermal_zone_bind_cooling_device(struct thermal_zone_device *tz, - int trip, struct thermal_cooling_device *cdev, - unsigned long upper, unsigned long lower, unsigned int weight); - - This interface function binds a thermal cooling device to a particular trip - point of a thermal zone device. - - This function is usually called in the thermal zone device .bind callback. - - tz: - the thermal zone device - cdev: - thermal cooling device - trip: - indicates which trip point in this thermal zone the cooling device - is associated with. - upper: - the Maximum cooling state for this trip point. - THERMAL_NO_LIMIT means no upper limit, - and the cooling device can be in max_state. - lower: - the Minimum cooling state can be used for this trip point. - THERMAL_NO_LIMIT means no lower limit, - and the cooling device can be in cooling state 0. - weight: - the influence of this cooling device in this thermal - zone. See 1.4.1 below for more information. - - :: - - int thermal_zone_unbind_cooling_device(struct thermal_zone_device *tz, - int trip, struct thermal_cooling_device *cdev); - - This interface function unbinds a thermal cooling device from a particular - trip point of a thermal zone device. This function is usually called in - the thermal zone device .unbind callback. - - tz: - the thermal zone device - cdev: - thermal cooling device - trip: - indicates which trip point in this thermal zone the cooling device - is associated with. - -1.4 Thermal Zone Parameters ---------------------------- - - :: - - struct thermal_bind_params - - This structure defines the following parameters that are used to bind - a zone with a cooling device for a particular trip point. - - .cdev: - The cooling device pointer - .weight: - The 'influence' of a particular cooling device on this - zone. This is relative to the rest of the cooling - devices. For example, if all cooling devices have a - weight of 1, then they all contribute the same. You can - use percentages if you want, but it's not mandatory. A - weight of 0 means that this cooling device doesn't - contribute to the cooling of this zone unless all cooling - devices have a weight of 0. If all weights are 0, then - they all contribute the same. - .trip_mask: - This is a bit mask that gives the binding relation between - this thermal zone and cdev, for a particular trip point. - If nth bit is set, then the cdev and thermal zone are bound - for trip point n. - .binding_limits: - This is an array of cooling state limits. Must have - exactly 2 * thermal_zone.number_of_trip_points. It is an - array consisting of tuples of - state limits. Each trip will be associated with one state - limit tuple when binding. A NULL pointer means - on all trips. - These limits are used when binding a cdev to a trip point. - .match: - This call back returns success(0) if the 'tz and cdev' need to - be bound, as per platform data. - - :: - - struct thermal_zone_params - - This structure defines the platform level parameters for a thermal zone. - This data, for each thermal zone should come from the platform layer. - This is an optional feature where some platforms can choose not to - provide this data. - - .governor_name: - Name of the thermal governor used for this zone - .no_hwmon: - a boolean to indicate if the thermal to hwmon sysfs interface - is required. when no_hwmon == false, a hwmon sysfs interface - will be created. when no_hwmon == true, nothing will be done. - In case the thermal_zone_params is NULL, the hwmon interface - will be created (for backward compatibility). - .num_tbps: - Number of thermal_bind_params entries for this zone - .tbp: - thermal_bind_params entries - -2. sysfs attributes structure -============================= - -== ================ -RO read only value -WO write only value -RW read/write value -== ================ - -Thermal sysfs attributes will be represented under /sys/class/thermal. -Hwmon sysfs I/F extension is also available under /sys/class/hwmon -if hwmon is compiled in or built as a module. - -Thermal zone device sys I/F, created once it's registered:: - - /sys/class/thermal/thermal_zone[0-*]: - |---type: Type of the thermal zone - |---temp: Current temperature - |---mode: Working mode of the thermal zone - |---policy: Thermal governor used for this zone - |---available_policies: Available thermal governors for this zone - |---trip_point_[0-*]_temp: Trip point temperature - |---trip_point_[0-*]_type: Trip point type - |---trip_point_[0-*]_hyst: Hysteresis value for this trip point - |---emul_temp: Emulated temperature set node - |---sustainable_power: Sustainable dissipatable power - |---k_po: Proportional term during temperature overshoot - |---k_pu: Proportional term during temperature undershoot - |---k_i: PID's integral term in the power allocator gov - |---k_d: PID's derivative term in the power allocator - |---integral_cutoff: Offset above which errors are accumulated - |---slope: Slope constant applied as linear extrapolation - |---offset: Offset constant applied as linear extrapolation - -Thermal cooling device sys I/F, created once it's registered:: - - /sys/class/thermal/cooling_device[0-*]: - |---type: Type of the cooling device(processor/fan/...) - |---max_state: Maximum cooling state of the cooling device - |---cur_state: Current cooling state of the cooling device - |---stats: Directory containing cooling device's statistics - |---stats/reset: Writing any value resets the statistics - |---stats/time_in_state_ms: Time (msec) spent in various cooling states - |---stats/total_trans: Total number of times cooling state is changed - |---stats/trans_table: Cooing state transition table - - -Then next two dynamic attributes are created/removed in pairs. They represent -the relationship between a thermal zone and its associated cooling device. -They are created/removed for each successful execution of -thermal_zone_bind_cooling_device/thermal_zone_unbind_cooling_device. - -:: - - /sys/class/thermal/thermal_zone[0-*]: - |---cdev[0-*]: [0-*]th cooling device in current thermal zone - |---cdev[0-*]_trip_point: Trip point that cdev[0-*] is associated with - |---cdev[0-*]_weight: Influence of the cooling device in - this thermal zone - -Besides the thermal zone device sysfs I/F and cooling device sysfs I/F, -the generic thermal driver also creates a hwmon sysfs I/F for each _type_ -of thermal zone device. E.g. the generic thermal driver registers one hwmon -class device and build the associated hwmon sysfs I/F for all the registered -ACPI thermal zones. - -:: - - /sys/class/hwmon/hwmon[0-*]: - |---name: The type of the thermal zone devices - |---temp[1-*]_input: The current temperature of thermal zone [1-*] - |---temp[1-*]_critical: The critical trip point of thermal zone [1-*] - -Please read Documentation/hwmon/sysfs-interface.rst for additional information. - -Thermal zone attributes ------------------------ - -type - Strings which represent the thermal zone type. - This is given by thermal zone driver as part of registration. - E.g: "acpitz" indicates it's an ACPI thermal device. - In order to keep it consistent with hwmon sys attribute; this should - be a short, lowercase string, not containing spaces nor dashes. - RO, Required - -temp - Current temperature as reported by thermal zone (sensor). - Unit: millidegree Celsius - RO, Required - -mode - One of the predefined values in [enabled, disabled]. - This file gives information about the algorithm that is currently - managing the thermal zone. It can be either default kernel based - algorithm or user space application. - - enabled - enable Kernel Thermal management. - disabled - Preventing kernel thermal zone driver actions upon - trip points so that user application can take full - charge of the thermal management. - - RW, Optional - -policy - One of the various thermal governors used for a particular zone. - - RW, Required - -available_policies - Available thermal governors which can be used for a particular zone. - - RO, Required - -`trip_point_[0-*]_temp` - The temperature above which trip point will be fired. - - Unit: millidegree Celsius - - RO, Optional - -`trip_point_[0-*]_type` - Strings which indicate the type of the trip point. - - E.g. it can be one of critical, hot, passive, `active[0-*]` for ACPI - thermal zone. - - RO, Optional - -`trip_point_[0-*]_hyst` - The hysteresis value for a trip point, represented as an integer - Unit: Celsius - RW, Optional - -`cdev[0-*]` - Sysfs link to the thermal cooling device node where the sys I/F - for cooling device throttling control represents. - - RO, Optional - -`cdev[0-*]_trip_point` - The trip point in this thermal zone which `cdev[0-*]` is associated - with; -1 means the cooling device is not associated with any trip - point. - - RO, Optional - -`cdev[0-*]_weight` - The influence of `cdev[0-*]` in this thermal zone. This value - is relative to the rest of cooling devices in the thermal - zone. For example, if a cooling device has a weight double - than that of other, it's twice as effective in cooling the - thermal zone. - - RW, Optional - -passive - Attribute is only present for zones in which the passive cooling - policy is not supported by native thermal driver. Default is zero - and can be set to a temperature (in millidegrees) to enable a - passive trip point for the zone. Activation is done by polling with - an interval of 1 second. - - Unit: millidegrees Celsius - - Valid values: 0 (disabled) or greater than 1000 - - RW, Optional - -emul_temp - Interface to set the emulated temperature method in thermal zone - (sensor). After setting this temperature, the thermal zone may pass - this temperature to platform emulation function if registered or - cache it locally. This is useful in debugging different temperature - threshold and its associated cooling action. This is write only node - and writing 0 on this node should disable emulation. - Unit: millidegree Celsius - - WO, Optional - - WARNING: - Be careful while enabling this option on production systems, - because userland can easily disable the thermal policy by simply - flooding this sysfs node with low temperature values. - -sustainable_power - An estimate of the sustained power that can be dissipated by - the thermal zone. Used by the power allocator governor. For - more information see Documentation/thermal/power_allocator.rst - - Unit: milliwatts - - RW, Optional - -k_po - The proportional term of the power allocator governor's PID - controller during temperature overshoot. Temperature overshoot - is when the current temperature is above the "desired - temperature" trip point. For more information see - Documentation/thermal/power_allocator.rst - - RW, Optional - -k_pu - The proportional term of the power allocator governor's PID - controller during temperature undershoot. Temperature undershoot - is when the current temperature is below the "desired - temperature" trip point. For more information see - Documentation/thermal/power_allocator.rst - - RW, Optional - -k_i - The integral term of the power allocator governor's PID - controller. This term allows the PID controller to compensate - for long term drift. For more information see - Documentation/thermal/power_allocator.rst - - RW, Optional - -k_d - The derivative term of the power allocator governor's PID - controller. For more information see - Documentation/thermal/power_allocator.rst - - RW, Optional - -integral_cutoff - Temperature offset from the desired temperature trip point - above which the integral term of the power allocator - governor's PID controller starts accumulating errors. For - example, if integral_cutoff is 0, then the integral term only - accumulates error when temperature is above the desired - temperature trip point. For more information see - Documentation/thermal/power_allocator.rst - - Unit: millidegree Celsius - - RW, Optional - -slope - The slope constant used in a linear extrapolation model - to determine a hotspot temperature based off the sensor's - raw readings. It is up to the device driver to determine - the usage of these values. - - RW, Optional - -offset - The offset constant used in a linear extrapolation model - to determine a hotspot temperature based off the sensor's - raw readings. It is up to the device driver to determine - the usage of these values. - - RW, Optional - -Cooling device attributes -------------------------- - -type - String which represents the type of device, e.g: - - - for generic ACPI: should be "Fan", "Processor" or "LCD" - - for memory controller device on intel_menlow platform: - should be "Memory controller". - - RO, Required - -max_state - The maximum permissible cooling state of this cooling device. - - RO, Required - -cur_state - The current cooling state of this cooling device. - The value can any integer numbers between 0 and max_state: - - - cur_state == 0 means no cooling - - cur_state == max_state means the maximum cooling. - - RW, Required - -stats/reset - Writing any value resets the cooling device's statistics. - WO, Required - -stats/time_in_state_ms: - The amount of time spent by the cooling device in various cooling - states. The output will have "