diff options
Diffstat (limited to 'Documentation')
237 files changed, 6828 insertions, 2355 deletions
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 <N> 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-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/<backlight>/scale +Date: July 2019 +KernelVersion: 5.4 +Contact: Daniel Thompson <daniel.thompson@linaro.org> +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-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 <s-anna@ti.com> +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-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 <i.mikhaylov@yadro.com>, + Alexander Amelkin <a.amelkin@yadro.com> +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-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-kernel@vger.kernel.org> + Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org> +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-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/<disk>/encoding +Date July 2019 +Contact: "Daniel Rosenberg" <drosen@google.com> +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-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 <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> 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/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/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/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 <metadata dev> <destination dev> <source dev> <region size> + [<#feature args> [<feature arg>]* [<#core args> [<core arg>]*]] + + ================ ============================================================== + 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 +------ + + :: + + <metadata block size> <#used metadata blocks>/<#total metadata blocks> + <region size> <#hydrated regions>/<#total regions> <#hydrating regions> + <#feature args> <feature args>* <#core args> <core args>* + <clone metadata mode> + + ======================= ======================================================= + 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 <key_description> + 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/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 782e9072407b..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: <int> The number of initial APIC ID for the @@ -2270,6 +2276,15 @@ lockd.nlm_udpport=M [NFS] Assign UDP port. Format: <integer> + 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 @@ -3461,12 +3476,13 @@ specify the device is described above. If <order of align> 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 @@ -4641,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 @@ -5326,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/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/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 <afaerber@suse.de> + - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> + +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/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 <narmstrong@baylibre.com> + +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-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 727e0ffc702b..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: 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: <prop-encoded-array> 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: <prop-encoded-array> 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/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,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/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 <afaerber@suse.de> + +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/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 <wens@csie.org> + - Maxime Ripard <maxime.ripard@bootlin.com> + +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/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/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/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: <GCC_LPASS_Q6_AXI_CLK>, <GCC_LPASS_SWAY_CLK>; }; + +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 index 268ca615459e..268ca615459e 100644 --- a/Documentation/devicetree/bindings/clock/emev2-clock.txt +++ b/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 = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>; + 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/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 <wens@csie.org> + - Maxime Ripard <maxime.ripard@bootlin.com> + +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 = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&ahb_gates 5>, <&ss_clk>; - clock-names = "ahb", "mod"; - }; diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt deleted file mode 100644 index 3a50a7862cf3..000000000000 --- a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt +++ /dev/null @@ -1,119 +0,0 @@ -Amlogic specific extensions to the Synopsys Designware HDMI Controller -====================================================================== - -The Amlogic Meson Synopsys Designware Integration is composed of : -- A Synopsys DesignWare HDMI Controller IP -- A TOP control block controlling the Clocks and PHY -- A custom HDMI PHY in order to convert video to TMDS signal - ___________________________________ -| HDMI TOP |<= HPD -|___________________________________| -| | | -| Synopsys HDMI | HDMI PHY |=> TMDS -| Controller |________________| -|___________________________________|<=> DDC - -The HDMI TOP block only supports HPD sensing. -The Synopsys HDMI Controller interrupt is routed through the -TOP Block interrupt. -Communication to the TOP Block and the Synopsys HDMI Controller is done -via a pair of dedicated addr+read/write registers. -The HDMI PHY is configured by registers in the HHI register block. - -Pixel data arrives in 4:4:4 format from the VENC block and the VPU HDMI mux -selects either the ENCI encoder for the 576i or 480i formats or the ENCP -encoder for all the other formats including interlaced HD formats. - -The VENC uses a DVI encoder on top of the ENCI or ENCP encoders to generate -DVI timings for the HDMI controller. - -Amlogic Meson GXBB, GXL and GXM SoCs families embeds the Synopsys DesignWare -HDMI TX IP version 2.01a with HDCP and I2C & S/PDIF -audio source interfaces. - -Required properties: -- compatible: value should be different for each SoC family as : - - GXBB (S905) : "amlogic,meson-gxbb-dw-hdmi" - - GXL (S905X, S905D) : "amlogic,meson-gxl-dw-hdmi" - - GXM (S912) : "amlogic,meson-gxm-dw-hdmi" - followed by the common "amlogic,meson-gx-dw-hdmi" - - G12A (S905X2, S905Y2, S905D2) : "amlogic,meson-g12a-dw-hdmi" -- reg: Physical base address and length of the controller's registers. -- interrupts: The HDMI interrupt number -- clocks, clock-names : must have the phandles to the HDMI iahb and isfr clocks, - and the Amlogic Meson venci clocks as described in - Documentation/devicetree/bindings/clock/clock-bindings.txt, - the clocks are soc specific, the clock-names should be "iahb", "isfr", "venci" -- resets, resets-names: must have the phandles to the HDMI apb, glue and phy - resets as described in : - Documentation/devicetree/bindings/reset/reset.txt, - the reset-names should be "hdmitx_apb", "hdmitx", "hdmitx_phy" - -Optional properties: -- hdmi-supply: Optional phandle to an external 5V regulator to power the HDMI - logic, as described in the file ../regulator/regulator.txt - -Required nodes: - -The connections to the HDMI ports are modeled using the OF graph -bindings specified in Documentation/devicetree/bindings/graph.txt. - -The following table lists for each supported model the port number -corresponding to each HDMI output and input. - - Port 0 Port 1 ------------------------------------------ - S905 (GXBB) VENC Input TMDS Output - S905X (GXL) VENC Input TMDS Output - S905D (GXL) VENC Input TMDS Output - S912 (GXM) VENC Input TMDS Output - S905X2 (G12A) VENC Input TMDS Output - S905Y2 (G12A) VENC Input TMDS Output - S905D2 (G12A) VENC Input TMDS Output - -Example: - -hdmi-connector { - compatible = "hdmi-connector"; - type = "a"; - - port { - hdmi_connector_in: endpoint { - remote-endpoint = <&hdmi_tx_tmds_out>; - }; - }; -}; - -hdmi_tx: hdmi-tx@c883a000 { - compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi"; - reg = <0x0 0xc883a000 0x0 0x1c>; - interrupts = <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>; - resets = <&reset RESET_HDMITX_CAPB3>, - <&reset RESET_HDMI_SYSTEM_RESET>, - <&reset RESET_HDMI_TX>; - reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy"; - clocks = <&clkc CLKID_HDMI_PCLK>, - <&clkc CLKID_CLK81>, - <&clkc CLKID_GCLK_VENCI_INT0>; - clock-names = "isfr", "iahb", "venci"; - #address-cells = <1>; - #size-cells = <0>; - - /* VPU VENC Input */ - hdmi_tx_venc_port: port@0 { - reg = <0>; - - hdmi_tx_in: endpoint { - remote-endpoint = <&hdmi_tx_out>; - }; - }; - - /* TMDS Output */ - hdmi_tx_tmds_port: port@1 { - reg = <1>; - - hdmi_tx_tmds_out: endpoint { - remote-endpoint = <&hdmi_connector_in>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml new file mode 100644 index 000000000000..fb747682006d --- /dev/null +++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml @@ -0,0 +1,150 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 BayLibre, SAS +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/display/amlogic,meson-dw-hdmi.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic specific extensions to the Synopsys Designware HDMI Controller + +maintainers: + - Neil Armstrong <narmstrong@baylibre.com> + +description: | + The Amlogic Meson Synopsys Designware Integration is composed of + - A Synopsys DesignWare HDMI Controller IP + - A TOP control block controlling the Clocks and PHY + - A custom HDMI PHY in order to convert video to TMDS signal + ___________________________________ + | HDMI TOP |<= HPD + |___________________________________| + | | | + | Synopsys HDMI | HDMI PHY |=> TMDS + | Controller |________________| + |___________________________________|<=> DDC + + The HDMI TOP block only supports HPD sensing. + The Synopsys HDMI Controller interrupt is routed through the + TOP Block interrupt. + Communication to the TOP Block and the Synopsys HDMI Controller is done + via a pair of dedicated addr+read/write registers. + The HDMI PHY is configured by registers in the HHI register block. + + Pixel data arrives in "4:4:4" format from the VENC block and the VPU HDMI mux + selects either the ENCI encoder for the 576i or 480i formats or the ENCP + encoder for all the other formats including interlaced HD formats. + + The VENC uses a DVI encoder on top of the ENCI or ENCP encoders to generate + DVI timings for the HDMI controller. + + Amlogic Meson GXBB, GXL and GXM SoCs families embeds the Synopsys DesignWare + HDMI TX IP version 2.01a with HDCP and I2C & S/PDIF + audio source interfaces. + +properties: + compatible: + oneOf: + - items: + - enum: + - amlogic,meson-gxbb-dw-hdmi # GXBB (S905) + - amlogic,meson-gxl-dw-hdmi # GXL (S905X, S905D) + - amlogic,meson-gxm-dw-hdmi # GXM (S912) + - const: amlogic,meson-gx-dw-hdmi + - enum: + - amlogic,meson-g12a-dw-hdmi # G12A (S905X2, S905Y2, S905D2) + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 3 + + clock-names: + items: + - const: isfr + - const: iahb + - const: venci + + resets: + minItems: 3 + + reset-names: + items: + - const: hdmitx_apb + - const: hdmitx + - const: hdmitx_phy + + hdmi-supply: + description: phandle to an external 5V regulator to power the HDMI logic + allOf: + - $ref: /schemas/types.yaml#/definitions/phandle + + port@0: + type: object + description: + A port node pointing to the VENC Input port node. + + port@1: + type: object + description: + A port node pointing to the TMDS Output port node. + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - resets + - reset-names + - port@0 + - port@1 + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + hdmi_tx: hdmi-tx@c883a000 { + compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi"; + reg = <0xc883a000 0x1c>; + interrupts = <57>; + resets = <&reset_apb>, <&reset_hdmitx>, <&reset_hdmitx_phy>; + reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy"; + clocks = <&clk_isfr>, <&clk_iahb>, <&clk_venci>; + clock-names = "isfr", "iahb", "venci"; + #address-cells = <1>; + #size-cells = <0>; + + /* VPU VENC Input */ + hdmi_tx_venc_port: port@0 { + reg = <0>; + + hdmi_tx_in: endpoint { + remote-endpoint = <&hdmi_tx_out>; + }; + }; + + /* TMDS Output */ + hdmi_tx_tmds_port: port@1 { + reg = <1>; + + hdmi_tx_tmds_out: endpoint { + remote-endpoint = <&hdmi_connector_in>; + }; + }; + }; + diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt deleted file mode 100644 index be40a780501c..000000000000 --- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt +++ /dev/null @@ -1,121 +0,0 @@ -Amlogic Meson Display Controller -================================ - -The Amlogic Meson Display controller is composed of several components -that are going to be documented below: - -DMC|---------------VPU (Video Processing Unit)----------------|------HHI------| - | vd1 _______ _____________ _________________ | | -D |-------| |----| | | | | HDMI PLL | -D | vd2 | VIU | | Video Post | | Video Encoders |<---|-----VCLK | -R |-------| |----| Processing | | | | | - | osd2 | | | |---| Enci ----------|----|-----VDAC------| -R |-------| CSC |----| Scalers | | Encp ----------|----|----HDMI-TX----| -A | osd1 | | | Blenders | | Encl ----------|----|---------------| -M |-------|______|----|____________| |________________| | | -___|__________________________________________________________|_______________| - - -VIU: Video Input Unit ---------------------- - -The Video Input Unit is in charge of the pixel scanout from the DDR memory. -It fetches the frames addresses, stride and parameters from the "Canvas" memory. -This part is also in charge of the CSC (Colorspace Conversion). -It can handle 2 OSD Planes and 2 Video Planes. - -VPP: Video Post Processing --------------------------- - -The Video Post Processing is in charge of the scaling and blending of the -various planes into a single pixel stream. -There is a special "pre-blending" used by the video planes with a dedicated -scaler and a "post-blending" to merge with the OSD Planes. -The OSD planes also have a dedicated scaler for one of the OSD. - -VENC: Video Encoders --------------------- - -The VENC is composed of the multiple pixel encoders : - - ENCI : Interlace Video encoder for CVBS and Interlace HDMI - - ENCP : Progressive Video Encoder for HDMI - - ENCL : LCD LVDS Encoder -The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock -tree and provides the scanout clock to the VPP and VIU. -The ENCI is connected to a single VDAC for Composite Output. -The ENCI and ENCP are connected to an on-chip HDMI Transceiver. - -Device Tree Bindings: ---------------------- - -VPU: Video Processing Unit --------------------------- - -Required properties: -- compatible: value should be different for each SoC family as : - - GXBB (S905) : "amlogic,meson-gxbb-vpu" - - GXL (S905X, S905D) : "amlogic,meson-gxl-vpu" - - GXM (S912) : "amlogic,meson-gxm-vpu" - followed by the common "amlogic,meson-gx-vpu" - - G12A (S905X2, S905Y2, S905D2) : "amlogic,meson-g12a-vpu" -- reg: base address and size of he following memory-mapped regions : - - vpu - - hhi -- reg-names: should contain the names of the previous memory regions -- interrupts: should contain the VENC Vsync interrupt number -- amlogic,canvas: phandle to canvas provider node as described in the file - ../soc/amlogic/amlogic,canvas.txt - -Optional properties: -- power-domains: Optional phandle to associated power domain as described in - the file ../power/power_domain.txt - -Required nodes: - -The connections to the VPU output video ports are modeled using the OF graph -bindings specified in Documentation/devicetree/bindings/graph.txt. - -The following table lists for each supported model the port number -corresponding to each VPU output. - - Port 0 Port 1 ------------------------------------------ - S905 (GXBB) CVBS VDAC HDMI-TX - S905X (GXL) CVBS VDAC HDMI-TX - S905D (GXL) CVBS VDAC HDMI-TX - S912 (GXM) CVBS VDAC HDMI-TX - S905X2 (G12A) CVBS VDAC HDMI-TX - S905Y2 (G12A) CVBS VDAC HDMI-TX - S905D2 (G12A) CVBS VDAC HDMI-TX - -Example: - -tv-connector { - compatible = "composite-video-connector"; - - port { - tv_connector_in: endpoint { - remote-endpoint = <&cvbs_vdac_out>; - }; - }; -}; - -vpu: vpu@d0100000 { - compatible = "amlogic,meson-gxbb-vpu"; - reg = <0x0 0xd0100000 0x0 0x100000>, - <0x0 0xc883c000 0x0 0x1000>, - <0x0 0xc8838000 0x0 0x1000>; - reg-names = "vpu", "hhi", "dmc"; - interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>; - #address-cells = <1>; - #size-cells = <0>; - - /* CVBS VDAC output port */ - port@0 { - reg = <0>; - - cvbs_vdac_out: endpoint { - remote-endpoint = <&tv_connector_in>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml new file mode 100644 index 000000000000..d1205a6697a0 --- /dev/null +++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml @@ -0,0 +1,137 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 BayLibre, SAS +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/display/amlogic,meson-vpu.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic Meson Display Controller + +maintainers: + - Neil Armstrong <narmstrong@baylibre.com> + +description: | + The Amlogic Meson Display controller is composed of several components + that are going to be documented below + + DMC|---------------VPU (Video Processing Unit)----------------|------HHI------| + | vd1 _______ _____________ _________________ | | + D |-------| |----| | | | | HDMI PLL | + D | vd2 | VIU | | Video Post | | Video Encoders |<---|-----VCLK | + R |-------| |----| Processing | | | | | + | osd2 | | | |---| Enci ----------|----|-----VDAC------| + R |-------| CSC |----| Scalers | | Encp ----------|----|----HDMI-TX----| + A | osd1 | | | Blenders | | Encl ----------|----|---------------| + M |-------|______|----|____________| |________________| | | + ___|__________________________________________________________|_______________| + + + VIU: Video Input Unit + --------------------- + + The Video Input Unit is in charge of the pixel scanout from the DDR memory. + It fetches the frames addresses, stride and parameters from the "Canvas" memory. + This part is also in charge of the CSC (Colorspace Conversion). + It can handle 2 OSD Planes and 2 Video Planes. + + VPP: Video Post Processing + -------------------------- + + The Video Post Processing is in charge of the scaling and blending of the + various planes into a single pixel stream. + There is a special "pre-blending" used by the video planes with a dedicated + scaler and a "post-blending" to merge with the OSD Planes. + The OSD planes also have a dedicated scaler for one of the OSD. + + VENC: Video Encoders + -------------------- + + The VENC is composed of the multiple pixel encoders + - ENCI : Interlace Video encoder for CVBS and Interlace HDMI + - ENCP : Progressive Video Encoder for HDMI + - ENCL : LCD LVDS Encoder + The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock + tree and provides the scanout clock to the VPP and VIU. + The ENCI is connected to a single VDAC for Composite Output. + The ENCI and ENCP are connected to an on-chip HDMI Transceiver. + +properties: + compatible: + oneOf: + - items: + - enum: + - amlogic,meson-gxbb-vpu # GXBB (S905) + - amlogic,meson-gxl-vpu # GXL (S905X, S905D) + - amlogic,meson-gxm-vpu # GXM (S912) + - const: amlogic,meson-gx-vpu + - enum: + - amlogic,meson-g12a-vpu # G12A (S905X2, S905Y2, S905D2) + + reg: + maxItems: 2 + + reg-names: + items: + - const: vpu + - const: hhi + + interrupts: + maxItems: 1 + + power-domains: + maxItems: 1 + description: phandle to the associated power domain + + port@0: + type: object + description: + A port node pointing to the CVBS VDAC port node. + + port@1: + type: object + description: + A port node pointing to the HDMI-TX port node. + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +required: + - compatible + - reg + - interrupts + - port@0 + - port@1 + - "#address-cells" + - "#size-cells" + +examples: + - | + vpu: vpu@d0100000 { + compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu"; + reg = <0xd0100000 0x100000>, <0xc883c000 0x1000>; + reg-names = "vpu", "hhi"; + interrupts = <3>; + #address-cells = <1>; + #size-cells = <0>; + + /* CVBS VDAC output port */ + port@0 { + reg = <0>; + + cvbs_vdac_out: endpoint { + remote-endpoint = <&tv_connector_in>; + }; + }; + + /* HDMI TX output port */ + port@1 { + reg = <1>; + + hdmi_tx_out: endpoint { + remote-endpoint = <&hdmi_tx_in>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/arm,pl11x.txt b/Documentation/devicetree/bindings/display/arm,pl11x.txt index 572fa2773ec4..3f977e72a200 100644 --- a/Documentation/devicetree/bindings/display/arm,pl11x.txt +++ b/Documentation/devicetree/bindings/display/arm,pl11x.txt @@ -39,9 +39,11 @@ Required sub-nodes: - port: describes LCD panel signals, following the common binding for video transmitter interfaces; see - Documentation/devicetree/bindings/media/video-interfaces.txt; - when it is a TFT panel, the port's endpoint must define the - following property: + Documentation/devicetree/bindings/media/video-interfaces.txt + +Deprecated properties: + The port's endbpoint subnode had this, now deprecated property + in the past. Drivers should be able to survive without it: - arm,pl11x,tft-r0g0b0-pads: an array of three 32-bit values, defining the way CLD pads are wired up; first value @@ -80,7 +82,6 @@ Example: port { clcd_pads: endpoint { remote-endpoint = <&clcd_panel>; - arm,pl11x,tft-r0g0b0-pads = <0 8 16>; }; }; diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt b/Documentation/devicetree/bindings/display/bridge/sii902x.txt index 2df44b7d3821..6e14e087c0d0 100644 --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt @@ -26,9 +26,8 @@ Optional properties: - clocks: phandle and clock specifier for each clock listed in the clock-names property - clock-names: "mclk" - Describes SII902x MCLK input. MCLK is used to produce - HDMI audio CTS values. This property is required if - "#sound-dai-cells"-property is present. This property follows + Describes SII902x MCLK input. MCLK can be used to produce + HDMI audio CTS values. This property follows Documentation/devicetree/bindings/clock/clock-bindings.txt consumer binding. diff --git a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt index 508aee461e0d..aeb07c4bd703 100644 --- a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt +++ b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt @@ -9,6 +9,7 @@ Optional properties: - label: a symbolic name for the connector - hpd-gpios: HPD GPIO number - ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID probing +- ddc-en-gpios: signal to enable DDC bus Required nodes: - Video port for HDMI input diff --git a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt deleted file mode 100644 index 6812280cb109..000000000000 --- a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt +++ /dev/null @@ -1,26 +0,0 @@ -Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. - -Required properties: -- compatible: should be "ampire,am-480272h3tmqw-t01h" - -Optional properties: -- power-supply: regulator to provide the supply voltage -- enable-gpios: GPIO pin to enable or disable the panel -- backlight: phandle of the backlight device attached to the panel - -Optional nodes: -- Video port for RGB input. - -Example: - panel_rgb: panel-rgb { - compatible = "ampire,am-480272h3tmqw-t01h"; - enable-gpios = <&gpioa 8 1>; - port { - panel_in_rgb: endpoint { - remote-endpoint = <&controller_out_rgb>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml new file mode 100644 index 000000000000..c6e33e7f36d0 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/ampire,am-480272h3tmqw-t01h.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel + +maintainers: + - Yannick Fertre <yannick.fertre@st.com> + - Thierry Reding <treding@nvidia.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: ampire,am-480272h3tmqw-t01h + + power-supply: true + enable-gpios: true + backlight: true + port: true + +required: + - compatible + +additionalProperties: false + +examples: + - | + panel_rgb: panel { + compatible = "ampire,am-480272h3tmqw-t01h"; + enable-gpios = <&gpioa 8 1>; + port { + panel_in_rgb: endpoint { + remote-endpoint = <&controller_out_rgb>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt index 248141c3c7e3..0601a9e34703 100644 --- a/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt +++ b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt @@ -10,7 +10,7 @@ Required properties: - compatible: should be "arm,versatile-tft-panel" Required subnodes: -- port: see display/panel/panel-common.txt, graph.txt +- port: see display/panel/panel-common.yaml, graph.txt Example: diff --git a/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt b/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt deleted file mode 100644 index a30d63db3c8f..000000000000 --- a/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt +++ /dev/null @@ -1,9 +0,0 @@ -Armadeus ST0700 Adapt. A Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT with -an adapter board. - -Required properties: -- compatible: "armadeus,st0700-adapt" -- power-supply: see panel-common.txt - -Optional properties: -- backlight: see panel-common.txt diff --git a/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.yaml b/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.yaml new file mode 100644 index 000000000000..a6ade47066b3 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/armadeus,st0700-adapt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Armadeus ST0700 Adapter + +description: + A Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT with an adapter board. + +maintainers: + - '"Sébastien Szymanski" <sebastien.szymanski@armadeus.com>' + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: armadeus,st0700-adapt + + power-supply: true + backlight: true + port: true + +additionalProperties: false + +required: + - compatible + - power-supply + +... diff --git a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt deleted file mode 100644 index 35bc0c839f49..000000000000 --- a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt +++ /dev/null @@ -1,12 +0,0 @@ -Banana Pi 7" (S070WV20-CT16) TFT LCD Panel - -Required properties: -- compatible: should be "bananapi,s070wv20-ct16" -- power-supply: see ./panel-common.txt - -Optional properties: -- enable-gpios: see ./simple-panel.txt -- backlight: see ./simple-panel.txt - -This binding is compatible with the simple-panel binding, which is specified -in ./simple-panel.txt. diff --git a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.yaml b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.yaml new file mode 100644 index 000000000000..bbf127fb28f7 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.yaml @@ -0,0 +1,31 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/bananapi,s070wv20-ct16.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Banana Pi 7" (S070WV20-CT16) TFT LCD Panel + +maintainers: + - Chen-Yu Tsai <wens@csie.org> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: bananapi,s070wv20-ct16 + + power-supply: true + backlight: true + enable-gpios: true + port: true + +additionalProperties: false + +required: + - compatible + - power-supply + +... diff --git a/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt new file mode 100644 index 000000000000..3caea2172b1b --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt @@ -0,0 +1,24 @@ +Boe Himax8279d 1200x1920 TFT LCD panel + +Required properties: +- compatible: should be "boe,himax8279d8p" and one of: "boe,himax8279d10p" +- reg: DSI virtual channel of the peripheral +- enable-gpios: panel enable gpio +- pp33-gpios: a GPIO phandle for the 3.3v pin that provides the supply voltage +- pp18-gpios: a GPIO phandle for the 1.8v pin that provides the supply voltage + +Optional properties: +- backlight: phandle of the backlight device attached to the panel + +Example: + + &mipi_dsi { + panel { + compatible = "boe,himax8279d8p", "boe,himax8279d10p"; + reg = <0>; + backlight = <&backlight>; + enable-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>; + pp33-gpios = <&gpio 35 GPIO_ACTIVE_HIGH>; + pp18-gpios = <&gpio 36 GPIO_ACTIVE_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt b/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt deleted file mode 100644 index bf06bb025b08..000000000000 --- a/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt +++ /dev/null @@ -1,13 +0,0 @@ -DLC Display Co. DLC0700YZG-1 7.0" WSVGA TFT LCD panel - -Required properties: -- compatible: should be "dlc,dlc0700yzg-1" -- power-supply: See simple-panel.txt - -Optional properties: -- reset-gpios: See panel-common.txt -- enable-gpios: See simple-panel.txt -- backlight: See simple-panel.txt - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.yaml b/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.yaml new file mode 100644 index 000000000000..287e2feb6533 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.yaml @@ -0,0 +1,31 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/dlc,dlc0700yzg-1.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DLC Display Co. DLC0700YZG-1 7.0" WSVGA TFT LCD panel + +maintainers: + - Philipp Zabel <p.zabel@pengutronix.de> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: dlc,dlc0700yzg-1 + + reset-gpios: true + enable-gpios: true + backlight: true + port: true + +additionalProperties: false + +required: + - compatible + - power-supply + +... diff --git a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt index be8684327ee4..b7ac1c725f97 100644 --- a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt +++ b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt @@ -40,7 +40,7 @@ simple-panel.txt | Identifier | compatbile | description | +=================+=====================+=====================================+ | ETM0700G0DH6 | edt,etm070080dh6 | WVGA TFT Display with capacitive | -| | | Touchscreen | +| | edt,etm0700g0dh6 | Touchscreen | +-----------------+---------------------+-------------------------------------+ | ETM0700G0BDH6 | edt,etm070080bdh6 | Same as ETM0700G0DH6 but with | | | | inverted pixel clock. | diff --git a/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt b/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt new file mode 100644 index 000000000000..3dab52f92c26 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt @@ -0,0 +1,12 @@ +GiantPlus 3.0" (320x240 pixels) 24-bit TFT LCD panel + +Required properties: +- compatible: should be "giantplus,gpm940b0" +- power-supply: as specified in the base binding + +Optional properties: +- backlight: as specified in the base binding +- enable-gpios: as specified in the base binding + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt deleted file mode 100644 index e5ca4ccd55ed..000000000000 --- a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt +++ /dev/null @@ -1,7 +0,0 @@ -Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel - -Required properties: -- compatible: should be "innolux,ee101ia-01d" - -This binding is compatible with the lvds-panel binding, which is specified -in panel-lvds.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml new file mode 100644 index 000000000000..a69681e724cb --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml @@ -0,0 +1,31 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/innolux,ee101ia-01d.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel + +maintainers: + - Heiko Stuebner <heiko.stuebner@bq.com> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: lvds.yaml# + +properties: + compatible: + items: + - const: innolux,ee101ia-01d + - {} # panel-lvds, but not listed here to avoid false select + + backlight: true + enable-gpios: true + power-supply: true + width-mm: true + height-mm: true + panel-timing: true + port: true + +additionalProperties: false +... diff --git a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt new file mode 100644 index 000000000000..fa9596082e44 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt @@ -0,0 +1,42 @@ +King Display KD035G6-54NT 3.5" (320x240 pixels) 24-bit TFT LCD panel + +Required properties: +- compatible: should be "kingdisplay,kd035g6-54nt" +- power-supply: See panel-common.txt +- reset-gpios: See panel-common.txt + +Optional properties: +- backlight: see panel-common.txt + +The generic bindings for the SPI slaves documented in [1] also apply. + +The device node can contain one 'port' child node with one child +'endpoint' node, according to the bindings defined in [2]. This +node should describe panel's video bus. + +[1]: Documentation/devicetree/bindings/spi/spi-bus.txt +[2]: Documentation/devicetree/bindings/graph.txt + +Example: + +&spi { + panel@0 { + compatible = "kingdisplay,kd035g6-54nt"; + reg = <0>; + + spi-max-frequency = <3125000>; + spi-3wire; + spi-cs-high; + + reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>; + + backlight = <&backlight>; + power-supply = <&ldo6>; + + port { + panel_input: endpoint { + remote-endpoint = <&panel_output>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml b/Documentation/devicetree/bindings/display/panel/lvds.yaml new file mode 100644 index 000000000000..d0083301acbe --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml @@ -0,0 +1,107 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/lvds.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LVDS Display Panel + +maintainers: + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> + - Thierry Reding <thierry.reding@gmail.com> + +description: |+ + LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple + incompatible data link layers have been used over time to transmit image data + to LVDS panels. This bindings supports display panels compatible with the + following specifications. + + [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February + 1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA) + [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National + Semiconductor + [VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video + Electronics Standards Association (VESA) + + Device compatible with those specifications have been marketed under the + FPD-Link and FlatLink brands. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + contains: + const: panel-lvds + description: + Shall contain "panel-lvds" in addition to a mandatory panel-specific + compatible string defined in individual panel bindings. The "panel-lvds" + value shall never be used on its own. + + data-mapping: + enum: + - jeida-18 + - jeida-24 + - vesa-24 + description: | + The color signals mapping order. + + LVDS data mappings are defined as follows. + + - "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and + [VESA] specifications. Data are transferred as follows on 3 LVDS lanes. + + Slot 0 1 2 3 4 5 6 + ________________ _________________ + Clock \_______________________/ + ______ ______ ______ ______ ______ ______ ______ + DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< + DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< + + - "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI] + specifications. Data are transferred as follows on 4 LVDS lanes. + + Slot 0 1 2 3 4 5 6 + ________________ _________________ + Clock \_______________________/ + ______ ______ ______ ______ ______ ______ ______ + DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__>< + DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__>< + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__>< + DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__>< + + - "vesa-24" - 24-bit data mapping compatible with the [VESA] specification. + Data are transferred as follows on 4 LVDS lanes. + + Slot 0 1 2 3 4 5 6 + ________________ _________________ + Clock \_______________________/ + ______ ______ ______ ______ ______ ______ ______ + DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< + DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< + DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__>< + + Control signals are mapped as follows. + + CTL0: HSync + CTL1: VSync + CTL2: Data Enable + CTL3: 0 + + data-mirror: + type: boolean + description: + If set, reverse the bit order described in the data mappings below on all + data lanes, transmitting bits for slots 6 to 0 instead of 0 to 6. + +required: + - compatible + - data-mapping + - width-mm + - height-mm + - panel-timing + - port + +... diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.txt b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.txt deleted file mode 100644 index ced0121aed7d..000000000000 --- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.txt +++ /dev/null @@ -1,47 +0,0 @@ -Mitsubishi AA204XD12 LVDS Display Panel -======================================= - -The AA104XD12 is a 10.4" XGA TFT-LCD display panel. - -These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt -with the following device-specific properties. - - -Required properties: - -- compatible: Shall contain "mitsubishi,aa121td01" and "panel-lvds", in that - order. -- vcc-supply: Reference to the regulator powering the panel VCC pins. - - -Example -------- - -panel { - compatible = "mitsubishi,aa104xd12", "panel-lvds"; - vcc-supply = <&vcc_3v3>; - - width-mm = <210>; - height-mm = <158>; - - data-mapping = "jeida-24"; - - panel-timing { - /* 1024x768 @65Hz */ - clock-frequency = <65000000>; - hactive = <1024>; - vactive = <768>; - hsync-len = <136>; - hfront-porch = <20>; - hback-porch = <160>; - vfront-porch = <3>; - vback-porch = <29>; - vsync-len = <6>; - }; - - port { - panel_in: endpoint { - remote-endpoint = <&lvds_encoder>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml new file mode 100644 index 000000000000..b5e7ee230fa6 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/mitsubishi,aa104xd12.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mitsubishi AA104XD12 10.4" XGA LVDS Display Panel + +maintainers: + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: lvds.yaml# + +properties: + compatible: + items: + - const: mitsubishi,aa104xd12 + - {} # panel-lvds, but not listed here to avoid false select + + vcc-supply: + description: Reference to the regulator powering the panel VCC pins. + + data-mapping: + const: jeida-24 + + width-mm: + const: 210 + + height-mm: + const: 158 + + panel-timing: true + port: true + +additionalProperties: false + +required: + - compatible + - vcc-supply + +examples: + - |+ + + panel { + compatible = "mitsubishi,aa104xd12", "panel-lvds"; + vcc-supply = <&vcc_3v3>; + + width-mm = <210>; + height-mm = <158>; + + data-mapping = "jeida-24"; + + panel-timing { + /* 1024x768 @65Hz */ + clock-frequency = <65000000>; + hactive = <1024>; + vactive = <768>; + hsync-len = <136>; + hfront-porch = <20>; + hback-porch = <160>; + vfront-porch = <3>; + vback-porch = <29>; + vsync-len = <6>; + }; + + port { + panel_in: endpoint { + remote-endpoint = <&lvds_encoder>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.txt b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.txt deleted file mode 100644 index d6e1097504fe..000000000000 --- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.txt +++ /dev/null @@ -1,47 +0,0 @@ -Mitsubishi AA121TD01 LVDS Display Panel -======================================= - -The AA121TD01 is a 12.1" WXGA TFT-LCD display panel. - -These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt -with the following device-specific properties. - - -Required properties: - -- compatible: Shall contain "mitsubishi,aa121td01" and "panel-lvds", in that - order. -- vcc-supply: Reference to the regulator powering the panel VCC pins. - - -Example -------- - -panel { - compatible = "mitsubishi,aa121td01", "panel-lvds"; - vcc-supply = <&vcc_3v3>; - - width-mm = <261>; - height-mm = <163>; - - data-mapping = "jeida-24"; - - panel-timing { - /* 1280x800 @60Hz */ - clock-frequency = <71000000>; - hactive = <1280>; - vactive = <800>; - hsync-len = <70>; - hfront-porch = <20>; - hback-porch = <70>; - vsync-len = <5>; - vfront-porch = <3>; - vback-porch = <15>; - }; - - port { - panel_in: endpoint { - remote-endpoint = <&lvds_encoder>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml new file mode 100644 index 000000000000..977c50a85b67 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/mitsubishi,aa121td01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mitsubishi AA121TD01 12.1" WXGA LVDS Display Panel + +maintainers: + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: lvds.yaml# + +properties: + compatible: + items: + - const: mitsubishi,aa121td01 + - {} # panel-lvds, but not listed here to avoid false select + + vcc-supply: + description: Reference to the regulator powering the panel VCC pins. + + data-mapping: + const: jeida-24 + + width-mm: + const: 261 + + height-mm: + const: 163 + + panel-timing: true + port: true + +additionalProperties: false + +required: + - compatible + - vcc-supply + +examples: + - |+ + panel { + compatible = "mitsubishi,aa121td01", "panel-lvds"; + vcc-supply = <&vcc_3v3>; + + width-mm = <261>; + height-mm = <163>; + + data-mapping = "jeida-24"; + + panel-timing { + /* 1280x800 @60Hz */ + clock-frequency = <71000000>; + hactive = <1280>; + vactive = <800>; + hsync-len = <70>; + hfront-porch = <20>; + hback-porch = <70>; + vsync-len = <5>; + vfront-porch = <3>; + vback-porch = <15>; + }; + + port { + panel_in: endpoint { + remote-endpoint = <&lvds_encoder>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml b/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml new file mode 100644 index 000000000000..aa788eaa2f71 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/nec,nl8048hl11.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NEC NL8048HL11 4.1" WVGA TFT LCD panel + +description: + The NEC NL8048HL11 is a 4.1" WVGA TFT LCD panel with a 24-bit RGB parallel + data interface and an SPI control interface. + +maintainers: + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: nec,nl8048hl11 + + label: true + port: true + reg: true + reset-gpios: true + + spi-max-frequency: + maximum: 10000000 + +required: + - compatible + - reg + - reset-gpios + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + lcd_panel: panel@0 { + compatible = "nec,nl8048hl11"; + reg = <0>; + spi-max-frequency = <10000000>; + + reset-gpios = <&gpio7 7 GPIO_ACTIVE_LOW>; + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/ortustech,com37h3m05dtc.txt b/Documentation/devicetree/bindings/display/panel/ortustech,com37h3m05dtc.txt new file mode 100644 index 000000000000..c16907c02f80 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/ortustech,com37h3m05dtc.txt @@ -0,0 +1,12 @@ +OrtusTech COM37H3M05DTC Blanview 3.7" VGA portrait TFT-LCD panel + +Required properties: +- compatible: should be "ortustech,com37h3m05dtc" + +Optional properties: +- enable-gpios: GPIO pin to enable or disable the panel +- backlight: phandle of the backlight device attached to the panel +- power-supply: phandle of the regulator that provides the supply voltage + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/ortustech,com37h3m99dtc.txt b/Documentation/devicetree/bindings/display/panel/ortustech,com37h3m99dtc.txt new file mode 100644 index 000000000000..06a73c3f46b5 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/ortustech,com37h3m99dtc.txt @@ -0,0 +1,12 @@ +OrtusTech COM37H3M99DTC Blanview 3.7" VGA portrait TFT-LCD panel + +Required properties: +- compatible: should be "ortustech,com37h3m99dtc" + +Optional properties: +- enable-gpios: GPIO pin to enable or disable the panel +- backlight: phandle of the backlight device attached to the panel +- power-supply: phandle of the regulator that provides the supply voltage + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.txt b/Documentation/devicetree/bindings/display/panel/panel-common.txt deleted file mode 100644 index 5d2519af4bb5..000000000000 --- a/Documentation/devicetree/bindings/display/panel/panel-common.txt +++ /dev/null @@ -1,101 +0,0 @@ -Common Properties for Display Panel -=================================== - -This document defines device tree properties common to several classes of -display panels. It doesn't constitue a device tree binding specification by -itself but is meant to be referenced by device tree bindings. - -When referenced from panel device tree bindings the properties defined in this -document are defined as follows. The panel device tree bindings are -responsible for defining whether each property is required or optional. - - -Descriptive Properties ----------------------- - -- width-mm, -- height-mm: The width-mm and height-mm specify the width and height of the - physical area where images are displayed. These properties are expressed in - millimeters and rounded to the closest unit. - -- label: The label property specifies a symbolic name for the panel as a - string suitable for use by humans. It typically contains a name inscribed on - the system (e.g. as an affixed label) or specified in the system's - documentation (e.g. in the user's manual). - - If no such name exists, and unless the property is mandatory according to - device tree bindings, it shall rather be omitted than constructed of - non-descriptive information. For instance an LCD panel in a system that - contains a single panel shall not be labelled "LCD" if that name is not - inscribed on the system or used in a descriptive fashion in system - documentation. - - -Display Timings ---------------- - -- panel-timing: Most display panels are restricted to a single resolution and - require specific display timings. The panel-timing subnode expresses those - timings as specified in the timing subnode section of the display timing - bindings defined in - Documentation/devicetree/bindings/display/panel/display-timing.txt. - - -Connectivity ------------- - -- ports: Panels receive video data through one or multiple connections. While - the nature of those connections is specific to the panel type, the - connectivity is expressed in a standard fashion using ports as specified in - the device graph bindings defined in - Documentation/devicetree/bindings/graph.txt. - -- ddc-i2c-bus: Some panels expose EDID information through an I2C-compatible - bus such as DDC2 or E-DDC. For such panels the ddc-i2c-bus contains a - phandle to the system I2C controller connected to that bus. - - -Control I/Os ------------- - -Many display panels can be controlled through pins driven by GPIOs. The nature -and timing of those control signals are device-specific and left for panel -device tree bindings to specify. The following GPIO specifiers can however be -used for panels that implement compatible control signals. - -- enable-gpios: Specifier for a GPIO connected to the panel enable control - signal. The enable signal is active high and enables operation of the panel. - This property can also be used for panels implementing an active low power - down signal, which is a negated version of the enable signal. Active low - enable signals (or active high power down signals) can be supported by - inverting the GPIO specifier polarity flag. - - Note that the enable signal control panel operation only and must not be - confused with a backlight enable signal. - -- reset-gpios: Specifier for a GPIO coonnected to the panel reset control - signal. The reset signal is active low and resets the panel internal logic - while active. Active high reset signals can be supported by inverting the - GPIO specifier polarity flag. - -Power ------ - -- power-supply: display panels require power to be supplied. While several - panels need more than one power supply with panel-specific constraints - governing the order and timings of the power supplies, in many cases a single - power supply is sufficient, either because the panel has a single power rail, - or because all its power rails can be driven by the same supply. In that case - the power-supply property specifies the supply powering the panel as a phandle - to a regulator. - -Backlight ---------- - -Most display panels include a backlight. Some of them also include a backlight -controller exposed through a control bus such as I2C or DSI. Others expose -backlight control through GPIO, PWM or other signals connected to an external -backlight controller. - -- backlight: For panels whose backlight is controlled by an external backlight - controller, this property contains a phandle that references the controller. diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml new file mode 100644 index 000000000000..ef8d8cdfcede --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml @@ -0,0 +1,149 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/panel-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common Properties for Display Panels + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> + +description: | + This document defines device tree properties common to several classes of + display panels. It doesn't constitue a device tree binding specification by + itself but is meant to be referenced by device tree bindings. + + When referenced from panel device tree bindings the properties defined in this + document are defined as follows. The panel device tree bindings are + responsible for defining whether each property is required or optional. + +properties: + # Descriptive Properties + width-mm: + description: + Specifies the width of the physical area where images are displayed. This + property is expressed in millimeters and rounded to the closest unit. + + height-mm: + description: + Specifies the height of the physical area where images are displayed. This + property is expressed in millimeters and rounded to the closest unit. + + label: + description: | + The label property specifies a symbolic name for the panel as a + string suitable for use by humans. It typically contains a name inscribed + on the system (e.g. as an affixed label) or specified in the system's + documentation (e.g. in the user's manual). + + If no such name exists, and unless the property is mandatory according to + device tree bindings, it shall rather be omitted than constructed of + non-descriptive information. For instance an LCD panel in a system that + contains a single panel shall not be labelled "LCD" if that name is not + inscribed on the system or used in a descriptive fashion in system + documentation. + + rotation: + description: + Display rotation in degrees counter clockwise (0,90,180,270) + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - enum: [ 0, 90, 180, 270 ] + + # Display Timings + panel-timing: + type: object + description: + Most display panels are restricted to a single resolution and + require specific display timings. The panel-timing subnode expresses those + timings as specified in the timing subnode section of the display timing + bindings defined in + Documentation/devicetree/bindings/display/panel/display-timing.txt. + + # Connectivity + port: + type: object + + ports: + type: object + description: + Panels receive video data through one or multiple connections. While + the nature of those connections is specific to the panel type, the + connectivity is expressed in a standard fashion using ports as specified + in the device graph bindings defined in + Documentation/devicetree/bindings/graph.txt. + + ddc-i2c-bus: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Some panels expose EDID information through an I2C-compatible + bus such as DDC2 or E-DDC. For such panels the ddc-i2c-bus contains a + phandle to the system I2C controller connected to that bus. + + no-hpd: + type: boolean + description: + This panel is supposed to communicate that it's ready via HPD + (hot plug detect) signal, but the signal isn't hooked up so we should + hardcode the max delay from the panel spec when powering up the panel. + + # Control I/Os + + # Many display panels can be controlled through pins driven by GPIOs. The nature + # and timing of those control signals are device-specific and left for panel + # device tree bindings to specify. The following GPIO specifiers can however be + # used for panels that implement compatible control signals. + + enable-gpios: + maxItems: 1 + description: | + Specifier for a GPIO connected to the panel enable control signal. The + enable signal is active high and enables operation of the panel. This + property can also be used for panels implementing an active low power down + signal, which is a negated version of the enable signal. Active low enable + signals (or active high power down signals) can be supported by inverting + the GPIO specifier polarity flag. + + Note that the enable signal control panel operation only and must not be + confused with a backlight enable signal. + + reset-gpios: + maxItems: 1 + description: + Specifier for a GPIO connected to the panel reset control signal. + The reset signal is active low and resets the panel internal logic + while active. Active high reset signals can be supported by inverting the + GPIO specifier polarity flag. + + # Power + power-supply: + description: + Display panels require power to be supplied. While several panels need + more than one power supply with panel-specific constraints governing the + order and timings of the power supplies, in many cases a single power + supply is sufficient, either because the panel has a single power rail, or + because all its power rails can be driven by the same supply. In that case + the power-supply property specifies the supply powering the panel as a + phandle to a regulator. + + # Backlight + + # Most display panels include a backlight. Some of them also include a backlight + # controller exposed through a control bus such as I2C or DSI. Others expose + # backlight control through GPIO, PWM or other signals connected to an external + # backlight controller. + + backlight: + $ref: /schemas/types.yaml#/definitions/phandle + description: + For panels whose backlight is controlled by an external backlight + controller, this property contains a phandle that references the + controller. + +dependencies: + width-mm: [ height-mm ] + height-mm: [ width-mm ] + +... diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt deleted file mode 100644 index 250850a2150b..000000000000 --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt +++ /dev/null @@ -1,121 +0,0 @@ -LVDS Display Panel -================== - -LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple -incompatible data link layers have been used over time to transmit image data -to LVDS panels. This bindings supports display panels compatible with the -following specifications. - -[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February -1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA) -[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National -Semiconductor -[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video -Electronics Standards Association (VESA) - -Device compatible with those specifications have been marketed under the -FPD-Link and FlatLink brands. - - -Required properties: - -- compatible: Shall contain "panel-lvds" in addition to a mandatory - panel-specific compatible string defined in individual panel bindings. The - "panel-lvds" value shall never be used on its own. -- width-mm: See panel-common.txt. -- height-mm: See panel-common.txt. -- data-mapping: The color signals mapping order, "jeida-18", "jeida-24" - or "vesa-24". - -Optional properties: - -- label: See panel-common.txt. -- gpios: See panel-common.txt. -- backlight: See panel-common.txt. -- power-supply: See panel-common.txt. -- data-mirror: If set, reverse the bit order described in the data mappings - below on all data lanes, transmitting bits for slots 6 to 0 instead of - 0 to 6. - -Required nodes: - -- panel-timing: See panel-common.txt. -- ports: See panel-common.txt. These bindings require a single port subnode - corresponding to the panel LVDS input. - - -LVDS data mappings are defined as follows. - -- "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and - [VESA] specifications. Data are transferred as follows on 3 LVDS lanes. - -Slot 0 1 2 3 4 5 6 - ________________ _________________ -Clock \_______________________/ - ______ ______ ______ ______ ______ ______ ______ -DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< -DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< -DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< - -- "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI] - specifications. Data are transferred as follows on 4 LVDS lanes. - -Slot 0 1 2 3 4 5 6 - ________________ _________________ -Clock \_______________________/ - ______ ______ ______ ______ ______ ______ ______ -DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__>< -DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__>< -DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__>< -DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__>< - -- "vesa-24" - 24-bit data mapping compatible with the [VESA] specification. - Data are transferred as follows on 4 LVDS lanes. - -Slot 0 1 2 3 4 5 6 - ________________ _________________ -Clock \_______________________/ - ______ ______ ______ ______ ______ ______ ______ -DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< -DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< -DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< -DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__>< - -Control signals are mapped as follows. - -CTL0: HSync -CTL1: VSync -CTL2: Data Enable -CTL3: 0 - - -Example -------- - -panel { - compatible = "mitsubishi,aa121td01", "panel-lvds"; - - width-mm = <261>; - height-mm = <163>; - - data-mapping = "jeida-24"; - - panel-timing { - /* 1280x800 @60Hz */ - clock-frequency = <71000000>; - hactive = <1280>; - vactive = <800>; - hsync-len = <70>; - hfront-porch = <20>; - hback-porch = <70>; - vsync-len = <5>; - vfront-porch = <3>; - vback-porch = <15>; - }; - - port { - panel_in: endpoint { - remote-endpoint = <&lvds_encoder>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/panel/panel.txt b/Documentation/devicetree/bindings/display/panel/panel.txt deleted file mode 100644 index e2e6867852b8..000000000000 --- a/Documentation/devicetree/bindings/display/panel/panel.txt +++ /dev/null @@ -1,4 +0,0 @@ -Common display properties -------------------------- - -- rotation: Display rotation in degrees counter clockwise (0,90,180,270) diff --git a/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt b/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt deleted file mode 100644 index 1639fb17a9f0..000000000000 --- a/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt +++ /dev/null @@ -1,14 +0,0 @@ -PDA 91-00156-A0 5.0" WVGA TFT LCD panel - -Required properties: -- compatible: should be "pda,91-00156-a0" -- power-supply: this panel requires a single power supply. A phandle to a -regulator needs to be specified here. Compatible with panel-common binding which -is specified in the panel-common.txt in this directory. -- backlight: this panel's backlight is controlled by an external backlight -controller. A phandle to this controller needs to be specified here. -Compatible with panel-common binding which is specified in the panel-common.txt -in this directory. - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.yaml b/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.yaml new file mode 100644 index 000000000000..ccd3623b4955 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.yaml @@ -0,0 +1,31 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/pda,91-00156-a0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PDA 91-00156-A0 5.0" WVGA TFT LCD panel + +maintainers: + - Cristian Birsan <cristian.birsan@microchip.com> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: pda,91-00156-a0 + + power-supply: true + backlight: true + port: true + +additionalProperties: false + +required: + - compatible + - power-supply + - backlight + +... diff --git a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt deleted file mode 100644 index e9e19c059260..000000000000 --- a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt +++ /dev/null @@ -1,49 +0,0 @@ -This binding covers the official 7" (800x480) Raspberry Pi touchscreen -panel. - -This DSI panel contains: - -- TC358762 DSI->DPI bridge -- Atmel microcontroller on I2C for power sequencing the DSI bridge and - controlling backlight -- Touchscreen controller on I2C for touch input - -and this binding covers the DSI display parts but not its touch input. - -Required properties: -- compatible: Must be "raspberrypi,7inch-touchscreen-panel" -- reg: Must be "45" -- port: See panel-common.txt - -Example: - -dsi1: dsi@7e700000 { - #address-cells = <1>; - #size-cells = <0>; - <...> - - port { - dsi_out_port: endpoint { - remote-endpoint = <&panel_dsi_port>; - }; - }; -}; - -i2c_dsi: i2c { - compatible = "i2c-gpio"; - #address-cells = <1>; - #size-cells = <0>; - gpios = <&gpio 28 0 - &gpio 29 0>; - - lcd@45 { - compatible = "raspberrypi,7inch-touchscreen-panel"; - reg = <0x45>; - - port { - panel_dsi_port: endpoint { - remote-endpoint = <&dsi_out_port>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml new file mode 100644 index 000000000000..22a083f7bc8e --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/raspberrypi,7inch-touchscreen.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: The official 7" (800x480) Raspberry Pi touchscreen + +maintainers: + - Eric Anholt <eric@anholt.net> + - Thierry Reding <thierry.reding@gmail.com> + +description: |+ + This DSI panel contains: + + - TC358762 DSI->DPI bridge + - Atmel microcontroller on I2C for power sequencing the DSI bridge and + controlling backlight + - Touchscreen controller on I2C for touch input + + and this binding covers the DSI display parts but not its touch input. + +properties: + compatible: + const: raspberrypi,7inch-touchscreen-panel + + reg: + const: 0x45 + + port: true + +required: + - compatible + - reg + - port + +additionalProperties: false + +examples: + - |+ + dsi1: dsi { + #address-cells = <1>; + #size-cells = <0>; + + port { + dsi_out_port: endpoint { + remote-endpoint = <&panel_dsi_port>; + }; + }; + }; + + i2c_dsi: i2c { + compatible = "i2c-gpio"; + #address-cells = <1>; + #size-cells = <0>; + scl-gpios = <&gpio 28 0>; + sda-gpios = <&gpio 29 0>; + + lcd@45 { + compatible = "raspberrypi,7inch-touchscreen-panel"; + reg = <0x45>; + + port { + panel_dsi_port: endpoint { + remote-endpoint = <&dsi_out_port>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt new file mode 100644 index 000000000000..10424695aa02 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt @@ -0,0 +1,41 @@ +Raydium RM67171 OLED LCD panel with MIPI-DSI protocol + +Required properties: +- compatible: "raydium,rm67191" +- reg: virtual channel for MIPI-DSI protocol + must be <0> +- dsi-lanes: number of DSI lanes to be used + must be <3> or <4> +- port: input port node with endpoint definition as + defined in Documentation/devicetree/bindings/graph.txt; + the input port should be connected to a MIPI-DSI device + driver + +Optional properties: +- reset-gpios: a GPIO spec for the RST_B GPIO pin +- v3p3-supply: phandle to 3.3V regulator that powers the VDD_3V3 pin +- v1p8-supply: phandle to 1.8V regulator that powers the VDD_1V8 pin +- width-mm: see panel-common.txt +- height-mm: see panel-common.txt +- video-mode: 0 - burst-mode + 1 - non-burst with sync event + 2 - non-burst with sync pulse + +Example: + + panel@0 { + compatible = "raydium,rm67191"; + reg = <0>; + pinctrl-0 = <&pinctrl_mipi_dsi_0_1_en>; + pinctrl-names = "default"; + reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>; + dsi-lanes = <4>; + width-mm = <68>; + height-mm = <121>; + + port { + panel_in: endpoint { + remote-endpoint = <&mipi_out>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt index 1b5763200cf6..a372c5d84695 100644 --- a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt +++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt @@ -5,6 +5,9 @@ Required properties: - reg: DSI virtual channel of the peripheral - reset-gpios: panel reset gpio - backlight: phandle of the backlight device attached to the panel +- vcc-supply: phandle of the regulator that provides the vcc supply voltage. +- iovcc-supply: phandle of the regulator that provides the iovcc supply + voltage. Example: @@ -14,5 +17,7 @@ Example: reg = <0>; backlight = <&backlight>; reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>; + vcc-supply = <®_2v8_p>; + iovcc-supply = <®_1v8_p>; }; }; diff --git a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt deleted file mode 100644 index d06644b555bd..000000000000 --- a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt +++ /dev/null @@ -1,41 +0,0 @@ -Solomon Goldentek Display GKTW70SDAE4SE LVDS Display Panel -========================================================== - -The GKTW70SDAE4SE is a 7" WVGA TFT-LCD display panel. - -These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt -with the following device-specific properties. - -Required properties: - -- compatible: Shall contain "sgd,gktw70sdae4se" and "panel-lvds", in that order. - -Example -------- - -panel { - compatible = "sgd,gktw70sdae4se", "panel-lvds"; - - width-mm = <153>; - height-mm = <86>; - - data-mapping = "jeida-18"; - - panel-timing { - clock-frequency = <32000000>; - hactive = <800>; - vactive = <480>; - hback-porch = <39>; - hfront-porch = <39>; - vback-porch = <29>; - vfront-porch = <13>; - hsync-len = <47>; - vsync-len = <2>; - }; - - port { - panel_in: endpoint { - remote-endpoint = <&lvds_encoder>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml new file mode 100644 index 000000000000..e63a570ae59d --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/sgd,gktw70sdae4se.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Solomon Goldentek Display GKTW70SDAE4SE 7" WVGA LVDS Display Panel + +maintainers: + - Neil Armstrong <narmstrong@baylibre.com> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: lvds.yaml# + +properties: + compatible: + items: + - const: sgd,gktw70sdae4se + - {} # panel-lvds, but not listed here to avoid false select + + data-mapping: + const: jeida-18 + + width-mm: + const: 153 + + height-mm: + const: 86 + + panel-timing: true + port: true + +additionalProperties: false + +required: + - compatible + +examples: + - |+ + panel { + compatible = "sgd,gktw70sdae4se", "panel-lvds"; + + width-mm = <153>; + height-mm = <86>; + + data-mapping = "jeida-18"; + + panel-timing { + clock-frequency = <32000000>; + hactive = <800>; + vactive = <480>; + hback-porch = <39>; + hfront-porch = <39>; + vback-porch = <29>; + vfront-porch = <13>; + hsync-len = <47>; + vsync-len = <2>; + }; + + port { + panel_in: endpoint { + remote-endpoint = <&lvds_encoder>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/sharp,ld-d5116z01b.txt b/Documentation/devicetree/bindings/display/panel/sharp,ld-d5116z01b.txt new file mode 100644 index 000000000000..fd9cf39bde77 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sharp,ld-d5116z01b.txt @@ -0,0 +1,26 @@ +Sharp LD-D5116Z01B 12.3" WUXGA+ eDP panel + +Required properties: +- compatible: should be "sharp,ld-d5116z01b" +- power-supply: regulator to provide the VCC supply voltage (3.3 volts) + +This binding is compatible with the simple-panel binding. + +The device node can contain one 'port' child node with one child +'endpoint' node, according to the bindings defined in [1]. This +node should describe panel's video bus. + +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + + panel: panel { + compatible = "sharp,ld-d5116z01b"; + power-supply = <&vlcd_3v3>; + + port { + panel_ep: endpoint { + remote-endpoint = <&bridge_out_ep>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq070y3dg3b.txt b/Documentation/devicetree/bindings/display/panel/sharp,lq070y3dg3b.txt new file mode 100644 index 000000000000..95534b55ee5f --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sharp,lq070y3dg3b.txt @@ -0,0 +1,12 @@ +Sharp LQ070Y3DG3B 7.0" WVGA landscape TFT LCD panel + +Required properties: +- compatible: should be "sharp,lq070y3dg3b" + +Optional properties: +- enable-gpios: GPIO pin to enable or disable the panel +- backlight: phandle of the backlight device attached to the panel +- power-supply: phandle of the regulator that provides the supply voltage + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt b/Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt new file mode 100644 index 000000000000..e45edbc565a3 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt @@ -0,0 +1,12 @@ +Sharp 2.0" (240x160 pixels) 16-bit TFT LCD panel + +Required properties: +- compatible: should be "sharp,ls020b1dd01d" +- power-supply: as specified in the base binding + +Optional properties: +- backlight: as specified in the base binding +- enable-gpios: as specified in the base binding + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt index b2b872c710f2..e11208fb7da8 100644 --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt @@ -1,28 +1 @@ -Simple display panel -==================== - -panel node ----------- - -Required properties: -- power-supply: See panel-common.txt - -Optional properties: -- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing -- enable-gpios: GPIO pin to enable or disable the panel -- backlight: phandle of the backlight device attached to the panel -- no-hpd: This panel is supposed to communicate that it's ready via HPD - (hot plug detect) signal, but the signal isn't hooked up so we should - hardcode the max delay from the panel spec when powering up the panel. - -Example: - - panel: panel { - compatible = "cptt,claa101wb01"; - ddc-i2c-bus = <&panelddc>; - - power-supply = <&vdd_pnl_reg>; - enable-gpios = <&gpio 90 0>; - - backlight = <&backlight>; - }; +See panel-common.yaml in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt b/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt deleted file mode 100644 index dfb572f085eb..000000000000 --- a/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt +++ /dev/null @@ -1,15 +0,0 @@ -TFC S9700RTWV43TR-01B 7" Three Five Corp 800x480 LCD panel with -resistive touch - -The panel is found on TI AM335x-evm. - -Required properties: -- compatible: should be "tfc,s9700rtwv43tr-01b" -- power-supply: See panel-common.txt - -Optional properties: -- enable-gpios: GPIO pin to enable or disable the panel, if there is one -- backlight: phandle of the backlight device attached to the panel - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.yaml b/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.yaml new file mode 100644 index 000000000000..9e5994417c12 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/tfc,s9700rtwv43tr-01b.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TFC S9700RTWV43TR-01B 7" Three Five Corp 800x480 LCD panel with resistive touch + +maintainers: + - Jyri Sarha <jsarha@ti.com> + - Thierry Reding <thierry.reding@gmail.com> + +description: |+ + The panel is found on TI AM335x-evm. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: tfc,s9700rtwv43tr-01b + + enable-gpios: true + backlight: true + port: true + +additionalProperties: false + +required: + - compatible + - power-supply + +... diff --git a/Documentation/devicetree/bindings/display/panel/ti,nspire.yaml b/Documentation/devicetree/bindings/display/panel/ti,nspire.yaml new file mode 100644 index 000000000000..5c5a3b519e31 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/ti,nspire.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/ti,nspire.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments NSPIRE Display Panels + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + enum: + - ti,nspire-cx-lcd-panel + - ti,nspire-classic-lcd-panel + port: true + +required: + - compatible + +additionalProperties: false + +examples: + - | + panel { + compatible = "ti,nspire-cx-lcd-panel"; + port { + panel_in: endpoint { + remote-endpoint = <&pads>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt deleted file mode 100644 index 40f3d7c713bb..000000000000 --- a/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt +++ /dev/null @@ -1,70 +0,0 @@ -TPO TPG110 Panel -================ - -This panel driver is a component that acts as an intermediary -between an RGB output and a variety of panels. The panel -driver is strapped up in electronics to the desired resolution -and other properties, and has a control interface over 3WIRE -SPI. By talking to the TPG110 over SPI, the strapped properties -can be discovered and the hardware is therefore mostly -self-describing. - - +--------+ -SPI -> | TPO | -> physical display -RGB -> | TPG110 | - +--------+ - -If some electrical strap or alternate resolution is desired, -this can be set up by taking software control of the display -over the SPI interface. The interface can also adjust -for properties of the display such as gamma correction and -certain electrical driving levels. - -The TPG110 does not know the physical dimensions of the panel -connected, so this needs to be specified in the device tree. - -It requires a GPIO line for control of its reset line. - -The serial protocol has line names that resemble I2C but the -protocol is not I2C but 3WIRE SPI. - -Required properties: -- compatible : one of: - "ste,nomadik-nhk15-display", "tpo,tpg110" - "tpo,tpg110" -- grestb-gpios : panel reset GPIO -- width-mm : see display/panel/panel-common.txt -- height-mm : see display/panel/panel-common.txt - -The device needs to be a child of an SPI bus, see -spi/spi-bus.txt. The SPI child must set the following -properties: -- spi-3wire -- spi-max-frequency = <3000000>; -as these are characteristics of this device. - -The device node can contain one 'port' child node with one child -'endpoint' node, according to the bindings defined in -media/video-interfaces.txt. This node should describe panel's video bus. - -Example -------- - -panel: display@0 { - compatible = "tpo,tpg110"; - reg = <0>; - spi-3wire; - /* 320 ns min period ~= 3 MHz */ - spi-max-frequency = <3000000>; - /* Width and height from data sheet */ - width-mm = <116>; - height-mm = <87>; - grestb-gpios = <&foo_gpio 5 GPIO_ACTIVE_LOW>; - backlight = <&bl>; - - port { - nomadik_clcd_panel: endpoint { - remote-endpoint = <&foo>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml new file mode 100644 index 000000000000..a51660b73f28 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/tpo,tpg110.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TPO TPG110 Panel + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + - Thierry Reding <thierry.reding@gmail.com> + +description: |+ + This panel driver is a component that acts as an intermediary + between an RGB output and a variety of panels. The panel + driver is strapped up in electronics to the desired resolution + and other properties, and has a control interface over 3WIRE + SPI. By talking to the TPG110 over SPI, the strapped properties + can be discovered and the hardware is therefore mostly + self-describing. + + +--------+ + SPI -> | TPO | -> physical display + RGB -> | TPG110 | + +--------+ + + If some electrical strap or alternate resolution is desired, + this can be set up by taking software control of the display + over the SPI interface. The interface can also adjust + for properties of the display such as gamma correction and + certain electrical driving levels. + + The TPG110 does not know the physical dimensions of the panel + connected, so this needs to be specified in the device tree. + + It requires a GPIO line for control of its reset line. + + The serial protocol has line names that resemble I2C but the + protocol is not I2C but 3WIRE SPI. + + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + oneOf: + - items: + - enum: + - ste,nomadik-nhk15-display + - const: tpo,tpg110 + - const: tpo,tpg110 + + reg: true + + grestb-gpios: + maxItems: 1 + description: panel reset GPIO + + spi-3wire: true + + spi-max-frequency: + const: 3000000 + +required: + - compatible + - reg + - grestb-gpios + - width-mm + - height-mm + - spi-3wire + - spi-max-frequency + - port + +examples: + - |+ + spi { + #address-cells = <1>; + #size-cells = <0>; + + panel: display@0 { + compatible = "tpo,tpg110"; + reg = <0>; + spi-3wire; + /* 320 ns min period ~= 3 MHz */ + spi-max-frequency = <3000000>; + /* Width and height from data sheet */ + width-mm = <116>; + height-mm = <87>; + grestb-gpios = <&foo_gpio 5 1>; + backlight = <&bl>; + + port { + nomadik_clcd_panel: endpoint { + remote-endpoint = <&foo>; + }; + }; + }; + }; + +... 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/display/rockchip/rockchip-lvds.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt index da6939efdb43..7849ff039229 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt @@ -32,17 +32,6 @@ Their connections are modeled using the OF graph bindings specified in - video port 0 for the VOP input, the remote endpoint maybe vopb or vopl - video port 1 for either a panel or subsequent encoder -the lvds panel described by - Documentation/devicetree/bindings/display/panel/simple-panel.txt - -Panel required properties: -- ports for remote LVDS output - -Panel optional properties: -- data-mapping: should be "vesa-24","jeida-24" or "jeida-18". -This describes decribed by: - Documentation/devicetree/bindings/display/panel/panel-lvds.txt - Example: lvds_panel: lvds-panel { diff --git a/Documentation/devicetree/bindings/display/ssd1307fb.txt b/Documentation/devicetree/bindings/display/ssd1307fb.txt index b67f8caa212c..27333b9551b3 100644 --- a/Documentation/devicetree/bindings/display/ssd1307fb.txt +++ b/Documentation/devicetree/bindings/display/ssd1307fb.txt @@ -27,6 +27,15 @@ Optional properties: - solomon,prechargep2: Length of precharge period (phase 2) in clock cycles. This needs to be the higher, the higher the capacitance of the OLED's pixels is + - solomon,dclk-div: Clock divisor 1 to 16 + - solomon,dclk-frq: Clock frequency 0 to 15, higher value means higher + frequency + - solomon,lookup-table: 8 bit value array of current drive pulse widths for + BANK0, and colors A, B, and C. Each value in range + of 31 to 63 for pulse widths of 32 to 64. Color D + is always width 64. + - solomon,area-color-enable: Display uses color mode + - solomon,low-power. Display runs in low power mode [0]: Documentation/devicetree/bindings/pwm/pwm.txt @@ -46,4 +55,5 @@ ssd1306: oled@3c { solomon,com-lrremap; solomon,com-invdir; solomon,com-offset = <32>; + solomon,lookup-table = /bits/ 8 <0x3f 0x3f 0x3f 0x3f>; }; 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/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 = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>; - 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 <robh@kernel.org> + +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 <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + gpu@ffe40000 { + compatible = "amlogic,meson-g12a-mali", "arm,mali-bifrost"; + reg = <0xffe40000 0x10000>; + interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>; + 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 = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>; - 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 <robh@kernel.org> + +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 <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + gpu@ffa30000 { + compatible = "rockchip,rk3288-mali", "arm,mali-t760"; + reg = <0xffa30000 0x10000>; + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>; + 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 = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>; - 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 <robh@kernel.org> + - Maxime Ripard <maxime.ripard@free-electrons.com> + - Heiko Stuebner <heiko@sntech.de> + +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 <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + mali: gpu@1c40000 { + compatible = "allwinner,sun7i-a20-mali", "arm,mali-400"; + reg = <0x01c40000 0x10000>; + interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>; + 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/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-rcar.txt b/Documentation/devicetree/bindings/i2c/renesas,i2c.txt index 3ee5e8f6ee01..3ee5e8f6ee01 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt +++ b/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 index 5ed1ea1c7e14..5ed1ea1c7e14 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-emev2.txt +++ b/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 index 202602e6e837..202602e6e837 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt +++ b/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 index e26fe3ad86a9..e26fe3ad86a9 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-riic.txt +++ b/Documentation/devicetree/bindings/i2c/renesas,riic.txt 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 <wens@csie.org> + - Maxime Ripard <maxime.ripard@bootlin.com> + +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 <dt-bindings/input/input.h> - - lradc: lradc@1c22800 { - compatible = "allwinner,sun4i-a10-lradc-keys"; - reg = <0x01c22800 0x100>; - interrupts = <31>; - vref-supply = <®_vcc3v0>; - - button@191 { - label = "Volume Up"; - linux,code = <KEY_VOLUMEUP>; - channel = <0>; - voltage = <191274>; - }; - - button@392 { - label = "Volume Down"; - linux,code = <KEY_VOLUMEDOWN>; - channel = <0>; - voltage = <392644>; - }; - - button@601 { - label = "Menu"; - linux,code = <KEY_MENU>; - channel = <0>; - voltage = <601151>; - }; - - button@795 { - label = "Enter"; - linux,code = <KEY_ENTER>; - channel = <0>; - voltage = <795090>; - }; - - button@987 { - label = "Home"; - linux,code = <KEY_HOMEPAGE>; - 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_name>-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/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 <wens@csie.org> + - Maxime Ripard <maxime.ripard@bootlin.com> + +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 <wens@csie.org> + - Maxime Ripard <maxime.ripard@bootlin.com> + +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/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/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 <narmstrong@baylibre.com> + +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 = <GIC_SPI 135 IRQ_TYPE_LEVEL_LOW>; 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 = <SUBSYS_1400XXXX>; mutex-event-eof = <CMDQ_EVENT_MUTEX0_STREAM_EOF CMDQ_EVENT_MUTEX1_STREAM_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/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/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/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/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 = <GIC_SPI 0x1d IRQ_TYPE_EDGE_RISING>; + 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/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 = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */ + <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>; /* 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 8324a4ee6f06..7a813d0e6d63 100644 --- a/Documentation/devicetree/bindings/pci/pci-armada8k.txt +++ b/Documentation/devicetree/bindings/pci/pci-armada8k.txt @@ -11,7 +11,7 @@ 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 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: <stringlist> + 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: <prop-encoded-array> + Definition: Register ranges as listed in the reg-names property + +- reg-names: + Usage: required + Value type: <stringlist> + 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 = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; + 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 <narmstrong@baylibre.com> + +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 <narmstrong@baylibre.com> + +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/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 <dt-bindings/phy/phy.h> 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-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 <andrew@aj.id.au> + +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: <string> + Definition: must be "qcom,sc7180-pinctrl" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: the base address and size of the north, south and west + TLMM tiles + +- reg-names: + Usage: required + Value type: <prop-encoded-array> + Definition: names for the cells of reg, must contain "north", "south" + and "west". + +- interrupts: + Usage: required + Value type: <prop-encoded-array> + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: <none> + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: <u32> + Definition: must be 2. Specifying the pin number and flags, as defined + in <dt-bindings/interrupt-controller/irq.h> + +- gpio-controller: + Usage: required + Value type: <none> + Definition: identifies this node as a gpio controller + +- #gpio-cells: + Usage: required + Value type: <u32> + Definition: must be 2. Specifying the pin number and flags, as defined + in <dt-bindings/gpio/gpio.h> + +- gpio-ranges: + Usage: required + Value type: <prop-encoded-array> + Definition: see ../gpio/gpio.txt + +- gpio-reserved-ranges: + Usage: optional + Value type: <prop-encoded-array> + 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: <string-array> + 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: <string> + 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: <none> + Definition: The specified pins should be configured as no pull. + +- bias-pull-down: + Usage: optional + Value type: <none> + Definition: The specified pins should be configured as pull down. + +- bias-pull-up: + Usage: optional + Value type: <none> + Definition: The specified pins should be configured as pull up. + +- output-high: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + high. + Not valid for sdc pins. + +- output-low: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + low. + Not valid for sdc pins. + +- drive-strength: + Usage: optional + Value type: <u32> + 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 = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>; + 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/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/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 <narmstrong@baylibre.com> + +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/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/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 <narmstrong@baylibre.com> + +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/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 @@ -96,6 +97,18 @@ allOf: properties: compatible: contains: + const: allwinner,sun50i-h6-rtc + + then: + properties: + clock-output-names: + minItems: 3 + maxItems: 3 + + - if: + properties: + compatible: + contains: const: allwinner,sun8i-r40-rtc then: 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,<chip>-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 = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>; - /* 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 <narmstrong@baylibre.com> + +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/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 <srinivas.kandagatla@linaro.org> + - Vinod Koul <vkoul@kernel.org> + +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 <narmstrong@baylibre.com> + +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 <narmstrong@baylibre.com> + +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/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 = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>; - clock-names = "core"; - clocks = <&clk81>; - #address-cells = <1>; - #size-cells = <0>; - }; 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/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 <dt-bindings/clock/ingenic,tcu.h>. +- 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 <dt-bindings/clock/jz4770-cgu.h> +#include <dt-bindings/clock/ingenic,tcu.h> + +/ { + 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/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/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 329b668dac0a..967e78c5ec0a 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -443,6 +443,8 @@ patternProperties: description: Innolux Corporation "^inside-secure,.*": description: INSIDE Secure + "^inspur,.*": + description: Inspur Corporation "^intel,.*": description: Intel Corporation "^intercontrol,.*": @@ -519,6 +521,8 @@ patternProperties: description: Lenovo Group Ltd. "^lg,.*": description: LG Corporation + "^lgphilips,.*": + description: LG Display "^libretech,.*": description: Shenzhen Libre Technology Co., Ltd "^licheepi,.*": @@ -949,6 +953,9 @@ patternProperties: description: Tecon Microprocessor Technologies, LLC. "^topeet,.*": description: Topeet + "^toppoly,.*": + description: TPO (deprecated, use tpo) + deprecated: true "^toradex,.*": description: Toradex AG "^toshiba,.*": 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 <wens@csie.org> + - Maxime Ripard <maxime.ripard@bootlin.com> + +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 <narmstrong@baylibre.com> + +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 = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>; + 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 <linux@roeck-us.net> + - Wim Van Sebroeck <wim@linux-watchdog.org> + +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.rst b/Documentation/devicetree/writing-schema.rst index 8f71d1e2ac52..f4a638072262 100644 --- a/Documentation/devicetree/writing-schema.rst +++ b/Documentation/devicetree/writing-schema.rst @@ -141,6 +141,7 @@ It is also possible to run checks with a single schema file by setting the :: + 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 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/filesystems/ceph.txt b/Documentation/filesystems/ceph.txt index d2c6a5ccf0f5..b19b6a03f91c 100644 --- a/Documentation/filesystems/ceph.txt +++ b/Documentation/filesystems/ceph.txt @@ -158,6 +158,20 @@ Mount Options copies. Currently, it's only used in copy_file_range, which will revert to the default VFS implementation if this option is used. + recover_session=<no|clean> + Set auto reconnect mode in the case where the client is blacklisted. The + available modes are "no" and "clean". The default is "no". + + * no: never attempt to reconnect when client detects that it has been + blacklisted. Operations will generally fail after being blacklisted. + + * clean: client reconnects to the ceph cluster automatically when it + detects that it has been blacklisted. During reconnect, client drops + dirty data/metadata, invalidates page caches and writable file handles. + After reconnect, file locks become stale because the MDS loses track + of them. If an inode contains any stale file locks, read/write on the + inode is not allowed until applications release all stale file locks. + More Information ================ diff --git a/Documentation/filesystems/cifs/cifsroot.txt b/Documentation/filesystems/cifs/cifsroot.txt new file mode 100644 index 000000000000..0fa1a2c36a40 --- /dev/null +++ b/Documentation/filesystems/cifs/cifsroot.txt @@ -0,0 +1,97 @@ +Mounting root file system via SMB (cifs.ko) +=========================================== + +Written 2019 by Paulo Alcantara <palcantara@suse.de> +Written 2019 by Aurelien Aptel <aaptel@suse.com> + +The CONFIG_CIFS_ROOT option enables experimental root file system +support over the SMB protocol via cifs.ko. + +It introduces a new kernel command-line option called 'cifsroot=' +which will tell the kernel to mount the root file system over the +network by utilizing SMB or CIFS protocol. + +In order to mount, the network stack will also need to be set up by +using 'ip=' config option. For more details, see +Documentation/filesystems/nfs/nfsroot.txt. + +A CIFS root mount currently requires the use of SMB1+UNIX Extensions +which is only supported by the Samba server. SMB1 is the older +deprecated version of the protocol but it has been extended to support +POSIX features (See [1]). The equivalent extensions for the newer +recommended version of the protocol (SMB3) have not been fully +implemented yet which means SMB3 doesn't support some required POSIX +file system objects (e.g. block devices, pipes, sockets). + +As a result, a CIFS root will default to SMB1 for now but the version +to use can nonetheless be changed via the 'vers=' mount option. This +default will change once the SMB3 POSIX extensions are fully +implemented. + +Server configuration +==================== + +To enable SMB1+UNIX extensions you will need to set these global +settings in Samba smb.conf: + + [global] + server min protocol = NT1 + unix extension = yes # default + +Kernel command line +=================== + +root=/dev/cifs + +This is just a virtual device that basically tells the kernel to mount +the root file system via SMB protocol. + +cifsroot=//<server-ip>/<share>[,options] + +Enables the kernel to mount the root file system via SMB that are +located in the <server-ip> and <share> specified in this option. + +The default mount options are set in fs/cifs/cifsroot.c. + +server-ip + IPv4 address of the server. + +share + Path to SMB share (rootfs). + +options + Optional mount options. For more information, see mount.cifs(8). + +Examples +======== + +Export root file system as a Samba share in smb.conf file. + +... +[linux] + path = /path/to/rootfs + read only = no + guest ok = yes + force user = root + force group = root + browseable = yes + writeable = yes + admin users = root + public = yes + create mask = 0777 + directory mask = 0777 +... + +Restart smb service. + +# systemctl restart smb + +Test it under QEMU on a kernel built with CONFIG_CIFS_ROOT and +CONFIG_IP_PNP options enabled. + +# qemu-system-x86_64 -enable-kvm -cpu host -m 1024 \ + -kernel /path/to/linux/arch/x86/boot/bzImage -nographic \ + -append "root=/dev/cifs rw ip=dhcp cifsroot=//10.0.2.2/linux,username=foo,password=bar console=ttyS0 3" + + +1: https://wiki.samba.org/index.php/UNIX_Extensions diff --git a/Documentation/filesystems/ext4/bigalloc.rst b/Documentation/filesystems/ext4/bigalloc.rst index c6d88557553c..72075aa608e4 100644 --- a/Documentation/filesystems/ext4/bigalloc.rst +++ b/Documentation/filesystems/ext4/bigalloc.rst @@ -9,14 +9,26 @@ ext4 code is not prepared to handle the case where the block size exceeds the page size. However, for a filesystem of mostly huge files, it is desirable to be able to allocate disk blocks in units of multiple blocks to reduce both fragmentation and metadata overhead. The -`bigalloc <Bigalloc>`__ feature provides exactly this ability. The -administrator can set a block cluster size at mkfs time (which is stored -in the s\_log\_cluster\_size field in the superblock); from then on, the -block bitmaps track clusters, not individual blocks. This means that -block groups can be several gigabytes in size (instead of just 128MiB); -however, the minimum allocation unit becomes a cluster, not a block, -even for directories. TaoBao had a patchset to extend the “use units of -clusters instead of blocks” to the extent tree, though it is not clear -where those patches went-- they eventually morphed into “extent tree v2” -but that code has not landed as of May 2015. +bigalloc feature provides exactly this ability. + +The bigalloc feature (EXT4_FEATURE_RO_COMPAT_BIGALLOC) changes ext4 to +use clustered allocation, so that each bit in the ext4 block allocation +bitmap addresses a power of two number of blocks. For example, if the +file system is mainly going to be storing large files in the 4-32 +megabyte range, it might make sense to set a cluster size of 1 megabyte. +This means that each bit in the block allocation bitmap now addresses +256 4k blocks. This shrinks the total size of the block allocation +bitmaps for a 2T file system from 64 megabytes to 256 kilobytes. It also +means that a block group addresses 32 gigabytes instead of 128 megabytes, +also shrinking the amount of file system overhead for metadata. + +The administrator can set a block cluster size at mkfs time (which is +stored in the s\_log\_cluster\_size field in the superblock); from then +on, the block bitmaps track clusters, not individual blocks. This means +that block groups can be several gigabytes in size (instead of just +128MiB); however, the minimum allocation unit becomes a cluster, not a +block, even for directories. TaoBao had a patchset to extend the “use +units of clusters instead of blocks” to the extent tree, though it is +not clear where those patches went-- they eventually morphed into +“extent tree v2” but that code has not landed as of May 2015. diff --git a/Documentation/filesystems/ext4/blockgroup.rst b/Documentation/filesystems/ext4/blockgroup.rst index baf888e4c06a..3da156633339 100644 --- a/Documentation/filesystems/ext4/blockgroup.rst +++ b/Documentation/filesystems/ext4/blockgroup.rst @@ -71,11 +71,11 @@ if the flex\_bg size is 4, then group 0 will contain (in order) the superblock, group descriptors, data block bitmaps for groups 0-3, inode bitmaps for groups 0-3, inode tables for groups 0-3, and the remaining space in group 0 is for file data. The effect of this is to group the -block metadata close together for faster loading, and to enable large -files to be continuous on disk. Backup copies of the superblock and -group descriptors are always at the beginning of block groups, even if -flex\_bg is enabled. The number of block groups that make up a flex\_bg -is given by 2 ^ ``sb.s_log_groups_per_flex``. +block group metadata close together for faster loading, and to enable +large files to be continuous on disk. Backup copies of the superblock +and group descriptors are always at the beginning of block groups, even +if flex\_bg is enabled. The number of block groups that make up a +flex\_bg is given by 2 ^ ``sb.s_log_groups_per_flex``. Meta Block Groups ----------------- diff --git a/Documentation/filesystems/ext4/blocks.rst b/Documentation/filesystems/ext4/blocks.rst index 73d4dc0f7bda..bd722ecd92d6 100644 --- a/Documentation/filesystems/ext4/blocks.rst +++ b/Documentation/filesystems/ext4/blocks.rst @@ -10,7 +10,9 @@ block groups. Block size is specified at mkfs time and typically is 4KiB. You may experience mounting problems if block size is greater than page size (i.e. 64KiB blocks on a i386 which only has 4KiB memory pages). By default a filesystem can contain 2^32 blocks; if the '64bit' -feature is enabled, then a filesystem can have 2^64 blocks. +feature is enabled, then a filesystem can have 2^64 blocks. The location +of structures is stored in terms of the block number the structure lives +in and not the absolute offset on disk. For 32-bit filesystems, limits are as follows: diff --git a/Documentation/filesystems/ext4/directory.rst b/Documentation/filesystems/ext4/directory.rst index 614034e24669..073940cc64ed 100644 --- a/Documentation/filesystems/ext4/directory.rst +++ b/Documentation/filesystems/ext4/directory.rst @@ -59,7 +59,7 @@ is at most 263 bytes long, though on disk you'll need to reference - File name. Since file names cannot be longer than 255 bytes, the new directory -entry format shortens the rec\_len field and uses the space for a file +entry format shortens the name\_len field and uses the space for a file type flag, probably to avoid having to load every inode during directory tree traversal. This format is ``ext4_dir_entry_2``, which is at most 263 bytes long, though on disk you'll need to reference diff --git a/Documentation/filesystems/ext4/group_descr.rst b/Documentation/filesystems/ext4/group_descr.rst index 0f783ed88592..7ba6114e7f5c 100644 --- a/Documentation/filesystems/ext4/group_descr.rst +++ b/Documentation/filesystems/ext4/group_descr.rst @@ -99,9 +99,12 @@ The block group descriptor is laid out in ``struct ext4_group_desc``. * - 0x1E - \_\_le16 - bg\_checksum - - Group descriptor checksum; crc16(sb\_uuid+group+desc) if the - RO\_COMPAT\_GDT\_CSUM feature is set, or crc32c(sb\_uuid+group\_desc) & - 0xFFFF if the RO\_COMPAT\_METADATA\_CSUM feature is set. + - Group descriptor checksum; crc16(sb\_uuid+group\_num+bg\_desc) if the + RO\_COMPAT\_GDT\_CSUM feature is set, or + crc32c(sb\_uuid+group\_num+bg\_desc) & 0xFFFF if the + RO\_COMPAT\_METADATA\_CSUM feature is set. The bg\_checksum + field in bg\_desc is skipped when calculating crc16 checksum, + and set to zero if crc32c checksum is used. * - - - diff --git a/Documentation/filesystems/ext4/inodes.rst b/Documentation/filesystems/ext4/inodes.rst index e851e6ca31fa..a65baffb4ebf 100644 --- a/Documentation/filesystems/ext4/inodes.rst +++ b/Documentation/filesystems/ext4/inodes.rst @@ -472,8 +472,8 @@ inode, which allows struct ext4\_inode to grow for a new kernel without having to upgrade all of the on-disk inodes. Access to fields beyond EXT2\_GOOD\_OLD\_INODE\_SIZE should be verified to be within ``i_extra_isize``. By default, ext4 inode records are 256 bytes, and (as -of October 2013) the inode structure is 156 bytes -(``i_extra_isize = 28``). The extra space between the end of the inode +of August 2019) the inode structure is 160 bytes +(``i_extra_isize = 32``). The extra space between the end of the inode structure and the end of the inode record can be used to store extended attributes. Each inode record can be as large as the filesystem block size, though this is not terribly efficient. diff --git a/Documentation/filesystems/ext4/super.rst b/Documentation/filesystems/ext4/super.rst index 6eae92054827..93e55d7c1d40 100644 --- a/Documentation/filesystems/ext4/super.rst +++ b/Documentation/filesystems/ext4/super.rst @@ -58,7 +58,7 @@ The ext4 superblock is laid out as follows in * - 0x1C - \_\_le32 - s\_log\_cluster\_size - - Cluster size is (2 ^ s\_log\_cluster\_size) blocks if bigalloc is + - Cluster size is 2 ^ (10 + s\_log\_cluster\_size) blocks if bigalloc is enabled. Otherwise s\_log\_cluster\_size must equal s\_log\_block\_size. * - 0x20 - \_\_le32 @@ -447,7 +447,7 @@ The ext4 superblock is laid out as follows in - Upper 8 bits of the s_wtime field. * - 0x275 - \_\_u8 - - s\_wtime_hi + - s\_mtime_hi - Upper 8 bits of the s_mtime field. * - 0x276 - \_\_u8 @@ -466,12 +466,20 @@ The ext4 superblock is laid out as follows in - s\_last_error_time_hi - Upper 8 bits of the s_last_error_time_hi field. * - 0x27A - - \_\_u8[2] - - s\_pad + - \_\_u8 + - s\_pad[2] - Zero padding. * - 0x27C + - \_\_le16 + - s\_encoding + - Filename charset encoding. + * - 0x27E + - \_\_le16 + - s\_encoding_flags + - Filename charset encoding flags. + * - 0x280 - \_\_le32 - - s\_reserved[96] + - s\_reserved[95] - Padding to the end of the block. * - 0x3FC - \_\_le32 @@ -617,7 +625,7 @@ following: * - 0x80 - Enable a filesystem size of 2^64 blocks (INCOMPAT\_64BIT). * - 0x100 - - Multiple mount protection. Not implemented (INCOMPAT\_MMP). + - Multiple mount protection (INCOMPAT\_MMP). * - 0x200 - Flexible block groups. See the earlier discussion of this feature (INCOMPAT\_FLEX\_BG). diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt index 496fa28b2492..7e1991328473 100644 --- a/Documentation/filesystems/f2fs.txt +++ b/Documentation/filesystems/f2fs.txt @@ -157,6 +157,11 @@ noinline_data Disable the inline data feature, inline data feature is enabled by default. data_flush Enable data flushing before checkpoint in order to persist data of regular and symlink. +reserve_root=%d Support configuring reserved space which is used for + allocation from a privileged user with specified uid or + gid, unit: 4KB, the default limit is 0.2% of user blocks. +resuid=%d The user ID which may use the reserved blocks. +resgid=%d The group ID which may use the reserved blocks. fault_injection=%d Enable fault injection in all supported types with specified injection rate. fault_type=%d Support configuring fault injection type, should be @@ -413,6 +418,9 @@ Files in /sys/fs/f2fs/<devname> that would be unusable if checkpoint=disable were to be set. +encoding This shows the encoding used for casefolding. + If casefolding is not enabled, returns (none) + ================================================================================ USAGE ================================================================================ diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index fd2bcf99cda0..2c3a9f761205 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -37,3 +37,13 @@ filesystem implementations. journalling fscrypt fsverity + +Filesystems +=========== + +Documentation for filesystem implementations. + +.. toctree:: + :maxdepth: 2 + + virtiofs diff --git a/Documentation/filesystems/virtiofs.rst b/Documentation/filesystems/virtiofs.rst new file mode 100644 index 000000000000..4f338e3cb3f7 --- /dev/null +++ b/Documentation/filesystems/virtiofs.rst @@ -0,0 +1,60 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================================================== +virtiofs: virtio-fs host<->guest shared file system +=================================================== + +- Copyright (C) 2019 Red Hat, Inc. + +Introduction +============ +The virtiofs file system for Linux implements a driver for the paravirtualized +VIRTIO "virtio-fs" device for guest<->host file system sharing. It allows a +guest to mount a directory that has been exported on the host. + +Guests often require access to files residing on the host or remote systems. +Use cases include making files available to new guests during installation, +booting from a root file system located on the host, persistent storage for +stateless or ephemeral guests, and sharing a directory between guests. + +Although it is possible to use existing network file systems for some of these +tasks, they require configuration steps that are hard to automate and they +expose the storage network to the guest. The virtio-fs device was designed to +solve these problems by providing file system access without networking. + +Furthermore the virtio-fs device takes advantage of the co-location of the +guest and host to increase performance and provide semantics that are not +possible with network file systems. + +Usage +===== +Mount file system with tag ``myfs`` on ``/mnt``: + +.. code-block:: sh + + guest# mount -t virtiofs myfs /mnt + +Please see https://virtio-fs.gitlab.io/ for details on how to configure QEMU +and the virtiofsd daemon. + +Internals +========= +Since the virtio-fs device uses the FUSE protocol for file system requests, the +virtiofs file system for Linux is integrated closely with the FUSE file system +client. The guest acts as the FUSE client while the host acts as the FUSE +server. The /dev/fuse interface between the kernel and userspace is replaced +with the virtio-fs device interface. + +FUSE requests are placed into a virtqueue and processed by the host. The +response portion of the buffer is filled in by the host and the guest handles +the request completion. + +Mapping /dev/fuse to virtqueues requires solving differences in semantics +between /dev/fuse and virtqueues. Each time the /dev/fuse device is read, the +FUSE client may choose which request to transfer, making it possible to +prioritize certain requests over others. Virtqueues have queue semantics and +it is not possible to change the order of requests that have been enqueued. +This is especially important if the virtqueue becomes full since it is then +impossible to add high priority requests. In order to address this difference, +the virtio-fs device uses a "hiprio" virtqueue specifically for requests that +have priority over normal requests. diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst index 4bfb7068e9f7..b4a0ed3ca961 100644 --- a/Documentation/gpu/drivers.rst +++ b/Documentation/gpu/drivers.rst @@ -11,7 +11,6 @@ GPU Driver Documentation meson pl111 tegra - tinydrm tve200 v3d vc4 diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index b327bbc11182..3868008db8a9 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -263,6 +263,18 @@ the MST topology helpers easier to understand drm_dp_mst_topology_put_port drm_dp_mst_get_mstb_malloc drm_dp_mst_put_mstb_malloc +MIPI DBI Helper Functions Reference +=================================== + +.. kernel-doc:: drivers/gpu/drm/drm_mipi_dbi.c + :doc: overview + +.. kernel-doc:: include/drm/drm_mipi_dbi.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_mipi_dbi.c + :export: + MIPI DSI Helper Functions Reference =================================== diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index c8ebd4f66a6a..b664f054c259 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -433,43 +433,11 @@ PRIME is the cross device buffer sharing framework in drm, originally created for the OPTIMUS range of multi-gpu platforms. To userspace PRIME buffers are dma-buf based file descriptors. -Overview and Driver Interface ------------------------------ +Overview and Lifetime Rules +--------------------------- -Similar to GEM global names, PRIME file descriptors are also used to -share buffer objects across processes. They offer additional security: -as file descriptors must be explicitly sent over UNIX domain sockets to -be shared between applications, they can't be guessed like the globally -unique GEM names. - -Drivers that support the PRIME API must set the DRIVER_PRIME bit in the -struct :c:type:`struct drm_driver <drm_driver>` -driver_features field, and implement the prime_handle_to_fd and -prime_fd_to_handle operations. - -int (\*prime_handle_to_fd)(struct drm_device \*dev, struct drm_file -\*file_priv, uint32_t handle, uint32_t flags, int \*prime_fd); int -(\*prime_fd_to_handle)(struct drm_device \*dev, struct drm_file -\*file_priv, int prime_fd, uint32_t \*handle); Those two operations -convert a handle to a PRIME file descriptor and vice versa. Drivers must -use the kernel dma-buf buffer sharing framework to manage the PRIME file -descriptors. Similar to the mode setting API PRIME is agnostic to the -underlying buffer object manager, as long as handles are 32bit unsigned -integers. - -While non-GEM drivers must implement the operations themselves, GEM -drivers must use the :c:func:`drm_gem_prime_handle_to_fd()` and -:c:func:`drm_gem_prime_fd_to_handle()` helper functions. Those -helpers rely on the driver gem_prime_export and gem_prime_import -operations to create a dma-buf instance from a GEM object (dma-buf -exporter role) and to create a GEM object from a dma-buf instance -(dma-buf importer role). - -struct dma_buf \* (\*gem_prime_export)(struct drm_device \*dev, -struct drm_gem_object \*obj, int flags); struct drm_gem_object \* -(\*gem_prime_import)(struct drm_device \*dev, struct dma_buf -\*dma_buf); These two operations are mandatory for GEM drivers that -support PRIME. +.. kernel-doc:: drivers/gpu/drm/drm_prime.c + :doc: overview and lifetime rules PRIME Helper Functions ---------------------- diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index c38ef0dda605..3415255ad3dc 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -91,9 +91,6 @@ Frontbuffer Tracking .. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.c :internal: -.. kernel-doc:: drivers/gpu/drm/i915/i915_gem.c - :functions: i915_gem_track_fb - Display FIFO Underrun Reporting ------------------------------- @@ -430,31 +427,31 @@ WOPCM Layout GuC === +Firmware Layout +------------------- + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h + :doc: Firmware Layout + GuC-specific firmware loader ---------------------------- -.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c :internal: GuC-based command submission ---------------------------- -.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_submission.c +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c :doc: GuC-based command submission -.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_submission.c +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c :internal: -GuC Firmware Layout -------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fwif.h - :doc: GuC Firmware Layout - GuC Address Space ----------------- -.. kernel-doc:: drivers/gpu/drm/i915/intel_guc.c +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.c :doc: GuC Address Space Tracing diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index fccbe375244d..25a56e9c0cfd 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -51,6 +51,22 @@ and "FIXME" where the interface could be cleaned up. Also read the :ref:`guidelines for the kernel documentation at large <doc_guide>`. +Documentation Requirements for kAPI +----------------------------------- + +All kernel APIs exported to other modules must be documented, including their +datastructures and at least a short introductory section explaining the overall +concepts. Documentation should be put into the code itself as kerneldoc comments +as much as reasonable. + +Do not blindly document everything, but document only what's relevant for driver +authors: Internal functions of drm.ko and definitely static functions should not +have formal kerneldoc comments. Use normal C comments if you feel like a comment +is warranted. You may use kerneldoc syntax in the comment, but it shall not +start with a /** kerneldoc marker. Similar for data structures, annotate +anything entirely private with ``/* private: */`` comments as per the +documentation guide. + Getting Started =============== diff --git a/Documentation/gpu/tinydrm.rst b/Documentation/gpu/tinydrm.rst deleted file mode 100644 index 33a41544f659..000000000000 --- a/Documentation/gpu/tinydrm.rst +++ /dev/null @@ -1,30 +0,0 @@ -============================ -drm/tinydrm Tiny DRM drivers -============================ - -tinydrm is a collection of DRM drivers that are so small they can fit in a -single source file. - -Helpers -======= - -.. kernel-doc:: include/drm/tinydrm/tinydrm-helpers.h - :internal: - -.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c - :export: - -.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c - :export: - -MIPI DBI Compatible Controllers -=============================== - -.. kernel-doc:: drivers/gpu/drm/tinydrm/mipi-dbi.c - :doc: overview - -.. kernel-doc:: include/drm/tinydrm/mipi-dbi.h - :internal: - -.. kernel-doc:: drivers/gpu/drm/tinydrm/mipi-dbi.c - :export: diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 0a49c5a1d9ce..32787acff0a8 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -162,7 +162,7 @@ Clean up mmap forwarding A lot of drivers forward gem mmap calls to dma-buf mmap for imported buffers. And also a lot of them forward dma-buf mmap to the gem mmap implementations. -Would be great to refactor this all into a set of small common helpers. +There's drm_gem_prime_mmap() for this now, but still needs to be rolled out. Contact: Daniel Vetter @@ -196,15 +196,6 @@ Might be good to also have some igt testcases for this. Contact: Daniel Vetter, Noralf Tronnes -Remove the ->gem_prime_res_obj callback --------------------------------------------- - -The ->gem_prime_res_obj callback can be removed from drivers by using the -reservation_object in the drm_gem_object. It may also be possible to use the -generic drm_gem_reservation_object_wait helper for waiting for a bo. - -Contact: Daniel Vetter - idr_init_base() --------------- @@ -215,22 +206,13 @@ efficient. Contact: Daniel Vetter -Defaults for .gem_prime_import and export ------------------------------------------ - -Most drivers don't need to set drm_driver->gem_prime_import and -->gem_prime_export now that drm_gem_prime_import() and drm_gem_prime_export() -are the default. - struct drm_gem_object_funcs --------------------------- GEM objects can now have a function table instead of having the callbacks on the DRM driver struct. This is now the preferred way and drivers can be moved over. -DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS already support this, but -DRM_GEM_VRAM_DRIVER_PRIME does not yet and needs to be aligned with the previous -two. We also need a 2nd version of the CMA define that doesn't require the +We also need a 2nd version of the CMA define that doesn't require the vmapping to be present (different hook for prime importing). Plus this needs to be rolled out to all drivers using their own implementations, too. @@ -317,19 +299,6 @@ In the end no .c file should need to include ``drmP.h`` anymore. Contact: Daniel Vetter -Add missing kerneldoc for exported functions --------------------------------------------- - -The DRM reference documentation is still lacking kerneldoc in a few areas. The -task would be to clean up interfaces like moving functions around between -files to better group them and improving the interfaces like dropping return -values for functions that never fail. Then write kerneldoc for all exported -functions and an overview section and integrate it all into the drm book. - -See https://dri.freedesktop.org/docs/drm/ for what's there already. - -Contact: Daniel Vetter - Make panic handling work ------------------------ @@ -393,6 +362,9 @@ There's a bunch of issues with it: this (together with the drm_minor->drm_device move) would allow us to remove debugfs_init. +- Drop the return code and error checking from all debugfs functions. Greg KH is + working on this already. + Contact: Daniel Vetter KMS cleanups @@ -440,39 +412,22 @@ fit the available time. Contact: Daniel Vetter +Backlight Refactoring +--------------------- + +Backlight drivers have a triple enable/disable state, which is a bit overkill. +Plan to fix this: + +1. Roll out backlight_enable() and backlight_disable() helpers everywhere. This + has started already. +2. In all, only look at one of the three status bits set by the above helpers. +3. Remove the other two status bits. + +Contact: Daniel Vetter + Driver Specific =============== -tinydrm -------- - -Tinydrm is the helper driver for really simple fb drivers. The goal is to make -those drivers as simple as possible, so lots of room for refactoring: - -- backlight helpers, probably best to put them into a new drm_backlight.c. - This is because drivers/video is de-facto unmaintained. We could also - move drivers/video/backlight to drivers/gpu/backlight and take it all - over within drm-misc, but that's more work. Backlight helpers require a fair - bit of reworking and refactoring. A simple example is the enabling of a backlight. - Tinydrm has helpers for this. It would be good if other drivers can also use the - helper. However, there are various cases we need to consider i.e different - drivers seem to have different ways of enabling/disabling a backlight. - We also need to consider the backlight drivers (like gpio_backlight). The situation - is further complicated by the fact that the backlight is tied to fbdev - via fb_notifier_callback() which has complicated logic. For further details, refer - to the following discussion thread: - https://groups.google.com/forum/#!topic/outreachy-kernel/8rBe30lwtdA - -- spi helpers, probably best put into spi core/helper code. Thierry said - the spi maintainer is fast&reactive, so shouldn't be a big issue. - -- extract the mipi-dbi helper (well, the non-tinydrm specific parts at - least) into a separate helper, like we have for mipi-dsi already. Or follow - one of the ideas for having a shared dsi/dbi helper, abstracting away the - transport details more. - -Contact: Noralf Trønnes, Daniel Vetter - AMD DC Display Driver --------------------- diff --git a/Documentation/index.rst b/Documentation/index.rst index b5fd87e7dbee..b843e313d2f2 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -144,16 +144,15 @@ implementation. .. toctree:: :maxdepth: 2 - sh/index arm/index arm64/index ia64/index m68k/index - powerpc/index mips/index nios2/nios2 openrisc/index parisc/index + powerpc/index riscv/index s390/index sh/index diff --git a/Documentation/infiniband/core_locking.rst b/Documentation/infiniband/core_locking.rst index f34669beb4fe..8f76a8a5a38f 100644 --- a/Documentation/infiniband/core_locking.rst +++ b/Documentation/infiniband/core_locking.rst @@ -29,10 +29,10 @@ Sleeping and interrupt context The corresponding functions exported to upper level protocol consumers: - - ib_create_ah - - ib_modify_ah - - ib_query_ah - - ib_destroy_ah + - rdma_create_ah + - rdma_modify_ah + - rdma_query_ah + - rdma_destroy_ah - ib_post_send - ib_post_recv - ib_req_notify_cq diff --git a/Documentation/kbuild/kbuild.rst b/Documentation/kbuild/kbuild.rst index 61b2181ed3ea..f1e5dce86af7 100644 --- a/Documentation/kbuild/kbuild.rst +++ b/Documentation/kbuild/kbuild.rst @@ -105,6 +105,15 @@ The output directory can also be specified using "O=...". Setting "O=..." takes precedence over KBUILD_OUTPUT. +KBUILD_EXTRA_WARN +----------------- +Specify the extra build checks. The same value can be assigned by passing +W=... from the command line. + +See `make help` for the list of the supported values. + +Setting "W=..." takes precedence over KBUILD_EXTRA_WARN. + KBUILD_DEBARCH -------------- For the deb-pkg target, allows overriding the normal heuristics deployed by @@ -241,11 +250,6 @@ To get all available archs you can also specify all. E.g.:: $ make ALLSOURCE_ARCHS=all tags -KBUILD_ENABLE_EXTRA_GCC_CHECKS ------------------------------- -If enabled over the make command line with "W=1", it turns on additional -gcc -W... options for more extensive build-time checking. - KBUILD_BUILD_TIMESTAMP ---------------------- Setting this to a date string overrides the timestamp used in the @@ -258,17 +262,3 @@ KBUILD_BUILD_USER, KBUILD_BUILD_HOST These two variables allow to override the user@host string displayed during boot and in /proc/version. The default value is the output of the commands whoami and host, respectively. - -KBUILD_LDS ----------- -The linker script with full path. Assigned by the top-level Makefile. - -KBUILD_VMLINUX_OBJS -------------------- -All object files for vmlinux. They are linked to vmlinux in the same -order as listed in KBUILD_VMLINUX_OBJS. - -KBUILD_VMLINUX_LIBS -------------------- -All .a "lib" files for vmlinux. KBUILD_VMLINUX_OBJS and KBUILD_VMLINUX_LIBS -together specify all the object files used to link vmlinux. diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst index f4f0f7ffde2b..6ba9d5365ff3 100644 --- a/Documentation/kbuild/makefiles.rst +++ b/Documentation/kbuild/makefiles.rst @@ -471,21 +471,6 @@ more details, with real examples. The second argument is optional, and if supplied will be used if first argument is not supported. - cc-ldoption - cc-ldoption is used to check if $(CC) when used to link object files - supports the given option. An optional second option may be - specified if first option are not supported. - - Example:: - - #arch/x86/kernel/Makefile - vsyscall-flags += $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) - - In the above example, vsyscall-flags will be assigned the option - -Wl$(comma)--hash-style=sysv if it is supported by $(CC). - The second argument is optional, and if supplied will be used - if first argument is not supported. - as-instr as-instr checks if the assembler reports a specific instruction and then outputs either option1 or option2 @@ -765,7 +750,8 @@ Files matching the patterns "*.[oas]", "*.ko", plus some additional files generated by kbuild are deleted all over the kernel src tree when "make clean" is executed. -Additional files can be specified in kbuild makefiles by use of $(clean-files). +Additional files or directories can be specified in kbuild makefiles by use of +$(clean-files). Example:: @@ -776,23 +762,8 @@ When executing "make clean", the file "crc32table.h" will be deleted. Kbuild will assume files to be in the same relative directory as the Makefile, except if prefixed with $(objtree). -To delete a directory hierarchy use: - - Example:: - - #scripts/package/Makefile - clean-dirs := $(objtree)/debian/ - -This will delete the directory debian in the toplevel directory, including all -subdirectories. - -To exclude certain files from make clean, use the $(no-clean-files) variable. -This is only a special case used in the top level Kbuild file: - - Example:: - - #Kbuild - no-clean-files := $(bounds-file) $(offsets-file) +To exclude certain files or directories from make clean, use the +$(no-clean-files) variable. Usually kbuild descends down in subdirectories due to "obj-* := dir/", but in the architecture makefiles where the kbuild infrastructure @@ -988,13 +959,25 @@ When kbuild executes, the following steps are followed (roughly): $(KBUILD_ARFLAGS) set by the top level Makefile to "D" (deterministic mode) if this option is supported by $(AR). - ARCH_CPPFLAGS, ARCH_AFLAGS, ARCH_CFLAGS Overrides the kbuild defaults + KBUILD_LDS + + The linker script with full path. Assigned by the top-level Makefile. + + KBUILD_LDS_MODULE + + The module linker script with full path. Assigned by the top-level + Makefile and additionally by the arch Makefile. + + KBUILD_VMLINUX_OBJS + + All object files for vmlinux. They are linked to vmlinux in the same + order as listed in KBUILD_VMLINUX_OBJS. - These variables are appended to the KBUILD_CPPFLAGS, - KBUILD_AFLAGS, and KBUILD_CFLAGS, respectively, after the - top-level Makefile has set any other flags. This provides a - means for an architecture to override the defaults. + KBUILD_VMLINUX_LIBS + All .a "lib" files for vmlinux. KBUILD_VMLINUX_OBJS and + KBUILD_VMLINUX_LIBS together specify all the object files used to + link vmlinux. 6.2 Add prerequisites to archheaders ------------------------------------ @@ -1139,7 +1122,7 @@ When kbuild executes, the following steps are followed (roughly): header-test-y - header-test-y specifies headers (*.h) in the current directory that + header-test-y specifies headers (`*.h`) in the current directory that should be compile tested to ensure they are self-contained, i.e. compilable as standalone units. If CONFIG_HEADER_TEST is enabled, this builds them as part of extra-y. @@ -1147,11 +1130,11 @@ When kbuild executes, the following steps are followed (roughly): header-test-pattern-y This works as a weaker version of header-test-y, and accepts wildcard - patterns. The typical usage is: + patterns. The typical usage is:: - header-test-pattern-y += *.h + header-test-pattern-y += *.h - This specifies all the files that matches to '*.h' in the current + This specifies all the files that matches to `*.h` in the current directory, but the files in 'header-test-' are excluded. 6.7 Commands useful for building a boot image diff --git a/Documentation/kbuild/modules.rst b/Documentation/kbuild/modules.rst index 24e763482650..d2ae799237fd 100644 --- a/Documentation/kbuild/modules.rst +++ b/Documentation/kbuild/modules.rst @@ -470,9 +470,12 @@ build. The syntax of the Module.symvers file is:: - <CRC> <Symbol> <module> + <CRC> <Symbol> <Namespace> <Module> <Export Type> - 0x2d036834 scsi_remove_host drivers/scsi/scsi_mod + 0xe1cc2a05 usb_stor_suspend USB_STORAGE drivers/usb/storage/usb-storage EXPORT_SYMBOL_GPL + + The fields are separated by tabs and values may be empty (e.g. + if no namespace is defined for an exported symbol). For a kernel build without CONFIG_MODVERSIONS enabled, the CRC would read 0x00000000. diff --git a/Documentation/kbuild/namespaces.rst b/Documentation/kbuild/namespaces.rst new file mode 100644 index 000000000000..982ed7b568ac --- /dev/null +++ b/Documentation/kbuild/namespaces.rst @@ -0,0 +1,154 @@ +================= +Symbol Namespaces +================= + +The following document describes how to use Symbol Namespaces to structure the +export surface of in-kernel symbols exported through the family of +EXPORT_SYMBOL() macros. + +.. Table of Contents + + === 1 Introduction + === 2 How to define Symbol Namespaces + --- 2.1 Using the EXPORT_SYMBOL macros + --- 2.2 Using the DEFAULT_SYMBOL_NAMESPACE define + === 3 How to use Symbols exported in Namespaces + === 4 Loading Modules that use namespaced Symbols + === 5 Automatically creating MODULE_IMPORT_NS statements + +1. Introduction +=============== + +Symbol Namespaces have been introduced as a means to structure the export +surface of the in-kernel API. It allows subsystem maintainers to partition +their exported symbols into separate namespaces. That is useful for +documentation purposes (think of the SUBSYSTEM_DEBUG namespace) as well as for +limiting the availability of a set of symbols for use in other parts of the +kernel. As of today, modules that make use of symbols exported into namespaces, +are required to import the namespace. Otherwise the kernel will, depending on +its configuration, reject loading the module or warn about a missing import. + +2. How to define Symbol Namespaces +================================== + +Symbols can be exported into namespace using different methods. All of them are +changing the way EXPORT_SYMBOL and friends are instrumented to create ksymtab +entries. + +2.1 Using the EXPORT_SYMBOL macros +================================== + +In addition to the macros EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL(), that allow +exporting of kernel symbols to the kernel symbol table, variants of these are +available to export symbols into a certain namespace: EXPORT_SYMBOL_NS() and +EXPORT_SYMBOL_NS_GPL(). They take one additional argument: the namespace. +Please note that due to macro expansion that argument needs to be a +preprocessor symbol. E.g. to export the symbol `usb_stor_suspend` into the +namespace `USB_STORAGE`, use:: + + EXPORT_SYMBOL_NS(usb_stor_suspend, USB_STORAGE); + +The corresponding ksymtab entry struct `kernel_symbol` will have the member +`namespace` set accordingly. A symbol that is exported without a namespace will +refer to `NULL`. There is no default namespace if none is defined. `modpost` +and kernel/module.c make use the namespace at build time or module load time, +respectively. + +2.2 Using the DEFAULT_SYMBOL_NAMESPACE define +============================================= + +Defining namespaces for all symbols of a subsystem can be very verbose and may +become hard to maintain. Therefore a default define (DEFAULT_SYMBOL_NAMESPACE) +is been provided, that, if set, will become the default for all EXPORT_SYMBOL() +and EXPORT_SYMBOL_GPL() macro expansions that do not specify a namespace. + +There are multiple ways of specifying this define and it depends on the +subsystem and the maintainer's preference, which one to use. The first option +is to define the default namespace in the `Makefile` of the subsystem. E.g. to +export all symbols defined in usb-common into the namespace USB_COMMON, add a +line like this to drivers/usb/common/Makefile:: + + ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=USB_COMMON + +That will affect all EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL() statements. A +symbol exported with EXPORT_SYMBOL_NS() while this definition is present, will +still be exported into the namespace that is passed as the namespace argument +as this argument has preference over a default symbol namespace. + +A second option to define the default namespace is directly in the compilation +unit as preprocessor statement. The above example would then read:: + + #undef DEFAULT_SYMBOL_NAMESPACE + #define DEFAULT_SYMBOL_NAMESPACE USB_COMMON + +within the corresponding compilation unit before any EXPORT_SYMBOL macro is +used. + +3. How to use Symbols exported in Namespaces +============================================ + +In order to use symbols that are exported into namespaces, kernel modules need +to explicitly import these namespaces. Otherwise the kernel might reject to +load the module. The module code is required to use the macro MODULE_IMPORT_NS +for the namespaces it uses symbols from. E.g. a module using the +usb_stor_suspend symbol from above, needs to import the namespace USB_STORAGE +using a statement like:: + + MODULE_IMPORT_NS(USB_STORAGE); + +This will create a `modinfo` tag in the module for each imported namespace. +This has the side effect, that the imported namespaces of a module can be +inspected with modinfo:: + + $ modinfo drivers/usb/storage/ums-karma.ko + [...] + import_ns: USB_STORAGE + [...] + + +It is advisable to add the MODULE_IMPORT_NS() statement close to other module +metadata definitions like MODULE_AUTHOR() or MODULE_LICENSE(). Refer to section +5. for a way to create missing import statements automatically. + +4. Loading Modules that use namespaced Symbols +============================================== + +At module loading time (e.g. `insmod`), the kernel will check each symbol +referenced from the module for its availability and whether the namespace it +might be exported to has been imported by the module. The default behaviour of +the kernel is to reject loading modules that don't specify sufficient imports. +An error will be logged and loading will be failed with EINVAL. In order to +allow loading of modules that don't satisfy this precondition, a configuration +option is available: Setting MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS=y will +enable loading regardless, but will emit a warning. + +5. Automatically creating MODULE_IMPORT_NS statements +===================================================== + +Missing namespaces imports can easily be detected at build time. In fact, +modpost will emit a warning if a module uses a symbol from a namespace +without importing it. +MODULE_IMPORT_NS() statements will usually be added at a definite location +(along with other module meta data). To make the life of module authors (and +subsystem maintainers) easier, a script and make target is available to fixup +missing imports. Fixing missing imports can be done with:: + + $ make nsdeps + +A typical scenario for module authors would be:: + + - write code that depends on a symbol from a not imported namespace + - `make` + - notice the warning of modpost telling about a missing import + - run `make nsdeps` to add the import to the correct code location + +For subsystem maintainers introducing a namespace, the steps are very similar. +Again, `make nsdeps` will eventually add the missing namespace imports for +in-tree modules:: + + - move or add symbols to a namespace (e.g. with EXPORT_SYMBOL_NS()) + - `make` (preferably with an allmodconfig to cover all in-kernel + modules) + - notice the warning of modpost telling about a missing import + - run `make nsdeps` to add the import to the correct code location + diff --git a/Documentation/kernel-hacking/hacking.rst b/Documentation/kernel-hacking/hacking.rst index 5891a701a159..a3ddb213a5e1 100644 --- a/Documentation/kernel-hacking/hacking.rst +++ b/Documentation/kernel-hacking/hacking.rst @@ -594,6 +594,24 @@ internal implementation issue, and not really an interface. Some maintainers and developers may however require EXPORT_SYMBOL_GPL() when adding any new APIs or functionality. +:c:func:`EXPORT_SYMBOL_NS()` +---------------------------- + +Defined in ``include/linux/export.h`` + +This is the variant of `EXPORT_SYMBOL()` that allows specifying a symbol +namespace. Symbol Namespaces are documented in +``Documentation/kbuild/namespaces.rst``. + +:c:func:`EXPORT_SYMBOL_NS_GPL()` +-------------------------------- + +Defined in ``include/linux/export.h`` + +This is the variant of `EXPORT_SYMBOL_GPL()` that allows specifying a symbol +namespace. Symbol Namespaces are documented in +``Documentation/kbuild/namespaces.rst``. + Routines and Conventions ======================== diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst b/Documentation/media/uapi/v4l/subdev-formats.rst index 7b8e17c7b68b..15e11f27b4c8 100644 --- a/Documentation/media/uapi/v4l/subdev-formats.rst +++ b/Documentation/media/uapi/v4l/subdev-formats.rst @@ -1313,6 +1313,113 @@ The following tables list existing packed RGB formats. - g\ :sub:`6` - g\ :sub:`5` - g\ :sub:`4` + * .. _MEDIA-BUS-FMT-RGB888-3X8: + + - MEDIA_BUS_FMT_RGB888_3X8 + - 0x101c + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - r\ :sub:`7` + - r\ :sub:`6` + - r\ :sub:`5` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + * - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - g\ :sub:`7` + - g\ :sub:`6` + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + * - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - b\ :sub:`7` + - b\ :sub:`6` + - b\ :sub:`5` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` * .. _MEDIA-BUS-FMT-ARGB888-1X32: - MEDIA_BUS_FMT_ARGB888_1X32 diff --git a/Documentation/mips/index.rst b/Documentation/mips/index.rst index fd9023c8a89f..a93c2f65884c 100644 --- a/Documentation/mips/index.rst +++ b/Documentation/mips/index.rst @@ -1,11 +1,14 @@ .. SPDX-License-Identifier: GPL-2.0 -================= -MIPS architecture -================= +=========================== +MIPS-specific Documentation +=========================== .. toctree:: :maxdepth: 2 + :numbered: + + ingenic-tcu au1xxx_ide diff --git a/Documentation/mips/ingenic-tcu.rst b/Documentation/mips/ingenic-tcu.rst new file mode 100644 index 000000000000..c4ef4c45aade --- /dev/null +++ b/Documentation/mips/ingenic-tcu.rst @@ -0,0 +1,71 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============================================== +Ingenic JZ47xx SoCs Timer/Counter Unit hardware +=============================================== + +The Timer/Counter Unit (TCU) in Ingenic JZ47xx SoCs is a multi-function +hardware block. It features up to to eight channels, that can be used as +counters, timers, or PWM. + +- JZ4725B, JZ4750, JZ4755 only have six TCU channels. The other SoCs all + have eight channels. + +- JZ4725B introduced a separate channel, called Operating System Timer + (OST). It is a 32-bit programmable timer. On JZ4760B and above, it is + 64-bit. + +- Each one of the TCU channels has its own clock, which can be reparented to three + different clocks (pclk, ext, rtc), gated, and reclocked, through their TCSR register. + + - The watchdog and OST hardware blocks also feature a TCSR register with the same + format in their register space. + - The TCU registers used to gate/ungate can also gate/ungate the watchdog and + OST clocks. + +- Each TCU channel works in one of two modes: + + - mode TCU1: channels cannot work in sleep mode, but are easier to + operate. + - mode TCU2: channels can work in sleep mode, but the operation is a bit + more complicated than with TCU1 channels. + +- The mode of each TCU channel depends on the SoC used: + + - On the oldest SoCs (up to JZ4740), all of the eight channels operate in + TCU1 mode. + - On JZ4725B, channel 5 operates as TCU2, the others operate as TCU1. + - On newest SoCs (JZ4750 and above), channels 1-2 operate as TCU2, the + others operate as TCU1. + +- Each channel can generate an interrupt. Some channels share an interrupt + line, some don't, and this changes between SoC versions: + + - on older SoCs (JZ4740 and below), channel 0 and channel 1 have their + own interrupt line; channels 2-7 share the last interrupt line. + - On JZ4725B, channel 0 has its own interrupt; channels 1-5 share one + interrupt line; the OST uses the last interrupt line. + - on newer SoCs (JZ4750 and above), channel 5 has its own interrupt; + channels 0-4 and (if eight channels) 6-7 all share one interrupt line; + the OST uses the last interrupt line. + +Implementation +============== + +The functionalities of the TCU hardware are spread across multiple drivers: + +=========== ===== +clocks drivers/clk/ingenic/tcu.c +interrupts drivers/irqchip/irq-ingenic-tcu.c +timers drivers/clocksource/ingenic-timer.c +OST drivers/clocksource/ingenic-ost.c +PWM drivers/pwm/pwm-jz4740.c +watchdog drivers/watchdog/jz4740_wdt.c +=========== ===== + +Because various functionalities of the TCU that belong to different drivers +and frameworks can be controlled from the same registers, all of these +drivers access their registers through the same regmap. + +For more information regarding the devicetree bindings of the TCU drivers, +have a look at Documentation/devicetree/bindings/mfd/ingenic,tcu.txt. diff --git a/Documentation/powerpc/elfnote.rst b/Documentation/powerpc/elfnote.rst new file mode 100644 index 000000000000..06602248621c --- /dev/null +++ b/Documentation/powerpc/elfnote.rst @@ -0,0 +1,41 @@ +========================== +ELF Note PowerPC Namespace +========================== + +The PowerPC namespace in an ELF Note of the kernel binary is used to store +capabilities and information which can be used by a bootloader or userland. + +Types and Descriptors +--------------------- + +The types to be used with the "PowerPC" namesapce are defined in [#f1]_. + + 1) PPC_ELFNOTE_CAPABILITIES + +Define the capabilities supported/required by the kernel. This type uses a +bitmap as "descriptor" field. Each bit is described below: + +- Ultravisor-capable bit (PowerNV only). + +.. code-block:: c + + #define PPCCAP_ULTRAVISOR_BIT (1 << 0) + +Indicate that the powerpc kernel binary knows how to run in an +ultravisor-enabled system. + +In an ultravisor-enabled system, some machine resources are now controlled +by the ultravisor. If the kernel is not ultravisor-capable, but it ends up +being run on a machine with ultravisor, the kernel will probably crash +trying to access ultravisor resources. For instance, it may crash in early +boot trying to set the partition table entry 0. + +In an ultravisor-enabled system, a bootloader could warn the user or prevent +the kernel from being run if the PowerPC ultravisor capability doesn't exist +or the Ultravisor-capable bit is not set. + +References +---------- + +.. [#f1] arch/powerpc/include/asm/elfnote.h + diff --git a/Documentation/powerpc/firmware-assisted-dump.rst b/Documentation/powerpc/firmware-assisted-dump.rst index 9ca12830a48e..0455a78486d5 100644 --- a/Documentation/powerpc/firmware-assisted-dump.rst +++ b/Documentation/powerpc/firmware-assisted-dump.rst @@ -9,18 +9,18 @@ a crashed system, and to do so from a fully-reset system, and to minimize the total elapsed time until the system is back in production use. -- Firmware assisted dump (fadump) infrastructure is intended to replace +- Firmware-Assisted Dump (FADump) infrastructure is intended to replace the existing phyp assisted dump. - Fadump uses the same firmware interfaces and memory reservation model as phyp assisted dump. -- Unlike phyp dump, fadump exports the memory dump through /proc/vmcore +- Unlike phyp dump, FADump exports the memory dump through /proc/vmcore in the ELF format in the same way as kdump. This helps us reuse the kdump infrastructure for dump capture and filtering. - Unlike phyp dump, userspace tool does not need to refer any sysfs interface while reading /proc/vmcore. -- Unlike phyp dump, fadump allows user to release all the memory reserved +- Unlike phyp dump, FADump allows user to release all the memory reserved for dump, with a single operation of echo 1 > /sys/kernel/fadump_release_mem. -- Once enabled through kernel boot parameter, fadump can be +- Once enabled through kernel boot parameter, FADump can be started/stopped through /sys/kernel/fadump_registered interface (see sysfs files section below) and can be easily integrated with kdump service start/stop init scripts. @@ -34,7 +34,7 @@ dump offers several strong, practical advantages: in a clean, consistent state. - Once the dump is copied out, the memory that held the dump is immediately available to the running kernel. And therefore, - unlike kdump, fadump doesn't need a 2nd reboot to get back + unlike kdump, FADump doesn't need a 2nd reboot to get back the system to the production configuration. The above can only be accomplished by coordination with, @@ -46,10 +46,9 @@ as follows: These registered sections of memory are reserved by the first kernel during early boot. -- When a system crashes, the Power firmware will save - the low memory (boot memory of size larger of 5% of system RAM - or 256MB) of RAM to the previous registered region. It will - also save system registers, and hardware PTE's. +- When system crashes, the Power firmware will copy the registered + low memory regions (boot memory) from source to destination area. + It will also save hardware PTE's. NOTE: The term 'boot memory' means size of the low memory chunk @@ -61,9 +60,9 @@ as follows: the default calculated size. Use this option if default boot memory size is not sufficient for second kernel to boot successfully. For syntax of crashkernel= parameter, - refer to Documentation/admin-guide/kdump/kdump.rst. If any offset is - provided in crashkernel= parameter, it will be ignored - as fadump uses a predefined offset to reserve memory + refer to Documentation/admin-guide/kdump/kdump.rst. If any + offset is provided in crashkernel= parameter, it will be + ignored as FADump uses a predefined offset to reserve memory for boot memory dump preservation in case of a crash. - After the low memory (boot memory) area has been saved, the @@ -71,13 +70,15 @@ as follows: *not* clear the RAM. It will then launch the bootloader, as normal. -- The freshly booted kernel will notice that there is a new - node (ibm,dump-kernel) in the device tree, indicating that +- The freshly booted kernel will notice that there is a new node + (rtas/ibm,kernel-dump on pSeries or ibm,opal/dump/mpipl-boot + on OPAL platform) in the device tree, indicating that there is crash data available from a previous boot. During the early boot OS will reserve rest of the memory above boot memory size effectively booting with restricted memory - size. This will make sure that the second kernel will not - touch any of the dump memory area. + size. This will make sure that this kernel (also, referred + to as second kernel or capture kernel) will not touch any + of the dump memory area. - User-space tools will read /proc/vmcore to obtain the contents of memory, which holds the previous crashed kernel dump in ELF @@ -94,8 +95,30 @@ as follows: # echo 1 > /sys/kernel/fadump_release_mem Please note that the firmware-assisted dump feature -is only available on Power6 and above systems with recent -firmware versions. +is only available on POWER6 and above systems on pSeries +(PowerVM) platform and POWER9 and above systems with OP940 +or later firmware versions on PowerNV (OPAL) platform. +Note that, OPAL firmware exports ibm,opal/dump node when +FADump is supported on PowerNV platform. + +On OPAL based machines, system first boots into an intermittent +kernel (referred to as petitboot kernel) before booting into the +capture kernel. This kernel would have minimal kernel and/or +userspace support to process crash data. Such kernel needs to +preserve previously crash'ed kernel's memory for the subsequent +capture kernel boot to process this crash data. Kernel config +option CONFIG_PRESERVE_FA_DUMP has to be enabled on such kernel +to ensure that crash data is preserved to process later. + +-- On OPAL based machines (PowerNV), if the kernel is build with + CONFIG_OPAL_CORE=y, OPAL memory at the time of crash is also + exported as /sys/firmware/opal/core file. This procfs file is + helpful in debugging OPAL crashes with GDB. The kernel memory + used for exporting this procfs file can be released by echo'ing + '1' to /sys/kernel/fadump_release_opalcore node. + + e.g. + # echo 1 > /sys/kernel/fadump_release_opalcore Implementation details: ----------------------- @@ -110,72 +133,95 @@ that are run. If there is dump data, then the /sys/kernel/fadump_release_mem file is created, and the reserved memory is held. -If there is no waiting dump data, then only the memory required -to hold CPU state, HPTE region, boot memory dump and elfcore -header, is usually reserved at an offset greater than boot memory -size (see Fig. 1). This area is *not* released: this region will -be kept permanently reserved, so that it can act as a receptacle -for a copy of the boot memory content in addition to CPU state -and HPTE region, in the case a crash does occur. Since this reserved -memory area is used only after the system crash, there is no point in -blocking this significant chunk of memory from production kernel. -Hence, the implementation uses the Linux kernel's Contiguous Memory -Allocator (CMA) for memory reservation if CMA is configured for kernel. -With CMA reservation this memory will be available for applications to -use it, while kernel is prevented from using it. With this fadump will -still be able to capture all of the kernel memory and most of the user -space memory except the user pages that were present in CMA region:: +If there is no waiting dump data, then only the memory required to +hold CPU state, HPTE region, boot memory dump, FADump header and +elfcore header, is usually reserved at an offset greater than boot +memory size (see Fig. 1). This area is *not* released: this region +will be kept permanently reserved, so that it can act as a receptacle +for a copy of the boot memory content in addition to CPU state and +HPTE region, in the case a crash does occur. + +Since this reserved memory area is used only after the system crash, +there is no point in blocking this significant chunk of memory from +production kernel. Hence, the implementation uses the Linux kernel's +Contiguous Memory Allocator (CMA) for memory reservation if CMA is +configured for kernel. With CMA reservation this memory will be +available for applications to use it, while kernel is prevented from +using it. With this FADump will still be able to capture all of the +kernel memory and most of the user space memory except the user pages +that were present in CMA region:: o Memory Reservation during first kernel - Low memory Top of memory - 0 boot memory size | - | | |<--Reserved dump area -->| | - V V | Permanent Reservation | V - +-----------+----------/ /---+---+----+-----------+----+------+ - | | |CPU|HPTE| DUMP |ELF | | - +-----------+----------/ /---+---+----+-----------+----+------+ - | ^ - | | - \ / - ------------------------------------------- - Boot memory content gets transferred to - reserved area by firmware at the time of - crash + Low memory Top of memory + 0 boot memory size |<--- Reserved dump area --->| | + | | | Permanent Reservation | | + V V | | V + +-----------+-----/ /---+---+----+-------+-----+-----+----+--+ + | | |///|////| DUMP | HDR | ELF |////| | + +-----------+-----/ /---+---+----+-------+-----+-----+----+--+ + | ^ ^ ^ ^ ^ + | | | | | | + \ CPU HPTE / | | + ------------------------------ | | + Boot memory content gets transferred | | + to reserved area by firmware at the | | + time of crash. | | + FADump Header | + (meta area) | + | + | + Metadata: This area holds a metadata struture whose + address is registered with f/w and retrieved in the + second kernel after crash, on platforms that support + tags (OPAL). Having such structure with info needed + to process the crashdump eases dump capture process. + Fig. 1 + o Memory Reservation during second kernel after crash - Low memory Top of memory - 0 boot memory size | - | |<------------- Reserved dump area ----------- -->| - V V V - +-----------+----------/ /---+---+----+-----------+----+------+ - | | |CPU|HPTE| DUMP |ELF | | - +-----------+----------/ /---+---+----+-----------+----+------+ - | | - V V - Used by second /proc/vmcore + Low memory Top of memory + 0 boot memory size | + | |<------------ Crash preserved area ------------>| + V V |<--- Reserved dump area --->| | + +-----------+-----/ /---+---+----+-------+-----+-----+----+--+ + | | |///|////| DUMP | HDR | ELF |////| | + +-----------+-----/ /---+---+----+-------+-----+-----+----+--+ + | | + V V + Used by second /proc/vmcore kernel to boot + + +---+ + |///| -> Regions (CPU, HPTE & Metadata) marked like this in the above + +---+ figures are not always present. For example, OPAL platform + does not have CPU & HPTE regions while Metadata region is + not supported on pSeries currently. + Fig. 2 -Currently the dump will be copied from /proc/vmcore to a -a new file upon user intervention. The dump data available through -/proc/vmcore will be in ELF format. Hence the existing kdump -infrastructure (kdump scripts) to save the dump works fine with -minor modifications. + +Currently the dump will be copied from /proc/vmcore to a new file upon +user intervention. The dump data available through /proc/vmcore will be +in ELF format. Hence the existing kdump infrastructure (kdump scripts) +to save the dump works fine with minor modifications. KDump scripts on +major Distro releases have already been modified to work seemlessly (no +user intervention in saving the dump) when FADump is used, instead of +KDump, as dump mechanism. The tools to examine the dump will be same as the ones used for kdump. -How to enable firmware-assisted dump (fadump): +How to enable firmware-assisted dump (FADump): ---------------------------------------------- 1. Set config option CONFIG_FA_DUMP=y and build kernel. 2. Boot into linux kernel with 'fadump=on' kernel cmdline option. - By default, fadump reserved memory will be initialized as CMA area. + By default, FADump reserved memory will be initialized as CMA area. Alternatively, user can boot linux kernel with 'fadump=nocma' to - prevent fadump to use CMA. + prevent FADump to use CMA. 3. Optionally, user can also set 'crashkernel=' kernel cmdline to specify size of the memory to reserve for boot memory dump preservation. @@ -201,29 +247,29 @@ the control files and debugfs file to display memory reserved region. Here is the list of files under kernel sysfs: /sys/kernel/fadump_enabled - This is used to display the fadump status. + This is used to display the FADump status. - - 0 = fadump is disabled - - 1 = fadump is enabled + - 0 = FADump is disabled + - 1 = FADump is enabled This interface can be used by kdump init scripts to identify if - fadump is enabled in the kernel and act accordingly. + FADump is enabled in the kernel and act accordingly. /sys/kernel/fadump_registered - This is used to display the fadump registration status as well - as to control (start/stop) the fadump registration. + This is used to display the FADump registration status as well + as to control (start/stop) the FADump registration. - - 0 = fadump is not registered. - - 1 = fadump is registered and ready to handle system crash. + - 0 = FADump is not registered. + - 1 = FADump is registered and ready to handle system crash. - To register fadump echo 1 > /sys/kernel/fadump_registered and + To register FADump echo 1 > /sys/kernel/fadump_registered and echo 0 > /sys/kernel/fadump_registered for un-register and stop the - fadump. Once the fadump is un-registered, the system crash will not + FADump. Once the FADump is un-registered, the system crash will not be handled and vmcore will not be captured. This interface can be easily integrated with kdump service start/stop. /sys/kernel/fadump_release_mem - This file is available only when fadump is active during + This file is available only when FADump is active during second kernel. This is used to release the reserved memory region that are held for saving crash dump. To release the reserved memory echo 1 to it:: @@ -237,25 +283,38 @@ Here is the list of files under kernel sysfs: enhanced to use this interface to release the memory reserved for dump and continue without 2nd reboot. + /sys/kernel/fadump_release_opalcore + + This file is available only on OPAL based machines when FADump is + active during capture kernel. This is used to release the memory + used by the kernel to export /sys/firmware/opal/core file. To + release this memory, echo '1' to it: + + echo 1 > /sys/kernel/fadump_release_opalcore + Here is the list of files under powerpc debugfs: (Assuming debugfs is mounted on /sys/kernel/debug directory.) /sys/kernel/debug/powerpc/fadump_region - This file shows the reserved memory regions if fadump is + This file shows the reserved memory regions if FADump is enabled otherwise this file is empty. The output format is:: <region>: [<start>-<end>] <reserved-size> bytes, Dumped: <dump-size> + and for kernel DUMP region is: + + DUMP: Src: <src-addr>, Dest: <dest-addr>, Size: <size>, Dumped: # bytes + e.g. - Contents when fadump is registered during first kernel:: + Contents when FADump is registered during first kernel:: # cat /sys/kernel/debug/powerpc/fadump_region CPU : [0x0000006ffb0000-0x0000006fff001f] 0x40020 bytes, Dumped: 0x0 HPTE: [0x0000006fff0020-0x0000006fff101f] 0x1000 bytes, Dumped: 0x0 DUMP: [0x0000006fff1020-0x0000007fff101f] 0x10000000 bytes, Dumped: 0x0 - Contents when fadump is active during second kernel:: + Contents when FADump is active during second kernel:: # cat /sys/kernel/debug/powerpc/fadump_region CPU : [0x0000006ffb0000-0x0000006fff001f] 0x40020 bytes, Dumped: 0x40020 @@ -263,6 +322,7 @@ Here is the list of files under powerpc debugfs: DUMP: [0x0000006fff1020-0x0000007fff101f] 0x10000000 bytes, Dumped: 0x10000000 : [0x00000010000000-0x0000006ffaffff] 0x5ffb0000 bytes, Dumped: 0x5ffb0000 + NOTE: Please refer to Documentation/filesystems/debugfs.txt on how to mount the debugfs filesystem. @@ -273,7 +333,7 @@ TODO: - Need to come up with the better approach to find out more accurate boot memory size that is required for a kernel to boot successfully when booted with restricted memory. - - The fadump implementation introduces a fadump crash info structure + - The FADump implementation introduces a FADump crash info structure in the scratch area before the ELF core header. The idea of introducing this structure is to pass some important crash info data to the second kernel which will help second kernel to populate ELF core header with diff --git a/Documentation/powerpc/index.rst b/Documentation/powerpc/index.rst index 549b1cdd77ae..db7b6a880f52 100644 --- a/Documentation/powerpc/index.rst +++ b/Documentation/powerpc/index.rst @@ -15,6 +15,7 @@ powerpc dawr-power9 dscr eeh-pci-error-recovery + elfnote firmware-assisted-dump hvcs isa-versions @@ -25,6 +26,7 @@ powerpc qe_firmware syscall64-abi transactional_memory + ultravisor .. only:: subproject and html diff --git a/Documentation/powerpc/ultravisor.rst b/Documentation/powerpc/ultravisor.rst new file mode 100644 index 000000000000..730854f73830 --- /dev/null +++ b/Documentation/powerpc/ultravisor.rst @@ -0,0 +1,1054 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. _ultravisor: + +============================ +Protected Execution Facility +============================ + +.. contents:: + :depth: 3 + +Protected Execution Facility +############################ + + Protected Execution Facility (PEF) is an architectural change for + POWER 9 that enables Secure Virtual Machines (SVMs). DD2.3 chips + (PVR=0x004e1203) or greater will be PEF-capable. A new ISA release + will include the PEF RFC02487 changes. + + When enabled, PEF adds a new higher privileged mode, called Ultravisor + mode, to POWER architecture. Along with the new mode there is new + firmware called the Protected Execution Ultravisor (or Ultravisor + for short). Ultravisor mode is the highest privileged mode in POWER + architecture. + + +------------------+ + | Privilege States | + +==================+ + | Problem | + +------------------+ + | Supervisor | + +------------------+ + | Hypervisor | + +------------------+ + | Ultravisor | + +------------------+ + + PEF protects SVMs from the hypervisor, privileged users, and other + VMs in the system. SVMs are protected while at rest and can only be + executed by an authorized machine. All virtual machines utilize + hypervisor services. The Ultravisor filters calls between the SVMs + and the hypervisor to assure that information does not accidentally + leak. All hypercalls except H_RANDOM are reflected to the hypervisor. + H_RANDOM is not reflected to prevent the hypervisor from influencing + random values in the SVM. + + To support this there is a refactoring of the ownership of resources + in the CPU. Some of the resources which were previously hypervisor + privileged are now ultravisor privileged. + +Hardware +======== + + The hardware changes include the following: + + * There is a new bit in the MSR that determines whether the current + process is running in secure mode, MSR(S) bit 41. MSR(S)=1, process + is in secure mode, MSR(s)=0 process is in normal mode. + + * The MSR(S) bit can only be set by the Ultravisor. + + * HRFID cannot be used to set the MSR(S) bit. If the hypervisor needs + to return to a SVM it must use an ultracall. It can determine if + the VM it is returning to is secure. + + * There is a new Ultravisor privileged register, SMFCTRL, which has an + enable/disable bit SMFCTRL(E). + + * The privilege of a process is now determined by three MSR bits, + MSR(S, HV, PR). In each of the tables below the modes are listed + from least privilege to highest privilege. The higher privilege + modes can access all the resources of the lower privilege modes. + + **Secure Mode MSR Settings** + + +---+---+---+---------------+ + | S | HV| PR|Privilege | + +===+===+===+===============+ + | 1 | 0 | 1 | Problem | + +---+---+---+---------------+ + | 1 | 0 | 0 | Privileged(OS)| + +---+---+---+---------------+ + | 1 | 1 | 0 | Ultravisor | + +---+---+---+---------------+ + | 1 | 1 | 1 | Reserved | + +---+---+---+---------------+ + + **Normal Mode MSR Settings** + + +---+---+---+---------------+ + | S | HV| PR|Privilege | + +===+===+===+===============+ + | 0 | 0 | 1 | Problem | + +---+---+---+---------------+ + | 0 | 0 | 0 | Privileged(OS)| + +---+---+---+---------------+ + | 0 | 1 | 0 | Hypervisor | + +---+---+---+---------------+ + | 0 | 1 | 1 | Problem (Host)| + +---+---+---+---------------+ + + * Memory is partitioned into secure and normal memory. Only processes + that are running in secure mode can access secure memory. + + * The hardware does not allow anything that is not running secure to + access secure memory. This means that the Hypervisor cannot access + the memory of the SVM without using an ultracall (asking the + Ultravisor). The Ultravisor will only allow the hypervisor to see + the SVM memory encrypted. + + * I/O systems are not allowed to directly address secure memory. This + limits the SVMs to virtual I/O only. + + * The architecture allows the SVM to share pages of memory with the + hypervisor that are not protected with encryption. However, this + sharing must be initiated by the SVM. + + * When a process is running in secure mode all hypercalls + (syscall lev=1) go to the Ultravisor. + + * When a process is in secure mode all interrupts go to the + Ultravisor. + + * The following resources have become Ultravisor privileged and + require an Ultravisor interface to manipulate: + + * Processor configurations registers (SCOMs). + + * Stop state information. + + * The debug registers CIABR, DAWR, and DAWRX when SMFCTRL(D) is set. + If SMFCTRL(D) is not set they do not work in secure mode. When set, + reading and writing requires an Ultravisor call, otherwise that + will cause a Hypervisor Emulation Assistance interrupt. + + * PTCR and partition table entries (partition table is in secure + memory). An attempt to write to PTCR will cause a Hypervisor + Emulation Assitance interrupt. + + * LDBAR (LD Base Address Register) and IMC (In-Memory Collection) + non-architected registers. An attempt to write to them will cause a + Hypervisor Emulation Assistance interrupt. + + * Paging for an SVM, sharing of memory with Hypervisor for an SVM. + (Including Virtual Processor Area (VPA) and virtual I/O). + + +Software/Microcode +================== + + The software changes include: + + * SVMs are created from normal VM using (open source) tooling supplied + by IBM. + + * All SVMs start as normal VMs and utilize an ultracall, UV_ESM + (Enter Secure Mode), to make the transition. + + * When the UV_ESM ultracall is made the Ultravisor copies the VM into + secure memory, decrypts the verification information, and checks the + integrity of the SVM. If the integrity check passes the Ultravisor + passes control in secure mode. + + * The verification information includes the pass phrase for the + encrypted disk associated with the SVM. This pass phrase is given + to the SVM when requested. + + * The Ultravisor is not involved in protecting the encrypted disk of + the SVM while at rest. + + * For external interrupts the Ultravisor saves the state of the SVM, + and reflects the interrupt to the hypervisor for processing. + For hypercalls, the Ultravisor inserts neutral state into all + registers not needed for the hypercall then reflects the call to + the hypervisor for processing. The H_RANDOM hypercall is performed + by the Ultravisor and not reflected. + + * For virtual I/O to work bounce buffering must be done. + + * The Ultravisor uses AES (IAPM) for protection of SVM memory. IAPM + is a mode of AES that provides integrity and secrecy concurrently. + + * The movement of data between normal and secure pages is coordinated + with the Ultravisor by a new HMM plug-in in the Hypervisor. + + The Ultravisor offers new services to the hypervisor and SVMs. These + are accessed through ultracalls. + +Terminology +=========== + + * Hypercalls: special system calls used to request services from + Hypervisor. + + * Normal memory: Memory that is accessible to Hypervisor. + + * Normal page: Page backed by normal memory and available to + Hypervisor. + + * Shared page: A page backed by normal memory and available to both + the Hypervisor/QEMU and the SVM (i.e page has mappings in SVM and + Hypervisor/QEMU). + + * Secure memory: Memory that is accessible only to Ultravisor and + SVMs. + + * Secure page: Page backed by secure memory and only available to + Ultravisor and SVM. + + * SVM: Secure Virtual Machine. + + * Ultracalls: special system calls used to request services from + Ultravisor. + + +Ultravisor calls API +#################### + + This section describes Ultravisor calls (ultracalls) needed to + support Secure Virtual Machines (SVM)s and Paravirtualized KVM. The + ultracalls allow the SVMs and Hypervisor to request services from the + Ultravisor such as accessing a register or memory region that can only + be accessed when running in Ultravisor-privileged mode. + + The specific service needed from an ultracall is specified in register + R3 (the first parameter to the ultracall). Other parameters to the + ultracall, if any, are specified in registers R4 through R12. + + Return value of all ultracalls is in register R3. Other output values + from the ultracall, if any, are returned in registers R4 through R12. + The only exception to this register usage is the ``UV_RETURN`` + ultracall described below. + + Each ultracall returns specific error codes, applicable in the context + of the ultracall. However, like with the PowerPC Architecture Platform + Reference (PAPR), if no specific error code is defined for a + particular situation, then the ultracall will fallback to an erroneous + parameter-position based code. i.e U_PARAMETER, U_P2, U_P3 etc + depending on the ultracall parameter that may have caused the error. + + Some ultracalls involve transferring a page of data between Ultravisor + and Hypervisor. Secure pages that are transferred from secure memory + to normal memory may be encrypted using dynamically generated keys. + When the secure pages are transferred back to secure memory, they may + be decrypted using the same dynamically generated keys. Generation and + management of these keys will be covered in a separate document. + + For now this only covers ultracalls currently implemented and being + used by Hypervisor and SVMs but others can be added here when it + makes sense. + + The full specification for all hypercalls/ultracalls will eventually + be made available in the public/OpenPower version of the PAPR + specification. + + .. note:: + + If PEF is not enabled, the ultracalls will be redirected to the + Hypervisor which must handle/fail the calls. + +Ultracalls used by Hypervisor +============================= + + This section describes the virtual memory management ultracalls used + by the Hypervisor to manage SVMs. + +UV_PAGE_OUT +----------- + + Encrypt and move the contents of a page from secure memory to normal + memory. + +Syntax +~~~~~~ + +.. code-block:: c + + uint64_t ultracall(const uint64_t UV_PAGE_OUT, + uint16_t lpid, /* LPAR ID */ + uint64_t dest_ra, /* real address of destination page */ + uint64_t src_gpa, /* source guest-physical-address */ + uint8_t flags, /* flags */ + uint64_t order) /* page size order */ + +Return values +~~~~~~~~~~~~~ + + One of the following values: + + * U_SUCCESS on success. + * U_PARAMETER if ``lpid`` is invalid. + * U_P2 if ``dest_ra`` is invalid. + * U_P3 if the ``src_gpa`` address is invalid. + * U_P4 if any bit in the ``flags`` is unrecognized + * U_P5 if the ``order`` parameter is unsupported. + * U_FUNCTION if functionality is not supported. + * U_BUSY if page cannot be currently paged-out. + +Description +~~~~~~~~~~~ + + Encrypt the contents of a secure-page and make it available to + Hypervisor in a normal page. + + By default, the source page is unmapped from the SVM's partition- + scoped page table. But the Hypervisor can provide a hint to the + Ultravisor to retain the page mapping by setting the ``UV_SNAPSHOT`` + flag in ``flags`` parameter. + + If the source page is already a shared page the call returns + U_SUCCESS, without doing anything. + +Use cases +~~~~~~~~~ + + #. QEMU attempts to access an address belonging to the SVM but the + page frame for that address is not mapped into QEMU's address + space. In this case, the Hypervisor will allocate a page frame, + map it into QEMU's address space and issue the ``UV_PAGE_OUT`` + call to retrieve the encrypted contents of the page. + + #. When Ultravisor runs low on secure memory and it needs to page-out + an LRU page. In this case, Ultravisor will issue the + ``H_SVM_PAGE_OUT`` hypercall to the Hypervisor. The Hypervisor will + then allocate a normal page and issue the ``UV_PAGE_OUT`` ultracall + and the Ultravisor will encrypt and move the contents of the secure + page into the normal page. + + #. When Hypervisor accesses SVM data, the Hypervisor requests the + Ultravisor to transfer the corresponding page into a insecure page, + which the Hypervisor can access. The data in the normal page will + be encrypted though. + +UV_PAGE_IN +---------- + + Move the contents of a page from normal memory to secure memory. + +Syntax +~~~~~~ + +.. code-block:: c + + uint64_t ultracall(const uint64_t UV_PAGE_IN, + uint16_t lpid, /* the LPAR ID */ + uint64_t src_ra, /* source real address of page */ + uint64_t dest_gpa, /* destination guest physical address */ + uint64_t flags, /* flags */ + uint64_t order) /* page size order */ + +Return values +~~~~~~~~~~~~~ + + One of the following values: + + * U_SUCCESS on success. + * U_BUSY if page cannot be currently paged-in. + * U_FUNCTION if functionality is not supported + * U_PARAMETER if ``lpid`` is invalid. + * U_P2 if ``src_ra`` is invalid. + * U_P3 if the ``dest_gpa`` address is invalid. + * U_P4 if any bit in the ``flags`` is unrecognized + * U_P5 if the ``order`` parameter is unsupported. + +Description +~~~~~~~~~~~ + + Move the contents of the page identified by ``src_ra`` from normal + memory to secure memory and map it to the guest physical address + ``dest_gpa``. + + If `dest_gpa` refers to a shared address, map the page into the + partition-scoped page-table of the SVM. If `dest_gpa` is not shared, + copy the contents of the page into the corresponding secure page. + Depending on the context, decrypt the page before being copied. + + The caller provides the attributes of the page through the ``flags`` + parameter. Valid values for ``flags`` are: + + * CACHE_INHIBITED + * CACHE_ENABLED + * WRITE_PROTECTION + + The Hypervisor must pin the page in memory before making + ``UV_PAGE_IN`` ultracall. + +Use cases +~~~~~~~~~ + + #. When a normal VM switches to secure mode, all its pages residing + in normal memory, are moved into secure memory. + + #. When an SVM requests to share a page with Hypervisor the Hypervisor + allocates a page and informs the Ultravisor. + + #. When an SVM accesses a secure page that has been paged-out, + Ultravisor invokes the Hypervisor to locate the page. After + locating the page, the Hypervisor uses UV_PAGE_IN to make the + page available to Ultravisor. + +UV_PAGE_INVAL +------------- + + Invalidate the Ultravisor mapping of a page. + +Syntax +~~~~~~ + +.. code-block:: c + + uint64_t ultracall(const uint64_t UV_PAGE_INVAL, + uint16_t lpid, /* the LPAR ID */ + uint64_t guest_pa, /* destination guest-physical-address */ + uint64_t order) /* page size order */ + +Return values +~~~~~~~~~~~~~ + + One of the following values: + + * U_SUCCESS on success. + * U_PARAMETER if ``lpid`` is invalid. + * U_P2 if ``guest_pa`` is invalid (or corresponds to a secure + page mapping). + * U_P3 if the ``order`` is invalid. + * U_FUNCTION if functionality is not supported. + * U_BUSY if page cannot be currently invalidated. + +Description +~~~~~~~~~~~ + + This ultracall informs Ultravisor that the page mapping in Hypervisor + corresponding to the given guest physical address has been invalidated + and that the Ultravisor should not access the page. If the specified + ``guest_pa`` corresponds to a secure page, Ultravisor will ignore the + attempt to invalidate the page and return U_P2. + +Use cases +~~~~~~~~~ + + #. When a shared page is unmapped from the QEMU's page table, possibly + because it is paged-out to disk, Ultravisor needs to know that the + page should not be accessed from its side too. + + +UV_WRITE_PATE +------------- + + Validate and write the partition table entry (PATE) for a given + partition. + +Syntax +~~~~~~ + +.. code-block:: c + + uint64_t ultracall(const uint64_t UV_WRITE_PATE, + uint32_t lpid, /* the LPAR ID */ + uint64_t dw0 /* the first double word to write */ + uint64_t dw1) /* the second double word to write */ + +Return values +~~~~~~~~~~~~~ + + One of the following values: + + * U_SUCCESS on success. + * U_BUSY if PATE cannot be currently written to. + * U_FUNCTION if functionality is not supported. + * U_PARAMETER if ``lpid`` is invalid. + * U_P2 if ``dw0`` is invalid. + * U_P3 if the ``dw1`` address is invalid. + * U_PERMISSION if the Hypervisor is attempting to change the PATE + of a secure virtual machine or if called from a + context other than Hypervisor. + +Description +~~~~~~~~~~~ + + Validate and write a LPID and its partition-table-entry for the given + LPID. If the LPID is already allocated and initialized, this call + results in changing the partition table entry. + +Use cases +~~~~~~~~~ + + #. The Partition table resides in Secure memory and its entries, + called PATE (Partition Table Entries), point to the partition- + scoped page tables for the Hypervisor as well as each of the + virtual machines (both secure and normal). The Hypervisor + operates in partition 0 and its partition-scoped page tables + reside in normal memory. + + #. This ultracall allows the Hypervisor to register the partition- + scoped and process-scoped page table entries for the Hypervisor + and other partitions (virtual machines) with the Ultravisor. + + #. If the value of the PATE for an existing partition (VM) changes, + the TLB cache for the partition is flushed. + + #. The Hypervisor is responsible for allocating LPID. The LPID and + its PATE entry are registered together. The Hypervisor manages + the PATE entries for a normal VM and can change the PATE entry + anytime. Ultravisor manages the PATE entries for an SVM and + Hypervisor is not allowed to modify them. + +UV_RETURN +--------- + + Return control from the Hypervisor back to the Ultravisor after + processing an hypercall or interrupt that was forwarded (aka + *reflected*) to the Hypervisor. + +Syntax +~~~~~~ + +.. code-block:: c + + uint64_t ultracall(const uint64_t UV_RETURN) + +Return values +~~~~~~~~~~~~~ + + This call never returns to Hypervisor on success. It returns + U_INVALID if ultracall is not made from a Hypervisor context. + +Description +~~~~~~~~~~~ + + When an SVM makes an hypercall or incurs some other exception, the + Ultravisor usually forwards (aka *reflects*) the exceptions to the + Hypervisor. After processing the exception, Hypervisor uses the + ``UV_RETURN`` ultracall to return control back to the SVM. + + The expected register state on entry to this ultracall is: + + * Non-volatile registers are restored to their original values. + * If returning from an hypercall, register R0 contains the return + value (**unlike other ultracalls**) and, registers R4 through R12 + contain any output values of the hypercall. + * R3 contains the ultracall number, i.e UV_RETURN. + * If returning with a synthesized interrupt, R2 contains the + synthesized interrupt number. + +Use cases +~~~~~~~~~ + + #. Ultravisor relies on the Hypervisor to provide several services to + the SVM such as processing hypercall and other exceptions. After + processing the exception, Hypervisor uses UV_RETURN to return + control back to the Ultravisor. + + #. Hypervisor has to use this ultracall to return control to the SVM. + + +UV_REGISTER_MEM_SLOT +-------------------- + + Register an SVM address-range with specified properties. + +Syntax +~~~~~~ + +.. code-block:: c + + uint64_t ultracall(const uint64_t UV_REGISTER_MEM_SLOT, + uint64_t lpid, /* LPAR ID of the SVM */ + uint64_t start_gpa, /* start guest physical address */ + uint64_t size, /* size of address range in bytes */ + uint64_t flags /* reserved for future expansion */ + uint16_t slotid) /* slot identifier */ + +Return values +~~~~~~~~~~~~~ + + One of the following values: + + * U_SUCCESS on success. + * U_PARAMETER if ``lpid`` is invalid. + * U_P2 if ``start_gpa`` is invalid. + * U_P3 if ``size`` is invalid. + * U_P4 if any bit in the ``flags`` is unrecognized. + * U_P5 if the ``slotid`` parameter is unsupported. + * U_PERMISSION if called from context other than Hypervisor. + * U_FUNCTION if functionality is not supported. + + +Description +~~~~~~~~~~~ + + Register a memory range for an SVM. The memory range starts at the + guest physical address ``start_gpa`` and is ``size`` bytes long. + +Use cases +~~~~~~~~~ + + + #. When a virtual machine goes secure, all the memory slots managed by + the Hypervisor move into secure memory. The Hypervisor iterates + through each of memory slots, and registers the slot with + Ultravisor. Hypervisor may discard some slots such as those used + for firmware (SLOF). + + #. When new memory is hot-plugged, a new memory slot gets registered. + + +UV_UNREGISTER_MEM_SLOT +---------------------- + + Unregister an SVM address-range that was previously registered using + UV_REGISTER_MEM_SLOT. + +Syntax +~~~~~~ + +.. code-block:: c + + uint64_t ultracall(const uint64_t UV_UNREGISTER_MEM_SLOT, + uint64_t lpid, /* LPAR ID of the SVM */ + uint64_t slotid) /* reservation slotid */ + +Return values +~~~~~~~~~~~~~ + + One of the following values: + + * U_SUCCESS on success. + * U_FUNCTION if functionality is not supported. + * U_PARAMETER if ``lpid`` is invalid. + * U_P2 if ``slotid`` is invalid. + * U_PERMISSION if called from context other than Hypervisor. + +Description +~~~~~~~~~~~ + + Release the memory slot identified by ``slotid`` and free any + resources allocated towards the reservation. + +Use cases +~~~~~~~~~ + + #. Memory hot-remove. + + +UV_SVM_TERMINATE +---------------- + + Terminate an SVM and release its resources. + +Syntax +~~~~~~ + +.. code-block:: c + + uint64_t ultracall(const uint64_t UV_SVM_TERMINATE, + uint64_t lpid, /* LPAR ID of the SVM */) + +Return values +~~~~~~~~~~~~~ + + One of the following values: + + * U_SUCCESS on success. + * U_FUNCTION if functionality is not supported. + * U_PARAMETER if ``lpid`` is invalid. + * U_INVALID if VM is not secure. + * U_PERMISSION if not called from a Hypervisor context. + +Description +~~~~~~~~~~~ + + Terminate an SVM and release all its resources. + +Use cases +~~~~~~~~~ + + #. Called by Hypervisor when terminating an SVM. + + +Ultracalls used by SVM +====================== + +UV_SHARE_PAGE +------------- + + Share a set of guest physical pages with the Hypervisor. + +Syntax +~~~~~~ + +.. code-block:: c + + uint64_t ultracall(const uint64_t UV_SHARE_PAGE, + uint64_t gfn, /* guest page frame number */ + uint64_t num) /* number of pages of size PAGE_SIZE */ + +Return values +~~~~~~~~~~~~~ + + One of the following values: + + * U_SUCCESS on success. + * U_FUNCTION if functionality is not supported. + * U_INVALID if the VM is not secure. + * U_PARAMETER if ``gfn`` is invalid. + * U_P2 if ``num`` is invalid. + +Description +~~~~~~~~~~~ + + Share the ``num`` pages starting at guest physical frame number ``gfn`` + with the Hypervisor. Assume page size is PAGE_SIZE bytes. Zero the + pages before returning. + + If the address is already backed by a secure page, unmap the page and + back it with an insecure page, with the help of the Hypervisor. If it + is not backed by any page yet, mark the PTE as insecure and back it + with an insecure page when the address is accessed. If it is already + backed by an insecure page, zero the page and return. + +Use cases +~~~~~~~~~ + + #. The Hypervisor cannot access the SVM pages since they are backed by + secure pages. Hence an SVM must explicitly request Ultravisor for + pages it can share with Hypervisor. + + #. Shared pages are needed to support virtio and Virtual Processor Area + (VPA) in SVMs. + + +UV_UNSHARE_PAGE +--------------- + + Restore a shared SVM page to its initial state. + +Syntax +~~~~~~ + +.. code-block:: c + + uint64_t ultracall(const uint64_t UV_UNSHARE_PAGE, + uint64_t gfn, /* guest page frame number */ + uint73 num) /* number of pages of size PAGE_SIZE*/ + +Return values +~~~~~~~~~~~~~ + + One of the following values: + + * U_SUCCESS on success. + * U_FUNCTION if functionality is not supported. + * U_INVALID if VM is not secure. + * U_PARAMETER if ``gfn`` is invalid. + * U_P2 if ``num`` is invalid. + +Description +~~~~~~~~~~~ + + Stop sharing ``num`` pages starting at ``gfn`` with the Hypervisor. + Assume that the page size is PAGE_SIZE. Zero the pages before + returning. + + If the address is already backed by an insecure page, unmap the page + and back it with a secure page. Inform the Hypervisor to release + reference to its shared page. If the address is not backed by a page + yet, mark the PTE as secure and back it with a secure page when that + address is accessed. If it is already backed by an secure page zero + the page and return. + +Use cases +~~~~~~~~~ + + #. The SVM may decide to unshare a page from the Hypervisor. + + +UV_UNSHARE_ALL_PAGES +-------------------- + + Unshare all pages the SVM has shared with Hypervisor. + +Syntax +~~~~~~ + +.. code-block:: c + + uint64_t ultracall(const uint64_t UV_UNSHARE_ALL_PAGES) + +Return values +~~~~~~~~~~~~~ + + One of the following values: + + * U_SUCCESS on success. + * U_FUNCTION if functionality is not supported. + * U_INVAL if VM is not secure. + +Description +~~~~~~~~~~~ + + Unshare all shared pages from the Hypervisor. All unshared pages are + zeroed on return. Only pages explicitly shared by the SVM with the + Hypervisor (using UV_SHARE_PAGE ultracall) are unshared. Ultravisor + may internally share some pages with the Hypervisor without explicit + request from the SVM. These pages will not be unshared by this + ultracall. + +Use cases +~~~~~~~~~ + + #. This call is needed when ``kexec`` is used to boot a different + kernel. It may also be needed during SVM reset. + +UV_ESM +------ + + Secure the virtual machine (*enter secure mode*). + +Syntax +~~~~~~ + +.. code-block:: c + + uint64_t ultracall(const uint64_t UV_ESM, + uint64_t esm_blob_addr, /* location of the ESM blob */ + unint64_t fdt) /* Flattened device tree */ + +Return values +~~~~~~~~~~~~~ + + One of the following values: + + * U_SUCCESS on success (including if VM is already secure). + * U_FUNCTION if functionality is not supported. + * U_INVALID if VM is not secure. + * U_PARAMETER if ``esm_blob_addr`` is invalid. + * U_P2 if ``fdt`` is invalid. + * U_PERMISSION if any integrity checks fail. + * U_RETRY insufficient memory to create SVM. + * U_NO_KEY symmetric key unavailable. + +Description +~~~~~~~~~~~ + + Secure the virtual machine. On successful completion, return + control to the virtual machine at the address specified in the + ESM blob. + +Use cases +~~~~~~~~~ + + #. A normal virtual machine can choose to switch to a secure mode. + +Hypervisor Calls API +#################### + + This document describes the Hypervisor calls (hypercalls) that are + needed to support the Ultravisor. Hypercalls are services provided by + the Hypervisor to virtual machines and Ultravisor. + + Register usage for these hypercalls is identical to that of the other + hypercalls defined in the Power Architecture Platform Reference (PAPR) + document. i.e on input, register R3 identifies the specific service + that is being requested and registers R4 through R11 contain + additional parameters to the hypercall, if any. On output, register + R3 contains the return value and registers R4 through R9 contain any + other output values from the hypercall. + + This document only covers hypercalls currently implemented/planned + for Ultravisor usage but others can be added here when it makes sense. + + The full specification for all hypercalls/ultracalls will eventually + be made available in the public/OpenPower version of the PAPR + specification. + +Hypervisor calls to support Ultravisor +====================================== + + Following are the set of hypercalls needed to support Ultravisor. + +H_SVM_INIT_START +---------------- + + Begin the process of converting a normal virtual machine into an SVM. + +Syntax +~~~~~~ + +.. code-block:: c + + uint64_t hypercall(const uint64_t H_SVM_INIT_START) + +Return values +~~~~~~~~~~~~~ + + One of the following values: + + * H_SUCCESS on success. + +Description +~~~~~~~~~~~ + + Initiate the process of securing a virtual machine. This involves + coordinating with the Ultravisor, using ultracalls, to allocate + resources in the Ultravisor for the new SVM, transferring the VM's + pages from normal to secure memory etc. When the process is + completed, Ultravisor issues the H_SVM_INIT_DONE hypercall. + +Use cases +~~~~~~~~~ + + #. Ultravisor uses this hypercall to inform Hypervisor that a VM + has initiated the process of switching to secure mode. + + +H_SVM_INIT_DONE +--------------- + + Complete the process of securing an SVM. + +Syntax +~~~~~~ + +.. code-block:: c + + uint64_t hypercall(const uint64_t H_SVM_INIT_DONE) + +Return values +~~~~~~~~~~~~~ + + One of the following values: + + * H_SUCCESS on success. + * H_UNSUPPORTED if called from the wrong context (e.g. + from an SVM or before an H_SVM_INIT_START + hypercall). + +Description +~~~~~~~~~~~ + + Complete the process of securing a virtual machine. This call must + be made after a prior call to ``H_SVM_INIT_START`` hypercall. + +Use cases +~~~~~~~~~ + + On successfully securing a virtual machine, the Ultravisor informs + Hypervisor about it. Hypervisor can use this call to finish setting + up its internal state for this virtual machine. + + +H_SVM_PAGE_IN +------------- + + Move the contents of a page from normal memory to secure memory. + +Syntax +~~~~~~ + +.. code-block:: c + + uint64_t hypercall(const uint64_t H_SVM_PAGE_IN, + uint64_t guest_pa, /* guest-physical-address */ + uint64_t flags, /* flags */ + uint64_t order) /* page size order */ + +Return values +~~~~~~~~~~~~~ + + One of the following values: + + * H_SUCCESS on success. + * H_PARAMETER if ``guest_pa`` is invalid. + * H_P2 if ``flags`` is invalid. + * H_P3 if ``order`` of page is invalid. + +Description +~~~~~~~~~~~ + + Retrieve the content of the page, belonging to the VM at the specified + guest physical address. + + Only valid value(s) in ``flags`` are: + + * H_PAGE_IN_SHARED which indicates that the page is to be shared + with the Ultravisor. + + * H_PAGE_IN_NONSHARED indicates that the UV is not anymore + interested in the page. Applicable if the page is a shared page. + + The ``order`` parameter must correspond to the configured page size. + +Use cases +~~~~~~~~~ + + #. When a normal VM becomes a secure VM (using the UV_ESM ultracall), + the Ultravisor uses this hypercall to move contents of each page of + the VM from normal memory to secure memory. + + #. Ultravisor uses this hypercall to ask Hypervisor to provide a page + in normal memory that can be shared between the SVM and Hypervisor. + + #. Ultravisor uses this hypercall to page-in a paged-out page. This + can happen when the SVM touches a paged-out page. + + #. If SVM wants to disable sharing of pages with Hypervisor, it can + inform Ultravisor to do so. Ultravisor will then use this hypercall + and inform Hypervisor that it has released access to the normal + page. + +H_SVM_PAGE_OUT +--------------- + + Move the contents of the page to normal memory. + +Syntax +~~~~~~ + +.. code-block:: c + + uint64_t hypercall(const uint64_t H_SVM_PAGE_OUT, + uint64_t guest_pa, /* guest-physical-address */ + uint64_t flags, /* flags (currently none) */ + uint64_t order) /* page size order */ + +Return values +~~~~~~~~~~~~~ + + One of the following values: + + * H_SUCCESS on success. + * H_PARAMETER if ``guest_pa`` is invalid. + * H_P2 if ``flags`` is invalid. + * H_P3 if ``order`` is invalid. + +Description +~~~~~~~~~~~ + + Move the contents of the page identified by ``guest_pa`` to normal + memory. + + Currently ``flags`` is unused and must be set to 0. The ``order`` + parameter must correspond to the configured page size. + +Use cases +~~~~~~~~~ + + #. If Ultravisor is running low on secure pages, it can move the + contents of some secure pages, into normal pages using this + hypercall. The content will be encrypted. + +References +########## + +- `Supporting Protected Computing on IBM Power Architecture <https://developer.ibm.com/articles/l-support-protected-computing/>`_ 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: [<hash algo>:]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/trace/kprobetrace.rst b/Documentation/trace/kprobetrace.rst index fbb314bfa112..55993055902c 100644 --- a/Documentation/trace/kprobetrace.rst +++ b/Documentation/trace/kprobetrace.rst @@ -52,6 +52,7 @@ Synopsis of kprobe_events $retval : Fetch return value.(\*2) $comm : Fetch current task comm. +|-[u]OFFS(FETCHARG) : Fetch memory at FETCHARG +|- OFFS address.(\*3)(\*4) + \IMM : Store an immediate value to the argument. NAME=FETCHARG : Set NAME as the argument name of FETCHARG. FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types (u8/u16/u32/u64/s8/s16/s32/s64), hexadecimal types diff --git a/Documentation/trace/uprobetracer.rst b/Documentation/trace/uprobetracer.rst index 6e75a6c5a2c8..98cde99939d7 100644 --- a/Documentation/trace/uprobetracer.rst +++ b/Documentation/trace/uprobetracer.rst @@ -45,6 +45,7 @@ Synopsis of uprobe_tracer $retval : Fetch return value.(\*1) $comm : Fetch current task comm. +|-[u]OFFS(FETCHARG) : Fetch memory at FETCHARG +|- OFFS address.(\*2)(\*3) + \IMM : Store an immediate value to the argument. NAME=FETCHARG : Set NAME as the argument name of FETCHARG. FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types (u8/u16/u32/u64/s8/s16/s32/s64), hexadecimal types diff --git a/Documentation/virt/kvm/api.txt b/Documentation/virt/kvm/api.txt index 136f1eef3712..4833904d32a5 100644 --- a/Documentation/virt/kvm/api.txt +++ b/Documentation/virt/kvm/api.txt @@ -5309,3 +5309,16 @@ Architectures: x86 This capability indicates that KVM supports paravirtualized Hyper-V IPI send hypercalls: HvCallSendSyntheticClusterIpi, HvCallSendSyntheticClusterIpiEx. +8.21 KVM_CAP_HYPERV_DIRECT_TLBFLUSH + +Architecture: x86 + +This capability indicates that KVM running on top of Hyper-V hypervisor +enables Direct TLB flush for its guests meaning that TLB flush +hypercalls are handled by Level 0 hypervisor (Hyper-V) bypassing KVM. +Due to the different ABI for hypercall parameters between Hyper-V and +KVM, enabling this capability effectively disables all hypercall +handling by KVM (as some KVM hypercall may be mistakenly treated as TLB +flush hypercalls by Hyper-V) so userspace should disable KVM identification +in CPUID and only exposes Hyper-V identification. In this case, guest +thinks it's running on Hyper-V and only use Hyper-V hypercalls. diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst index 710ce1c701bf..0a5960beccf7 100644 --- a/Documentation/vm/hmm.rst +++ b/Documentation/vm/hmm.rst @@ -192,15 +192,14 @@ read only, or fully unmap, etc.). The device must complete the update before the driver callback returns. When the device driver wants to populate a range of virtual addresses, it can -use either:: +use:: - long hmm_range_snapshot(struct hmm_range *range); - long hmm_range_fault(struct hmm_range *range, bool block); + long hmm_range_fault(struct hmm_range *range, unsigned int flags); -The first one (hmm_range_snapshot()) will only fetch present CPU page table +With the HMM_RANGE_SNAPSHOT flag, it will only fetch present CPU page table entries and will not trigger a page fault on missing or non-present entries. -The second one does trigger a page fault on missing or read-only entries if -write access is requested (see below). Page faults use the generic mm page +Without that flag, it does trigger a page fault on missing or read-only entries +if write access is requested (see below). Page faults use the generic mm page fault code path just like a CPU page fault. Both functions copy CPU page table entries into their pfns array argument. Each @@ -223,24 +222,24 @@ The usage pattern is:: range.flags = ...; range.values = ...; range.pfn_shift = ...; - hmm_range_register(&range); + hmm_range_register(&range, mirror); /* * Just wait for range to be valid, safe to ignore return value as we - * will use the return value of hmm_range_snapshot() below under the + * will use the return value of hmm_range_fault() below under the * mmap_sem to ascertain the validity of the range. */ hmm_range_wait_until_valid(&range, TIMEOUT_IN_MSEC); again: down_read(&mm->mmap_sem); - ret = hmm_range_snapshot(&range); + ret = hmm_range_fault(&range, HMM_RANGE_SNAPSHOT); if (ret) { up_read(&mm->mmap_sem); if (ret == -EBUSY) { /* * No need to check hmm_range_wait_until_valid() return value - * on retry we will get proper error with hmm_range_snapshot() + * on retry we will get proper error with hmm_range_fault() */ hmm_range_wait_until_valid(&range, TIMEOUT_IN_MSEC); goto again; @@ -340,58 +339,8 @@ Migration to and from device memory =================================== Because the CPU cannot access device memory, migration must use the device DMA -engine to perform copy from and to device memory. For this we need a new -migration helper:: - - int migrate_vma(const struct migrate_vma_ops *ops, - struct vm_area_struct *vma, - unsigned long mentries, - unsigned long start, - unsigned long end, - unsigned long *src, - unsigned long *dst, - void *private); - -Unlike other migration functions it works on a range of virtual address, there -are two reasons for that. First, device DMA copy has a high setup overhead cost -and thus batching multiple pages is needed as otherwise the migration overhead -makes the whole exercise pointless. The second reason is because the -migration might be for a range of addresses the device is actively accessing. - -The migrate_vma_ops struct defines two callbacks. First one (alloc_and_copy()) -controls destination memory allocation and copy operation. Second one is there -to allow the device driver to perform cleanup operations after migration:: - - struct migrate_vma_ops { - void (*alloc_and_copy)(struct vm_area_struct *vma, - const unsigned long *src, - unsigned long *dst, - unsigned long start, - unsigned long end, - void *private); - void (*finalize_and_map)(struct vm_area_struct *vma, - const unsigned long *src, - const unsigned long *dst, - unsigned long start, - unsigned long end, - void *private); - }; - -It is important to stress that these migration helpers allow for holes in the -virtual address range. Some pages in the range might not be migrated for all -the usual reasons (page is pinned, page is locked, ...). This helper does not -fail but just skips over those pages. - -The alloc_and_copy() might decide to not migrate all pages in the -range (for reasons under the callback control). For those, the callback just -has to leave the corresponding dst entry empty. - -Finally, the migration of the struct page might fail (for file backed page) for -various reasons (failure to freeze reference, or update page cache, ...). If -that happens, then the finalize_and_map() can catch any pages that were not -migrated. Note those pages were still copied to a new page and thus we wasted -bandwidth but this is considered as a rare event and a price that we are -willing to pay to keep all the code simpler. +engine to perform copy from and to device memory. For this we need to use +migrate_vma_setup(), migrate_vma_pages(), and migrate_vma_finalize() helpers. Memory cgroup (memcg) and rss accounting diff --git a/Documentation/vm/split_page_table_lock.rst b/Documentation/vm/split_page_table_lock.rst index 889b00be469f..ff51f4a5494d 100644 --- a/Documentation/vm/split_page_table_lock.rst +++ b/Documentation/vm/split_page_table_lock.rst @@ -54,9 +54,9 @@ Hugetlb-specific helpers: Support of split page table lock by an architecture =================================================== -There's no need in special enabling of PTE split page table lock: -everything required is done by pgtable_page_ctor() and pgtable_page_dtor(), -which must be called on PTE table allocation / freeing. +There's no need in special enabling of PTE split page table lock: everything +required is done by pgtable_pte_page_ctor() and pgtable_pte_page_dtor(), which +must be called on PTE table allocation / freeing. Make sure the architecture doesn't use slab allocator for page table allocation: slab uses page->slab_cache for its pages. @@ -74,7 +74,7 @@ paths: i.e X86_PAE preallocate few PMDs on pgd_alloc(). With everything in place you can set CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK. -NOTE: pgtable_page_ctor() and pgtable_pmd_page_ctor() can fail -- it must +NOTE: pgtable_pte_page_ctor() and pgtable_pmd_page_ctor() can fail -- it must be handled properly. page->ptl @@ -94,7 +94,7 @@ trick: split lock with enabled DEBUG_SPINLOCK or DEBUG_LOCK_ALLOC, but costs one more cache line for indirect access; -The spinlock_t allocated in pgtable_page_ctor() for PTE table and in +The spinlock_t allocated in pgtable_pte_page_ctor() for PTE table and in pgtable_pmd_page_ctor() for PMD table. Please, never access page->ptl directly -- use appropriate helper. diff --git a/Documentation/watchdog/watchdog-parameters.rst b/Documentation/watchdog/watchdog-parameters.rst index a3985cc5aeda..223c99361a30 100644 --- a/Documentation/watchdog/watchdog-parameters.rst +++ b/Documentation/watchdog/watchdog-parameters.rst @@ -301,15 +301,6 @@ ixp4xx_wdt: ------------------------------------------------- -ks8695_wdt: - wdt_time: - Watchdog time in seconds. (default=5) - nowayout: - Watchdog cannot be stopped once started - (default=kernel config parameter) - -------------------------------------------------- - machzwd: nowayout: Watchdog cannot be stopped once started @@ -375,16 +366,6 @@ nic7018_wdt: ------------------------------------------------- -nuc900_wdt: - heartbeat: - Watchdog heartbeats in seconds. - (default = 15) - nowayout: - Watchdog cannot be stopped once started - (default=kernel config parameter) - -------------------------------------------------- - omap_wdt: timer_margin: initial watchdog timeout (in seconds) diff --git a/Documentation/x86/x86_64/boot-options.rst b/Documentation/x86/x86_64/boot-options.rst index 6a4285a3c7a4..2b98efb5ba7f 100644 --- a/Documentation/x86/x86_64/boot-options.rst +++ b/Documentation/x86/x86_64/boot-options.rst @@ -230,7 +230,7 @@ IOMMU (input/output memory management unit) =========================================== Multiple x86-64 PCI-DMA mapping implementations exist, for example: - 1. <lib/dma-direct.c>: use no hardware/software IOMMU at all + 1. <kernel/dma/direct.c>: use no hardware/software IOMMU at all (e.g. because you have < 3 GB memory). Kernel boot message: "PCI-DMA: Disabling IOMMU" |