diff options
Diffstat (limited to 'Documentation')
159 files changed, 4954 insertions, 1949 deletions
diff --git a/Documentation/ABI/testing/debugfs-dell-wmi-ddv b/Documentation/ABI/testing/debugfs-dell-wmi-ddv new file mode 100644 index 000000000000..fbcc5d6f7388 --- /dev/null +++ b/Documentation/ABI/testing/debugfs-dell-wmi-ddv @@ -0,0 +1,21 @@ +What: /sys/kernel/debug/dell-wmi-ddv-<wmi_device_name>/fan_sensor_information +Date: September 2022 +KernelVersion: 6.1 +Contact: Armin Wolf <W_Armin@gmx.de> +Description: + This file contains the contents of the fan sensor information buffer, + which contains fan sensor entries and a terminating character (0xFF). + + Each fan sensor entry consists of three bytes with an unknown meaning, + interested people may use this file for reverse-engineering. + +What: /sys/kernel/debug/dell-wmi-ddv-<wmi_device_name>/thermal_sensor_information +Date: September 2022 +KernelVersion: 6.1 +Contact: Armin Wolf <W_Armin@gmx.de> +Description: + This file contains the contents of the thermal sensor information buffer, + which contains thermal sensor entries and a terminating character (0xFF). + + Each thermal sensor entry consists of five bytes with an unknown meaning, + interested people may use this file for reverse-engineering. diff --git a/Documentation/ABI/testing/sysfs-driver-intel_sdsi b/Documentation/ABI/testing/sysfs-driver-intel_sdsi index 96b92c105ec4..f8afed127107 100644 --- a/Documentation/ABI/testing/sysfs-driver-intel_sdsi +++ b/Documentation/ABI/testing/sysfs-driver-intel_sdsi @@ -4,21 +4,21 @@ KernelVersion: 5.18 Contact: "David E. Box" <david.e.box@linux.intel.com> Description: This directory contains interface files for accessing Intel - Software Defined Silicon (SDSi) features on a CPU. X - represents the socket instance (though not the socket ID). - The socket ID is determined by reading the registers file - and decoding it per the specification. + On Demand (formerly Software Defined Silicon or SDSi) features + on a CPU. X represents the socket instance (though not the + socket ID). The socket ID is determined by reading the + registers file and decoding it per the specification. - Some files communicate with SDSi hardware through a mailbox. - Should the operation fail, one of the following error codes - may be returned: + Some files communicate with On Demand hardware through a + mailbox. Should the operation fail, one of the following error + codes may be returned: ========== ===== Error Code Cause ========== ===== EIO General mailbox failure. Log may indicate cause. EBUSY Mailbox is owned by another agent. - EPERM SDSI capability is not enabled in hardware. + EPERM On Demand capability is not enabled in hardware. EPROTO Failure in mailbox protocol detected by driver. See log for details. EOVERFLOW For provision commands, the size of the data @@ -54,8 +54,8 @@ KernelVersion: 5.18 Contact: "David E. Box" <david.e.box@linux.intel.com> Description: (WO) Used to write an Authentication Key Certificate (AKC) to - the SDSi NVRAM for the CPU. The AKC is used to authenticate a - Capability Activation Payload. Mailbox command. + the On Demand NVRAM for the CPU. The AKC is used to authenticate + a Capability Activation Payload. Mailbox command. What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X/provision_cap Date: Feb 2022 @@ -63,17 +63,28 @@ KernelVersion: 5.18 Contact: "David E. Box" <david.e.box@linux.intel.com> Description: (WO) Used to write a Capability Activation Payload (CAP) to the - SDSi NVRAM for the CPU. CAPs are used to activate a given CPU - feature. A CAP is validated by SDSi hardware using a previously - provisioned AKC file. Upon successful authentication, the CPU - configuration is updated. A cold reboot is required to fully - activate the feature. Mailbox command. + On Demand NVRAM for the CPU. CAPs are used to activate a given + CPU feature. A CAP is validated by On Demand hardware using a + previously provisioned AKC file. Upon successful authentication, + the CPU configuration is updated. A cold reboot is required to + fully activate the feature. Mailbox command. + +What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X/meter_certificate +Date: Nov 2022 +KernelVersion: 6.2 +Contact: "David E. Box" <david.e.box@linux.intel.com> +Description: + (RO) Used to read back the current meter certificate for the CPU + from Intel On Demand hardware. The meter certificate contains + utilization metrics of On Demand enabled features. Mailbox + command. What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X/state_certificate Date: Feb 2022 KernelVersion: 5.18 Contact: "David E. Box" <david.e.box@linux.intel.com> Description: - (RO) Used to read back the current State Certificate for the CPU - from SDSi hardware. The State Certificate contains information - about the current licenses on the CPU. Mailbox command. + (RO) Used to read back the current state certificate for the CPU + from On Demand hardware. The state certificate contains + information about the current licenses on the CPU. Mailbox + command. diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-memory-tiers b/Documentation/ABI/testing/sysfs-kernel-mm-memory-tiers index 45985e411f13..721a05b90109 100644 --- a/Documentation/ABI/testing/sysfs-kernel-mm-memory-tiers +++ b/Documentation/ABI/testing/sysfs-kernel-mm-memory-tiers @@ -10,7 +10,7 @@ Description: A collection of all the memory tiers allocated. What: /sys/devices/virtual/memory_tiering/memory_tierN/ - /sys/devices/virtual/memory_tiering/memory_tierN/nodes + /sys/devices/virtual/memory_tiering/memory_tierN/nodelist Date: August 2022 Contact: Linux memory management mailing list <linux-mm@kvack.org> Description: Directory with details of a specific memory tier @@ -21,5 +21,5 @@ Description: Directory with details of a specific memory tier A smaller value of N implies a higher (faster) memory tier in the hierarchy. - nodes: NUMA nodes that are part of this memory tier. + nodelist: NUMA nodes that are part of this memory tier. diff --git a/Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv b/Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv new file mode 100644 index 000000000000..1d97ad615c66 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv @@ -0,0 +1,7 @@ +What: /sys/class/power_supply/<battery_name>/eppid +Date: September 2022 +KernelVersion: 6.1 +Contact: Armin Wolf <W_Armin@gmx.de> +Description: + Reports the Dell ePPID (electronic Dell Piece Part Identification) + of the ACPI battery. diff --git a/Documentation/RCU/arrayRCU.rst b/Documentation/RCU/arrayRCU.rst deleted file mode 100644 index a5f2ff8fc54c..000000000000 --- a/Documentation/RCU/arrayRCU.rst +++ /dev/null @@ -1,165 +0,0 @@ -.. _array_rcu_doc: - -Using RCU to Protect Read-Mostly Arrays -======================================= - -Although RCU is more commonly used to protect linked lists, it can -also be used to protect arrays. Three situations are as follows: - -1. :ref:`Hash Tables <hash_tables>` - -2. :ref:`Static Arrays <static_arrays>` - -3. :ref:`Resizable Arrays <resizable_arrays>` - -Each of these three situations involves an RCU-protected pointer to an -array that is separately indexed. It might be tempting to consider use -of RCU to instead protect the index into an array, however, this use -case is **not** supported. The problem with RCU-protected indexes into -arrays is that compilers can play way too many optimization games with -integers, which means that the rules governing handling of these indexes -are far more trouble than they are worth. If RCU-protected indexes into -arrays prove to be particularly valuable (which they have not thus far), -explicit cooperation from the compiler will be required to permit them -to be safely used. - -That aside, each of the three RCU-protected pointer situations are -described in the following sections. - -.. _hash_tables: - -Situation 1: Hash Tables ------------------------- - -Hash tables are often implemented as an array, where each array entry -has a linked-list hash chain. Each hash chain can be protected by RCU -as described in listRCU.rst. This approach also applies to other -array-of-list situations, such as radix trees. - -.. _static_arrays: - -Situation 2: Static Arrays --------------------------- - -Static arrays, where the data (rather than a pointer to the data) is -located in each array element, and where the array is never resized, -have not been used with RCU. Rik van Riel recommends using seqlock in -this situation, which would also have minimal read-side overhead as long -as updates are rare. - -Quick Quiz: - Why is it so important that updates be rare when using seqlock? - -:ref:`Answer to Quick Quiz <answer_quick_quiz_seqlock>` - -.. _resizable_arrays: - -Situation 3: Resizable Arrays ------------------------------- - -Use of RCU for resizable arrays is demonstrated by the grow_ary() -function formerly used by the System V IPC code. The array is used -to map from semaphore, message-queue, and shared-memory IDs to the data -structure that represents the corresponding IPC construct. The grow_ary() -function does not acquire any locks; instead its caller must hold the -ids->sem semaphore. - -The grow_ary() function, shown below, does some limit checks, allocates a -new ipc_id_ary, copies the old to the new portion of the new, initializes -the remainder of the new, updates the ids->entries pointer to point to -the new array, and invokes ipc_rcu_putref() to free up the old array. -Note that rcu_assign_pointer() is used to update the ids->entries pointer, -which includes any memory barriers required on whatever architecture -you are running on:: - - static int grow_ary(struct ipc_ids* ids, int newsize) - { - struct ipc_id_ary* new; - struct ipc_id_ary* old; - int i; - int size = ids->entries->size; - - if(newsize > IPCMNI) - newsize = IPCMNI; - if(newsize <= size) - return newsize; - - new = ipc_rcu_alloc(sizeof(struct kern_ipc_perm *)*newsize + - sizeof(struct ipc_id_ary)); - if(new == NULL) - return size; - new->size = newsize; - memcpy(new->p, ids->entries->p, - sizeof(struct kern_ipc_perm *)*size + - sizeof(struct ipc_id_ary)); - for(i=size;i<newsize;i++) { - new->p[i] = NULL; - } - old = ids->entries; - - /* - * Use rcu_assign_pointer() to make sure the memcpyed - * contents of the new array are visible before the new - * array becomes visible. - */ - rcu_assign_pointer(ids->entries, new); - - ipc_rcu_putref(old); - return newsize; - } - -The ipc_rcu_putref() function decrements the array's reference count -and then, if the reference count has dropped to zero, uses call_rcu() -to free the array after a grace period has elapsed. - -The array is traversed by the ipc_lock() function. This function -indexes into the array under the protection of rcu_read_lock(), -using rcu_dereference() to pick up the pointer to the array so -that it may later safely be dereferenced -- memory barriers are -required on the Alpha CPU. Since the size of the array is stored -with the array itself, there can be no array-size mismatches, so -a simple check suffices. The pointer to the structure corresponding -to the desired IPC object is placed in "out", with NULL indicating -a non-existent entry. After acquiring "out->lock", the "out->deleted" -flag indicates whether the IPC object is in the process of being -deleted, and, if not, the pointer is returned:: - - struct kern_ipc_perm* ipc_lock(struct ipc_ids* ids, int id) - { - struct kern_ipc_perm* out; - int lid = id % SEQ_MULTIPLIER; - struct ipc_id_ary* entries; - - rcu_read_lock(); - entries = rcu_dereference(ids->entries); - if(lid >= entries->size) { - rcu_read_unlock(); - return NULL; - } - out = entries->p[lid]; - if(out == NULL) { - rcu_read_unlock(); - return NULL; - } - spin_lock(&out->lock); - - /* ipc_rmid() may have already freed the ID while ipc_lock - * was spinning: here verify that the structure is still valid - */ - if (out->deleted) { - spin_unlock(&out->lock); - rcu_read_unlock(); - return NULL; - } - return out; - } - -.. _answer_quick_quiz_seqlock: - -Answer to Quick Quiz: - Why is it so important that updates be rare when using seqlock? - - The reason that it is important that updates be rare when - using seqlock is that frequent updates can livelock readers. - One way to avoid this problem is to assign a seqlock for - each array entry rather than to the entire array. diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index 048c5bc1f813..cc361fb01ed4 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -32,8 +32,8 @@ over a rather long period of time, but improvements are always welcome! for lockless updates. This does result in the mildly counter-intuitive situation where rcu_read_lock() and rcu_read_unlock() are used to protect updates, however, this - approach provides the same potential simplifications that garbage - collectors do. + approach can provide the same simplifications to certain types + of lockless algorithms that garbage collectors do. 1. Does the update code have proper mutual exclusion? @@ -49,12 +49,12 @@ over a rather long period of time, but improvements are always welcome! them -- even x86 allows later loads to be reordered to precede earlier stores), and be prepared to explain why this added complexity is worthwhile. If you choose #c, be prepared to - explain how this single task does not become a major bottleneck on - big multiprocessor machines (for example, if the task is updating - information relating to itself that other tasks can read, there - by definition can be no bottleneck). Note that the definition - of "large" has changed significantly: Eight CPUs was "large" - in the year 2000, but a hundred CPUs was unremarkable in 2017. + explain how this single task does not become a major bottleneck + on large systems (for example, if the task is updating information + relating to itself that other tasks can read, there by definition + can be no bottleneck). Note that the definition of "large" has + changed significantly: Eight CPUs was "large" in the year 2000, + but a hundred CPUs was unremarkable in 2017. 2. Do the RCU read-side critical sections make proper use of rcu_read_lock() and friends? These primitives are needed @@ -97,33 +97,38 @@ over a rather long period of time, but improvements are always welcome! b. Proceed as in (a) above, but also maintain per-element locks (that are acquired by both readers and writers) - that guard per-element state. Of course, fields that - the readers refrain from accessing can be guarded by - some other lock acquired only by updaters, if desired. + that guard per-element state. Fields that the readers + refrain from accessing can be guarded by some other lock + acquired only by updaters, if desired. - This works quite well, also. + This also works quite well. c. Make updates appear atomic to readers. For example, pointer updates to properly aligned fields will appear atomic, as will individual atomic primitives. Sequences of operations performed under a lock will *not* appear to be atomic to RCU readers, nor will sequences - of multiple atomic primitives. + of multiple atomic primitives. One alternative is to + move multiple individual fields to a separate structure, + thus solving the multiple-field problem by imposing an + additional level of indirection. This can work, but is starting to get a bit tricky. - d. Carefully order the updates and the reads so that - readers see valid data at all phases of the update. - This is often more difficult than it sounds, especially - given modern CPUs' tendency to reorder memory references. - One must usually liberally sprinkle memory barriers - (smp_wmb(), smp_rmb(), smp_mb()) through the code, - making it difficult to understand and to test. - - It is usually better to group the changing data into - a separate structure, so that the change may be made - to appear atomic by updating a pointer to reference - a new structure containing updated values. + d. Carefully order the updates and the reads so that readers + see valid data at all phases of the update. This is often + more difficult than it sounds, especially given modern + CPUs' tendency to reorder memory references. One must + usually liberally sprinkle memory-ordering operations + through the code, making it difficult to understand and + to test. Where it works, it is better to use things + like smp_store_release() and smp_load_acquire(), but in + some cases the smp_mb() full memory barrier is required. + + As noted earlier, it is usually better to group the + changing data into a separate structure, so that the + change may be made to appear atomic by updating a pointer + to reference a new structure containing updated values. 4. Weakly ordered CPUs pose special challenges. Almost all CPUs are weakly ordered -- even x86 CPUs allow later loads to be @@ -188,26 +193,29 @@ over a rather long period of time, but improvements are always welcome! when publicizing a pointer to a structure that can be traversed by an RCU read-side critical section. -5. If call_rcu() or call_srcu() is used, the callback function will - be called from softirq context. In particular, it cannot block. - If you need the callback to block, run that code in a workqueue - handler scheduled from the callback. The queue_rcu_work() - function does this for you in the case of call_rcu(). +5. If any of call_rcu(), call_srcu(), call_rcu_tasks(), + call_rcu_tasks_rude(), or call_rcu_tasks_trace() is used, + the callback function may be invoked from softirq context, + and in any case with bottom halves disabled. In particular, + this callback function cannot block. If you need the callback + to block, run that code in a workqueue handler scheduled from + the callback. The queue_rcu_work() function does this for you + in the case of call_rcu(). 6. Since synchronize_rcu() can block, it cannot be called from any sort of irq context. The same rule applies - for synchronize_srcu(), synchronize_rcu_expedited(), and - synchronize_srcu_expedited(). + for synchronize_srcu(), synchronize_rcu_expedited(), + synchronize_srcu_expedited(), synchronize_rcu_tasks(), + synchronize_rcu_tasks_rude(), and synchronize_rcu_tasks_trace(). The expedited forms of these primitives have the same semantics - as the non-expedited forms, but expediting is both expensive and - (with the exception of synchronize_srcu_expedited()) unfriendly - to real-time workloads. Use of the expedited primitives should - be restricted to rare configuration-change operations that would - not normally be undertaken while a real-time workload is running. - However, real-time workloads can use rcupdate.rcu_normal kernel - boot parameter to completely disable expedited grace periods, - though this might have performance implications. + as the non-expedited forms, but expediting is more CPU intensive. + Use of the expedited primitives should be restricted to rare + configuration-change operations that would not normally be + undertaken while a real-time workload is running. Note that + IPI-sensitive real-time workloads can use the rcupdate.rcu_normal + kernel boot parameter to completely disable expedited grace + periods, though this might have performance implications. In particular, if you find yourself invoking one of the expedited primitives repeatedly in a loop, please do everyone a favor: @@ -215,8 +223,9 @@ over a rather long period of time, but improvements are always welcome! a single non-expedited primitive to cover the entire batch. This will very likely be faster than the loop containing the expedited primitive, and will be much much easier on the rest - of the system, especially to real-time workloads running on - the rest of the system. + of the system, especially to real-time workloads running on the + rest of the system. Alternatively, instead use asynchronous + primitives such as call_rcu(). 7. As of v4.20, a given kernel implements only one RCU flavor, which is RCU-sched for PREEMPTION=n and RCU-preempt for PREEMPTION=y. @@ -239,7 +248,8 @@ over a rather long period of time, but improvements are always welcome! the corresponding readers must use rcu_read_lock_trace() and rcu_read_unlock_trace(). If an updater uses call_rcu_tasks_rude() or synchronize_rcu_tasks_rude(), then the corresponding readers - must use anything that disables interrupts. + must use anything that disables preemption, for example, + preempt_disable() and preempt_enable(). Mixing things up will result in confusion and broken kernels, and has even resulted in an exploitable security issue. Therefore, @@ -253,15 +263,16 @@ over a rather long period of time, but improvements are always welcome! that this usage is safe is that readers can use anything that disables BH when updaters use call_rcu() or synchronize_rcu(). -8. Although synchronize_rcu() is slower than is call_rcu(), it - usually results in simpler code. So, unless update performance is - critically important, the updaters cannot block, or the latency of - synchronize_rcu() is visible from userspace, synchronize_rcu() - should be used in preference to call_rcu(). Furthermore, - kfree_rcu() usually results in even simpler code than does - synchronize_rcu() without synchronize_rcu()'s multi-millisecond - latency. So please take advantage of kfree_rcu()'s "fire and - forget" memory-freeing capabilities where it applies. +8. Although synchronize_rcu() is slower than is call_rcu(), + it usually results in simpler code. So, unless update + performance is critically important, the updaters cannot block, + or the latency of synchronize_rcu() is visible from userspace, + synchronize_rcu() should be used in preference to call_rcu(). + Furthermore, kfree_rcu() and kvfree_rcu() usually result + in even simpler code than does synchronize_rcu() without + synchronize_rcu()'s multi-millisecond latency. So please take + advantage of kfree_rcu()'s and kvfree_rcu()'s "fire and forget" + memory-freeing capabilities where it applies. An especially important property of the synchronize_rcu() primitive is that it automatically self-limits: if grace periods @@ -271,8 +282,8 @@ over a rather long period of time, but improvements are always welcome! cases where grace periods are delayed, as failing to do so can result in excessive realtime latencies or even OOM conditions. - Ways of gaining this self-limiting property when using call_rcu() - include: + Ways of gaining this self-limiting property when using call_rcu(), + kfree_rcu(), or kvfree_rcu() include: a. Keeping a count of the number of data-structure elements used by the RCU-protected data structure, including @@ -304,18 +315,21 @@ over a rather long period of time, but improvements are always welcome! here is that superuser already has lots of ways to crash the machine. - d. Periodically invoke synchronize_rcu(), permitting a limited - number of updates per grace period. Better yet, periodically - invoke rcu_barrier() to wait for all outstanding callbacks. + d. Periodically invoke rcu_barrier(), permitting a limited + number of updates per grace period. - The same cautions apply to call_srcu() and kfree_rcu(). + The same cautions apply to call_srcu(), call_rcu_tasks(), + call_rcu_tasks_rude(), and call_rcu_tasks_trace(). This is + why there is an srcu_barrier(), rcu_barrier_tasks(), + rcu_barrier_tasks_rude(), and rcu_barrier_tasks_rude(), + respectively. - Note that although these primitives do take action to avoid memory - exhaustion when any given CPU has too many callbacks, a determined - user could still exhaust memory. This is especially the case - if a system with a large number of CPUs has been configured to - offload all of its RCU callbacks onto a single CPU, or if the - system has relatively little free memory. + Note that although these primitives do take action to avoid + memory exhaustion when any given CPU has too many callbacks, + a determined user or administrator can still exhaust memory. + This is especially the case if a system with a large number of + CPUs has been configured to offload all of its RCU callbacks onto + a single CPU, or if the system has relatively little free memory. 9. All RCU list-traversal primitives, which include rcu_dereference(), list_for_each_entry_rcu(), and @@ -344,14 +358,14 @@ over a rather long period of time, but improvements are always welcome! and you don't hold the appropriate update-side lock, you *must* use the "_rcu()" variants of the list macros. Failing to do so will break Alpha, cause aggressive compilers to generate bad code, - and confuse people trying to read your code. + and confuse people trying to understand your code. 11. Any lock acquired by an RCU callback must be acquired elsewhere - with softirq disabled, e.g., via spin_lock_irqsave(), - spin_lock_bh(), etc. Failing to disable softirq on a given - acquisition of that lock will result in deadlock as soon as - the RCU softirq handler happens to run your RCU callback while - interrupting that acquisition's critical section. + with softirq disabled, e.g., via spin_lock_bh(). Failing to + disable softirq on a given acquisition of that lock will result + in deadlock as soon as the RCU softirq handler happens to run + your RCU callback while interrupting that acquisition's critical + section. 12. RCU callbacks can be and are executed in parallel. In many cases, the callback code simply wrappers around kfree(), so that this @@ -372,7 +386,17 @@ over a rather long period of time, but improvements are always welcome! for some real-time workloads, this is the whole point of using the rcu_nocbs= kernel boot parameter. -13. Unlike other forms of RCU, it *is* permissible to block in an + In addition, do not assume that callbacks queued in a given order + will be invoked in that order, even if they all are queued on the + same CPU. Furthermore, do not assume that same-CPU callbacks will + be invoked serially. For example, in recent kernels, CPUs can be + switched between offloaded and de-offloaded callback invocation, + and while a given CPU is undergoing such a switch, its callbacks + might be concurrently invoked by that CPU's softirq handler and + that CPU's rcuo kthread. At such times, that CPU's callbacks + might be executed both concurrently and out of order. + +13. Unlike most flavors of RCU, it *is* permissible to block in an SRCU read-side critical section (demarked by srcu_read_lock() and srcu_read_unlock()), hence the "SRCU": "sleepable RCU". Please note that if you don't need to sleep in read-side critical @@ -412,6 +436,12 @@ over a rather long period of time, but improvements are always welcome! never sends IPIs to other CPUs, so it is easier on real-time workloads than is synchronize_rcu_expedited(). + It is also permissible to sleep in RCU Tasks Trace read-side + critical, which are delimited by rcu_read_lock_trace() and + rcu_read_unlock_trace(). However, this is a specialized flavor + of RCU, and you should not use it without first checking with + its current users. In most cases, you should instead use SRCU. + Note that rcu_assign_pointer() relates to SRCU just as it does to other forms of RCU, but instead of rcu_dereference() you should use srcu_dereference() in order to avoid lockdep splats. @@ -442,50 +472,62 @@ over a rather long period of time, but improvements are always welcome! find problems as follows: CONFIG_PROVE_LOCKING: - check that accesses to RCU-protected data - structures are carried out under the proper RCU - read-side critical section, while holding the right - combination of locks, or whatever other conditions - are appropriate. + check that accesses to RCU-protected data structures + are carried out under the proper RCU read-side critical + section, while holding the right combination of locks, + or whatever other conditions are appropriate. CONFIG_DEBUG_OBJECTS_RCU_HEAD: - check that you don't pass the - same object to call_rcu() (or friends) before an RCU - grace period has elapsed since the last time that you - passed that same object to call_rcu() (or friends). + check that you don't pass the same object to call_rcu() + (or friends) before an RCU grace period has elapsed + since the last time that you passed that same object to + call_rcu() (or friends). __rcu sparse checks: - tag the pointer to the RCU-protected data - structure with __rcu, and sparse will warn you if you - access that pointer without the services of one of the - variants of rcu_dereference(). + tag the pointer to the RCU-protected data structure + with __rcu, and sparse will warn you if you access that + pointer without the services of one of the variants + of rcu_dereference(). These debugging aids can help you find problems that are otherwise extremely difficult to spot. -17. If you register a callback using call_rcu() or call_srcu(), and - pass in a function defined within a loadable module, then it in - necessary to wait for all pending callbacks to be invoked after - the last invocation and before unloading that module. Note that - it is absolutely *not* sufficient to wait for a grace period! - The current (say) synchronize_rcu() implementation is *not* - guaranteed to wait for callbacks registered on other CPUs. - Or even on the current CPU if that CPU recently went offline - and came back online. +17. If you pass a callback function defined within a module to one of + call_rcu(), call_srcu(), call_rcu_tasks(), call_rcu_tasks_rude(), + or call_rcu_tasks_trace(), then it is necessary to wait for all + pending callbacks to be invoked before unloading that module. + Note that it is absolutely *not* sufficient to wait for a grace + period! For example, synchronize_rcu() implementation is *not* + guaranteed to wait for callbacks registered on other CPUs via + call_rcu(). Or even on the current CPU if that CPU recently + went offline and came back online. You instead need to use one of the barrier functions: - call_rcu() -> rcu_barrier() - call_srcu() -> srcu_barrier() + - call_rcu_tasks() -> rcu_barrier_tasks() + - call_rcu_tasks_rude() -> rcu_barrier_tasks_rude() + - call_rcu_tasks_trace() -> rcu_barrier_tasks_trace() However, these barrier functions are absolutely *not* guaranteed - to wait for a grace period. In fact, if there are no call_rcu() - callbacks waiting anywhere in the system, rcu_barrier() is within - its rights to return immediately. - - So if you need to wait for both an RCU grace period and for - all pre-existing call_rcu() callbacks, you will need to execute - both rcu_barrier() and synchronize_rcu(), if necessary, using - something like workqueues to execute them concurrently. + to wait for a grace period. For example, if there are no + call_rcu() callbacks queued anywhere in the system, rcu_barrier() + can and will return immediately. + + So if you need to wait for both a grace period and for all + pre-existing callbacks, you will need to invoke both functions, + with the pair depending on the flavor of RCU: + + - Either synchronize_rcu() or synchronize_rcu_expedited(), + together with rcu_barrier() + - Either synchronize_srcu() or synchronize_srcu_expedited(), + together with and srcu_barrier() + - synchronize_rcu_tasks() and rcu_barrier_tasks() + - synchronize_tasks_rude() and rcu_barrier_tasks_rude() + - synchronize_tasks_trace() and rcu_barrier_tasks_trace() + + If necessary, you can use something like workqueues to execute + the requisite pair of functions concurrently. See rcubarrier.rst for more information. diff --git a/Documentation/RCU/index.rst b/Documentation/RCU/index.rst index e703d3dbe60c..84a79903f6a8 100644 --- a/Documentation/RCU/index.rst +++ b/Documentation/RCU/index.rst @@ -9,7 +9,6 @@ RCU concepts .. toctree:: :maxdepth: 3 - arrayRCU checklist lockdep lockdep-splat diff --git a/Documentation/RCU/listRCU.rst b/Documentation/RCU/listRCU.rst index 2a643e293fb4..bdc4bcc5289f 100644 --- a/Documentation/RCU/listRCU.rst +++ b/Documentation/RCU/listRCU.rst @@ -3,11 +3,10 @@ Using RCU to Protect Read-Mostly Linked Lists ============================================= -One of the best applications of RCU is to protect read-mostly linked lists -(``struct list_head`` in list.h). One big advantage of this approach -is that all of the required memory barriers are included for you in -the list macros. This document describes several applications of RCU, -with the best fits first. +One of the most common uses of RCU is protecting read-mostly linked lists +(``struct list_head`` in list.h). One big advantage of this approach is +that all of the required memory ordering is provided by the list macros. +This document describes several list-based RCU use cases. Example 1: Read-mostly list: Deferred Destruction @@ -35,7 +34,8 @@ The code traversing the list of all processes typically looks like:: } rcu_read_unlock(); -The simplified code for removing a process from a task list is:: +The simplified and heavily inlined code for removing a process from a +task list is:: void release_task(struct task_struct *p) { @@ -45,39 +45,48 @@ The simplified code for removing a process from a task list is:: call_rcu(&p->rcu, delayed_put_task_struct); } -When a process exits, ``release_task()`` calls ``list_del_rcu(&p->tasks)`` under -``tasklist_lock`` writer lock protection, to remove the task from the list of -all tasks. The ``tasklist_lock`` prevents concurrent list additions/removals -from corrupting the list. Readers using ``for_each_process()`` are not protected -with the ``tasklist_lock``. To prevent readers from noticing changes in the list -pointers, the ``task_struct`` object is freed only after one or more grace -periods elapse (with the help of call_rcu()). This deferring of destruction -ensures that any readers traversing the list will see valid ``p->tasks.next`` -pointers and deletion/freeing can happen in parallel with traversal of the list. -This pattern is also called an **existence lock**, since RCU pins the object in -memory until all existing readers finish. +When a process exits, ``release_task()`` calls ``list_del_rcu(&p->tasks)`` +via __exit_signal() and __unhash_process() under ``tasklist_lock`` +writer lock protection. The list_del_rcu() invocation removes +the task from the list of all tasks. The ``tasklist_lock`` +prevents concurrent list additions/removals from corrupting the +list. Readers using ``for_each_process()`` are not protected with the +``tasklist_lock``. To prevent readers from noticing changes in the list +pointers, the ``task_struct`` object is freed only after one or more +grace periods elapse, with the help of call_rcu(), which is invoked via +put_task_struct_rcu_user(). This deferring of destruction ensures that +any readers traversing the list will see valid ``p->tasks.next`` pointers +and deletion/freeing can happen in parallel with traversal of the list. +This pattern is also called an **existence lock**, since RCU refrains +from invoking the delayed_put_task_struct() callback function until +all existing readers finish, which guarantees that the ``task_struct`` +object in question will remain in existence until after the completion +of all RCU readers that might possibly have a reference to that object. Example 2: Read-Side Action Taken Outside of Lock: No In-Place Updates ---------------------------------------------------------------------- -The best applications are cases where, if reader-writer locking were -used, the read-side lock would be dropped before taking any action -based on the results of the search. The most celebrated example is -the routing table. Because the routing table is tracking the state of -equipment outside of the computer, it will at times contain stale data. -Therefore, once the route has been computed, there is no need to hold -the routing table static during transmission of the packet. After all, -you can hold the routing table static all you want, but that won't keep -the external Internet from changing, and it is the state of the external -Internet that really matters. In addition, routing entries are typically -added or deleted, rather than being modified in place. - -A straightforward example of this use of RCU may be found in the -system-call auditing support. For example, a reader-writer locked +Some reader-writer locking use cases compute a value while holding +the read-side lock, but continue to use that value after that lock is +released. These use cases are often good candidates for conversion +to RCU. One prominent example involves network packet routing. +Because the packet-routing data tracks the state of equipment outside +of the computer, it will at times contain stale data. Therefore, once +the route has been computed, there is no need to hold the routing table +static during transmission of the packet. After all, you can hold the +routing table static all you want, but that won't keep the external +Internet from changing, and it is the state of the external Internet +that really matters. In addition, routing entries are typically added +or deleted, rather than being modified in place. This is a rare example +of the finite speed of light and the non-zero size of atoms actually +helping make synchronization be lighter weight. + +A straightforward example of this type of RCU use case may be found in +the system-call auditing support. For example, a reader-writer locked implementation of ``audit_filter_task()`` might be as follows:: - static enum audit_state audit_filter_task(struct task_struct *tsk) + static enum audit_state audit_filter_task(struct task_struct *tsk, char **key) { struct audit_entry *e; enum audit_state state; @@ -86,6 +95,8 @@ implementation of ``audit_filter_task()`` might be as follows:: /* Note: audit_filter_mutex held by caller. */ list_for_each_entry(e, &audit_tsklist, list) { if (audit_filter_rules(tsk, &e->rule, NULL, &state)) { + if (state == AUDIT_STATE_RECORD) + *key = kstrdup(e->rule.filterkey, GFP_ATOMIC); read_unlock(&auditsc_lock); return state; } @@ -101,7 +112,7 @@ you are turning auditing off, it is OK to audit a few extra system calls. This means that RCU can be easily applied to the read side, as follows:: - static enum audit_state audit_filter_task(struct task_struct *tsk) + static enum audit_state audit_filter_task(struct task_struct *tsk, char **key) { struct audit_entry *e; enum audit_state state; @@ -110,6 +121,8 @@ This means that RCU can be easily applied to the read side, as follows:: /* Note: audit_filter_mutex held by caller. */ list_for_each_entry_rcu(e, &audit_tsklist, list) { if (audit_filter_rules(tsk, &e->rule, NULL, &state)) { + if (state == AUDIT_STATE_RECORD) + *key = kstrdup(e->rule.filterkey, GFP_ATOMIC); rcu_read_unlock(); return state; } @@ -118,13 +131,15 @@ This means that RCU can be easily applied to the read side, as follows:: return AUDIT_BUILD_CONTEXT; } -The ``read_lock()`` and ``read_unlock()`` calls have become rcu_read_lock() -and rcu_read_unlock(), respectively, and the list_for_each_entry() has -become list_for_each_entry_rcu(). The **_rcu()** list-traversal primitives -insert the read-side memory barriers that are required on DEC Alpha CPUs. +The read_lock() and read_unlock() calls have become rcu_read_lock() +and rcu_read_unlock(), respectively, and the list_for_each_entry() +has become list_for_each_entry_rcu(). The **_rcu()** list-traversal +primitives add READ_ONCE() and diagnostic checks for incorrect use +outside of an RCU read-side critical section. The changes to the update side are also straightforward. A reader-writer lock -might be used as follows for deletion and insertion:: +might be used as follows for deletion and insertion in these simplified +versions of audit_del_rule() and audit_add_rule():: static inline int audit_del_rule(struct audit_rule *rule, struct list_head *list) @@ -188,16 +203,16 @@ Following are the RCU equivalents for these two functions:: return 0; } -Normally, the ``write_lock()`` and ``write_unlock()`` would be replaced by a +Normally, the write_lock() and write_unlock() would be replaced by a spin_lock() and a spin_unlock(). But in this case, all callers hold ``audit_filter_mutex``, so no additional locking is required. The -``auditsc_lock`` can therefore be eliminated, since use of RCU eliminates the +auditsc_lock can therefore be eliminated, since use of RCU eliminates the need for writers to exclude readers. The list_del(), list_add(), and list_add_tail() primitives have been replaced by list_del_rcu(), list_add_rcu(), and list_add_tail_rcu(). -The **_rcu()** list-manipulation primitives add memory barriers that are needed on -weakly ordered CPUs (most of them!). The list_del_rcu() primitive omits the +The **_rcu()** list-manipulation primitives add memory barriers that are +needed on weakly ordered CPUs. The list_del_rcu() primitive omits the pointer poisoning debug-assist code that would otherwise cause concurrent readers to fail spectacularly. @@ -238,7 +253,9 @@ need to be filled in):: The RCU version creates a copy, updates the copy, then replaces the old entry with the newly updated entry. This sequence of actions, allowing concurrent reads while making a copy to perform an update, is what gives -RCU (*read-copy update*) its name. The RCU code is as follows:: +RCU (*read-copy update*) its name. + +The RCU version of audit_upd_rule() is as follows:: static inline int audit_upd_rule(struct audit_rule *rule, struct list_head *list, @@ -267,6 +284,9 @@ RCU (*read-copy update*) its name. The RCU code is as follows:: Again, this assumes that the caller holds ``audit_filter_mutex``. Normally, the writer lock would become a spinlock in this sort of code. +The update_lsm_rule() does something very similar, for those who would +prefer to look at real Linux-kernel code. + Another use of this pattern can be found in the openswitch driver's *connection tracking table* code in ``ct_limit_set()``. The table holds connection tracking entries and has a limit on the maximum entries. There is one such table @@ -281,9 +301,10 @@ Example 4: Eliminating Stale Data --------------------------------- The auditing example above tolerates stale data, as do most algorithms -that are tracking external state. Because there is a delay from the -time the external state changes before Linux becomes aware of the change, -additional RCU-induced staleness is generally not a problem. +that are tracking external state. After all, given there is a delay +from the time the external state changes before Linux becomes aware +of the change, and so as noted earlier, a small quantity of additional +RCU-induced staleness is generally not a problem. However, there are many examples where stale data cannot be tolerated. One example in the Linux kernel is the System V IPC (see the shm_lock() @@ -302,7 +323,7 @@ Quick Quiz: If the system-call audit module were to ever need to reject stale data, one way to accomplish this would be to add a ``deleted`` flag and a ``lock`` spinlock to the -audit_entry structure, and modify ``audit_filter_task()`` as follows:: +``audit_entry`` structure, and modify audit_filter_task() as follows:: static enum audit_state audit_filter_task(struct task_struct *tsk) { @@ -319,6 +340,8 @@ audit_entry structure, and modify ``audit_filter_task()`` as follows:: return AUDIT_BUILD_CONTEXT; } rcu_read_unlock(); + if (state == AUDIT_STATE_RECORD) + *key = kstrdup(e->rule.filterkey, GFP_ATOMIC); return state; } } @@ -326,12 +349,6 @@ audit_entry structure, and modify ``audit_filter_task()`` as follows:: return AUDIT_BUILD_CONTEXT; } -Note that this example assumes that entries are only added and deleted. -Additional mechanism is required to deal correctly with the update-in-place -performed by ``audit_upd_rule()``. For one thing, ``audit_upd_rule()`` would -need additional memory barriers to ensure that the list_add_rcu() was really -executed before the list_del_rcu(). - The ``audit_del_rule()`` function would need to set the ``deleted`` flag under the spinlock as follows:: @@ -357,24 +374,32 @@ spinlock as follows:: This too assumes that the caller holds ``audit_filter_mutex``. +Note that this example assumes that entries are only added and deleted. +Additional mechanism is required to deal correctly with the update-in-place +performed by audit_upd_rule(). For one thing, audit_upd_rule() would +need to hold the locks of both the old ``audit_entry`` and its replacement +while executing the list_replace_rcu(). + Example 5: Skipping Stale Objects --------------------------------- -For some usecases, reader performance can be improved by skipping stale objects -during read-side list traversal if the object in concern is pending destruction -after one or more grace periods. One such example can be found in the timerfd -subsystem. When a ``CLOCK_REALTIME`` clock is reprogrammed - for example due to -setting of the system time, then all programmed timerfds that depend on this -clock get triggered and processes waiting on them to expire are woken up in -advance of their scheduled expiry. To facilitate this, all such timers are added -to an RCU-managed ``cancel_list`` when they are setup in +For some use cases, reader performance can be improved by skipping +stale objects during read-side list traversal, where stale objects +are those that will be removed and destroyed after one or more grace +periods. One such example can be found in the timerfd subsystem. When a +``CLOCK_REALTIME`` clock is reprogrammed (for example due to setting +of the system time) then all programmed ``timerfds`` that depend on +this clock get triggered and processes waiting on them are awakened in +advance of their scheduled expiry. To facilitate this, all such timers +are added to an RCU-managed ``cancel_list`` when they are setup in ``timerfd_setup_cancel()``:: static void timerfd_setup_cancel(struct timerfd_ctx *ctx, int flags) { spin_lock(&ctx->cancel_lock); - if ((ctx->clockid == CLOCK_REALTIME && + if ((ctx->clockid == CLOCK_REALTIME || + ctx->clockid == CLOCK_REALTIME_ALARM) && (flags & TFD_TIMER_ABSTIME) && (flags & TFD_TIMER_CANCEL_ON_SET)) { if (!ctx->might_cancel) { ctx->might_cancel = true; @@ -382,13 +407,16 @@ to an RCU-managed ``cancel_list`` when they are setup in list_add_rcu(&ctx->clist, &cancel_list); spin_unlock(&cancel_lock); } + } else { + __timerfd_remove_cancel(ctx); } spin_unlock(&ctx->cancel_lock); } -When a timerfd is freed (fd is closed), then the ``might_cancel`` flag of the -timerfd object is cleared, the object removed from the ``cancel_list`` and -destroyed:: +When a timerfd is freed (fd is closed), then the ``might_cancel`` +flag of the timerfd object is cleared, the object removed from the +``cancel_list`` and destroyed, as shown in this simplified and inlined +version of timerfd_release():: int timerfd_release(struct inode *inode, struct file *file) { @@ -403,7 +431,10 @@ destroyed:: } spin_unlock(&ctx->cancel_lock); - hrtimer_cancel(&ctx->t.tmr); + if (isalarm(ctx)) + alarm_cancel(&ctx->t.alarm); + else + hrtimer_cancel(&ctx->t.tmr); kfree_rcu(ctx, rcu); return 0; } @@ -416,6 +447,7 @@ objects:: void timerfd_clock_was_set(void) { + ktime_t moffs = ktime_mono_to_real(0); struct timerfd_ctx *ctx; unsigned long flags; @@ -424,7 +456,7 @@ objects:: if (!ctx->might_cancel) continue; spin_lock_irqsave(&ctx->wqh.lock, flags); - if (ctx->moffs != ktime_mono_to_real(0)) { + if (ctx->moffs != moffs) { ctx->moffs = KTIME_MAX; ctx->ticks++; wake_up_locked_poll(&ctx->wqh, EPOLLIN); @@ -434,10 +466,10 @@ objects:: rcu_read_unlock(); } -The key point here is, because RCU-traversal of the ``cancel_list`` happens -while objects are being added and removed to the list, sometimes the traversal -can step on an object that has been removed from the list. In this example, it -is seen that it is better to skip such objects using a flag. +The key point is that because RCU-protected traversal of the +``cancel_list`` happens concurrently with object addition and removal, +sometimes the traversal can access an object that has been removed from +the list. In this example, a flag is used to skip such objects. Summary diff --git a/Documentation/RCU/lockdep.rst b/Documentation/RCU/lockdep.rst index a94f55991a71..9308f1bdba05 100644 --- a/Documentation/RCU/lockdep.rst +++ b/Documentation/RCU/lockdep.rst @@ -17,7 +17,9 @@ state:: rcu_read_lock_held() for normal RCU. rcu_read_lock_bh_held() for RCU-bh. rcu_read_lock_sched_held() for RCU-sched. + rcu_read_lock_any_held() for any of normal RCU, RCU-bh, and RCU-sched. srcu_read_lock_held() for SRCU. + rcu_read_lock_trace_held() for RCU Tasks Trace. These functions are conservative, and will therefore return 1 if they aren't certain (for example, if CONFIG_DEBUG_LOCK_ALLOC is not set). @@ -53,6 +55,8 @@ checking of rcu_dereference() primitives: is invoked by both SRCU readers and updaters. rcu_dereference_raw(p): Don't check. (Use sparingly, if at all.) + rcu_dereference_raw_check(p): + Don't do lockdep at all. (Use sparingly, if at all.) rcu_dereference_protected(p, c): Use explicit check expression "c", and omit all barriers and compiler constraints. This is useful when the data diff --git a/Documentation/admin-guide/acpi/index.rst b/Documentation/admin-guide/acpi/index.rst index 71277689ad97..b078fdb8f4c9 100644 --- a/Documentation/admin-guide/acpi/index.rst +++ b/Documentation/admin-guide/acpi/index.rst @@ -9,7 +9,6 @@ the Linux ACPI support. :maxdepth: 1 initrd_table_override - dsdt-override ssdt-overlays cppc_sysfs fan_performance_states diff --git a/Documentation/admin-guide/device-mapper/verity.rst b/Documentation/admin-guide/device-mapper/verity.rst index 1a6b91368e59..a65c1602cb23 100644 --- a/Documentation/admin-guide/device-mapper/verity.rst +++ b/Documentation/admin-guide/device-mapper/verity.rst @@ -141,6 +141,10 @@ root_hash_sig_key_desc <key_description> also gain new certificates at run time if they are signed by a certificate already in the secondary trusted keyring. +try_verify_in_tasklet + If verity hashes are in cache, verify data blocks in kernel tasklet instead + of workqueue. This option can reduce IO latency. + Theory of operation =================== diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index a465d5242774..eb75778ad7e2 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -831,7 +831,7 @@ memory region [offset, offset + size] for that kernel image. If '@offset' is omitted, then a suitable offset is selected automatically. - [KNL, X86-64] Select a region under 4G first, and + [KNL, X86-64, ARM64] Select a region under 4G first, and fall back to reserve region above 4G when '@offset' hasn't been specified. See Documentation/admin-guide/kdump/kdump.rst for further details. @@ -851,26 +851,23 @@ available. It will be ignored if crashkernel=X is specified. crashkernel=size[KMG],low - [KNL, X86-64] range under 4G. When crashkernel=X,high + [KNL, X86-64, ARM64] range under 4G. When crashkernel=X,high is passed, kernel could allocate physical memory region above 4G, that cause second kernel crash on system that require some amount of low memory, e.g. swiotlb requires at least 64M+32K low memory, also enough extra low memory is needed to make sure DMA buffers for 32-bit devices won't run out. Kernel would try to allocate - at least 256M below 4G automatically. + default size of memory below 4G automatically. The default + size is platform dependent. + --> x86: max(swiotlb_size_or_default() + 8MiB, 256MiB) + --> arm64: 128MiB This one lets the user specify own low range under 4G for second kernel instead. 0: to disable low allocation. It will be ignored when crashkernel=X,high is not used or memory reserved is below 4G. - [KNL, ARM64] range in low memory. - This one lets the user specify a low range in the - DMA zone for the crash dump kernel. - It will be ignored when crashkernel=X,high is not used - or memory reserved is located in the DMA zones. - cryptomgr.notests [KNL] Disable crypto self-tests @@ -6959,3 +6956,14 @@ memory, and other data can't be written using xmon commands. off xmon is disabled. + + amd_pstate= [X86] + disable + Do not enable amd_pstate as the default + scaling driver for the supported processors + passive + Use amd_pstate as a scaling driver, driver requests a + desired performance on this abstract scale and the power + management firmware translates the requests into actual + hardware states (core frequency, data fabric and memory + clocks etc.) diff --git a/Documentation/admin-guide/media/vivid.rst b/Documentation/admin-guide/media/vivid.rst index 4f680dc9661c..abd90ed31090 100644 --- a/Documentation/admin-guide/media/vivid.rst +++ b/Documentation/admin-guide/media/vivid.rst @@ -1318,7 +1318,7 @@ instance. This setup would require the following commands: $ v4l2-ctl -d2 -i2 $ v4l2-ctl -d2 -c horizontal_movement=4 $ v4l2-ctl -d1 --overlay=1 - $ v4l2-ctl -d1 -c loop_video=1 + $ v4l2-ctl -d0 -c loop_video=1 $ v4l2-ctl -d2 --stream-mmap --overlay=1 And from another console: diff --git a/Documentation/admin-guide/perf/hisi-pcie-pmu.rst b/Documentation/admin-guide/perf/hisi-pcie-pmu.rst index 294ebbdb22af..7e863662e2d4 100644 --- a/Documentation/admin-guide/perf/hisi-pcie-pmu.rst +++ b/Documentation/admin-guide/perf/hisi-pcie-pmu.rst @@ -15,10 +15,10 @@ HiSilicon PCIe PMU driver The PCIe PMU driver registers a perf PMU with the name of its sicl-id and PCIe Core id.:: - /sys/bus/event_source/hisi_pcie<sicl>_<core> + /sys/bus/event_source/hisi_pcie<sicl>_core<core> PMU driver provides description of available events and filter options in sysfs, -see /sys/bus/event_source/devices/hisi_pcie<sicl>_<core>. +see /sys/bus/event_source/devices/hisi_pcie<sicl>_core<core>. The "format" directory describes all formats of the config (events) and config1 (filter options) fields of the perf_event_attr structure. The "events" directory @@ -33,13 +33,13 @@ monitored by PMU. Example usage of perf:: $# perf list - hisi_pcie0_0/rx_mwr_latency/ [kernel PMU event] - hisi_pcie0_0/rx_mwr_cnt/ [kernel PMU event] + hisi_pcie0_core0/rx_mwr_latency/ [kernel PMU event] + hisi_pcie0_core0/rx_mwr_cnt/ [kernel PMU event] ------------------------------------------ - $# perf stat -e hisi_pcie0_0/rx_mwr_latency/ - $# perf stat -e hisi_pcie0_0/rx_mwr_cnt/ - $# perf stat -g -e hisi_pcie0_0/rx_mwr_latency/ -e hisi_pcie0_0/rx_mwr_cnt/ + $# perf stat -e hisi_pcie0_core0/rx_mwr_latency/ + $# perf stat -e hisi_pcie0_core0/rx_mwr_cnt/ + $# perf stat -g -e hisi_pcie0_core0/rx_mwr_latency/ -e hisi_pcie0_core0/rx_mwr_cnt/ The current driver does not support sampling. So "perf record" is unsupported. Also attach to a task is unsupported for PCIe PMU. @@ -48,59 +48,83 @@ Filter options -------------- 1. Target filter -PMU could only monitor the performance of traffic downstream target Root Ports -or downstream target Endpoint. PCIe PMU driver support "port" and "bdf" -interfaces for users, and these two interfaces aren't supported at the same -time. --port -"port" filter can be used in all PCIe PMU events, target Root Port can be -selected by configuring the 16-bits-bitmap "port". Multi ports can be selected -for AP-layer-events, and only one port can be selected for TL/DL-layer-events. + PMU could only monitor the performance of traffic downstream target Root + Ports or downstream target Endpoint. PCIe PMU driver support "port" and + "bdf" interfaces for users, and these two interfaces aren't supported at the + same time. -For example, if target Root Port is 0000:00:00.0 (x8 lanes), bit0 of bitmap -should be set, port=0x1; if target Root Port is 0000:00:04.0 (x4 lanes), -bit8 is set, port=0x100; if these two Root Ports are both monitored, port=0x101. + - port -Example usage of perf:: + "port" filter can be used in all PCIe PMU events, target Root Port can be + selected by configuring the 16-bits-bitmap "port". Multi ports can be + selected for AP-layer-events, and only one port can be selected for + TL/DL-layer-events. - $# perf stat -e hisi_pcie0_0/rx_mwr_latency,port=0x1/ sleep 5 + For example, if target Root Port is 0000:00:00.0 (x8 lanes), bit0 of + bitmap should be set, port=0x1; if target Root Port is 0000:00:04.0 (x4 + lanes), bit8 is set, port=0x100; if these two Root Ports are both + monitored, port=0x101. --bdf + Example usage of perf:: -"bdf" filter can only be used in bandwidth events, target Endpoint is selected -by configuring BDF to "bdf". Counter only counts the bandwidth of message -requested by target Endpoint. + $# perf stat -e hisi_pcie0_core0/rx_mwr_latency,port=0x1/ sleep 5 -For example, "bdf=0x3900" means BDF of target Endpoint is 0000:39:00.0. + - bdf -Example usage of perf:: + "bdf" filter can only be used in bandwidth events, target Endpoint is + selected by configuring BDF to "bdf". Counter only counts the bandwidth of + message requested by target Endpoint. + + For example, "bdf=0x3900" means BDF of target Endpoint is 0000:39:00.0. + + Example usage of perf:: - $# perf stat -e hisi_pcie0_0/rx_mrd_flux,bdf=0x3900/ sleep 5 + $# perf stat -e hisi_pcie0_core0/rx_mrd_flux,bdf=0x3900/ sleep 5 2. Trigger filter -Event statistics start when the first time TLP length is greater/smaller -than trigger condition. You can set the trigger condition by writing "trig_len", -and set the trigger mode by writing "trig_mode". This filter can only be used -in bandwidth events. -For example, "trig_len=4" means trigger condition is 2^4 DW, "trig_mode=0" -means statistics start when TLP length > trigger condition, "trig_mode=1" -means start when TLP length < condition. + Event statistics start when the first time TLP length is greater/smaller + than trigger condition. You can set the trigger condition by writing + "trig_len", and set the trigger mode by writing "trig_mode". This filter can + only be used in bandwidth events. -Example usage of perf:: + For example, "trig_len=4" means trigger condition is 2^4 DW, "trig_mode=0" + means statistics start when TLP length > trigger condition, "trig_mode=1" + means start when TLP length < condition. + + Example usage of perf:: - $# perf stat -e hisi_pcie0_0/rx_mrd_flux,trig_len=0x4,trig_mode=1/ sleep 5 + $# perf stat -e hisi_pcie0_core0/rx_mrd_flux,trig_len=0x4,trig_mode=1/ sleep 5 3. Threshold filter -Counter counts when TLP length within the specified range. You can set the -threshold by writing "thr_len", and set the threshold mode by writing -"thr_mode". This filter can only be used in bandwidth events. -For example, "thr_len=4" means threshold is 2^4 DW, "thr_mode=0" means -counter counts when TLP length >= threshold, and "thr_mode=1" means counts -when TLP length < threshold. + Counter counts when TLP length within the specified range. You can set the + threshold by writing "thr_len", and set the threshold mode by writing + "thr_mode". This filter can only be used in bandwidth events. -Example usage of perf:: + For example, "thr_len=4" means threshold is 2^4 DW, "thr_mode=0" means + counter counts when TLP length >= threshold, and "thr_mode=1" means counts + when TLP length < threshold. + + Example usage of perf:: + + $# perf stat -e hisi_pcie0_core0/rx_mrd_flux,thr_len=0x4,thr_mode=1/ sleep 5 + +4. TLP Length filter + + When counting bandwidth, the data can be composed of certain parts of TLP + packets. You can specify it through "len_mode": + + - 2'b00: Reserved (Do not use this since the behaviour is undefined) + - 2'b01: Bandwidth of TLP payloads + - 2'b10: Bandwidth of TLP headers + - 2'b11: Bandwidth of both TLP payloads and headers + + For example, "len_mode=2" means only counting the bandwidth of TLP headers + and "len_mode=3" means the final bandwidth data is composed of both TLP + headers and payloads. Default value if not specified is 2'b11. + + Example usage of perf:: - $# perf stat -e hisi_pcie0_0/rx_mrd_flux,thr_len=0x4,thr_mode=1/ sleep 5 + $# perf stat -e hisi_pcie0_core0/rx_mrd_flux,len_mode=0x1/ sleep 5 diff --git a/Documentation/admin-guide/perf/index.rst b/Documentation/admin-guide/perf/index.rst index 793e1970bc05..9de64a40adab 100644 --- a/Documentation/admin-guide/perf/index.rst +++ b/Documentation/admin-guide/perf/index.rst @@ -19,3 +19,5 @@ Performance monitor support arm_dsu_pmu thunderx2-pmu alibaba_pmu + nvidia-pmu + meson-ddr-pmu diff --git a/Documentation/admin-guide/perf/meson-ddr-pmu.rst b/Documentation/admin-guide/perf/meson-ddr-pmu.rst new file mode 100644 index 000000000000..8e71be1d6346 --- /dev/null +++ b/Documentation/admin-guide/perf/meson-ddr-pmu.rst @@ -0,0 +1,70 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================================================== +Amlogic SoC DDR Bandwidth Performance Monitoring Unit (PMU) +=========================================================== + +The Amlogic Meson G12 SoC contains a bandwidth monitor inside DRAM controller. +The monitor includes 4 channels. Each channel can count the request accessing +DRAM. The channel can count up to 3 AXI port simultaneously. It can be helpful +to show if the performance bottleneck is on DDR bandwidth. + +Currently, this driver supports the following 5 perf events: + ++ meson_ddr_bw/total_rw_bytes/ ++ meson_ddr_bw/chan_1_rw_bytes/ ++ meson_ddr_bw/chan_2_rw_bytes/ ++ meson_ddr_bw/chan_3_rw_bytes/ ++ meson_ddr_bw/chan_4_rw_bytes/ + +meson_ddr_bw/chan_{1,2,3,4}_rw_bytes/ events are channel-specific events. +Each channel support filtering, which can let the channel to monitor +individual IP module in SoC. + +Below are DDR access request event filter keywords: + ++ arm - from CPU ++ vpu_read1 - from OSD + VPP read ++ gpu - from 3D GPU ++ pcie - from PCIe controller ++ hdcp - from HDCP controller ++ hevc_front - from HEVC codec front end ++ usb3_0 - from USB3.0 controller ++ hevc_back - from HEVC codec back end ++ h265enc - from HEVC encoder ++ vpu_read2 - from DI read ++ vpu_write1 - from VDIN write ++ vpu_write2 - from di write ++ vdec - from legacy codec video decoder ++ hcodec - from H264 encoder ++ ge2d - from ge2d ++ spicc1 - from SPI controller 1 ++ usb0 - from USB2.0 controller 0 ++ dma - from system DMA controller 1 ++ arb0 - from arb0 ++ sd_emmc_b - from SD eMMC b controller ++ usb1 - from USB2.0 controller 1 ++ audio - from Audio module ++ sd_emmc_c - from SD eMMC c controller ++ spicc2 - from SPI controller 2 ++ ethernet - from Ethernet controller + + +Examples: + + + Show the total DDR bandwidth per seconds: + + .. code-block:: bash + + perf stat -a -e meson_ddr_bw/total_rw_bytes/ -I 1000 sleep 10 + + + + Show individual DDR bandwidth from CPU and GPU respectively, as well as + sum of them: + + .. code-block:: bash + + perf stat -a -e meson_ddr_bw/chan_1_rw_bytes,arm=1/ -I 1000 sleep 10 + perf stat -a -e meson_ddr_bw/chan_2_rw_bytes,gpu=1/ -I 1000 sleep 10 + perf stat -a -e meson_ddr_bw/chan_3_rw_bytes,arm=1,gpu=1/ -I 1000 sleep 10 + diff --git a/Documentation/admin-guide/perf/nvidia-pmu.rst b/Documentation/admin-guide/perf/nvidia-pmu.rst new file mode 100644 index 000000000000..2e0d47cfe7ea --- /dev/null +++ b/Documentation/admin-guide/perf/nvidia-pmu.rst @@ -0,0 +1,299 @@ +========================================================= +NVIDIA Tegra SoC Uncore Performance Monitoring Unit (PMU) +========================================================= + +The NVIDIA Tegra SoC includes various system PMUs to measure key performance +metrics like memory bandwidth, latency, and utilization: + +* Scalable Coherency Fabric (SCF) +* NVLink-C2C0 +* NVLink-C2C1 +* CNVLink +* PCIE + +PMU Driver +---------- + +The PMUs in this document are based on ARM CoreSight PMU Architecture as +described in document: ARM IHI 0091. Since this is a standard architecture, the +PMUs are managed by a common driver "arm-cs-arch-pmu". This driver describes +the available events and configuration of each PMU in sysfs. Please see the +sections below to get the sysfs path of each PMU. Like other uncore PMU drivers, +the driver provides "cpumask" sysfs attribute to show the CPU id used to handle +the PMU event. There is also "associated_cpus" sysfs attribute, which contains a +list of CPUs associated with the PMU instance. + +.. _SCF_PMU_Section: + +SCF PMU +------- + +The SCF PMU monitors system level cache events, CPU traffic, and +strongly-ordered (SO) PCIE write traffic to local/remote memory. Please see +:ref:`NVIDIA_Uncore_PMU_Traffic_Coverage_Section` for more info about the PMU +traffic coverage. + +The events and configuration options of this PMU device are described in sysfs, +see /sys/bus/event_sources/devices/nvidia_scf_pmu_<socket-id>. + +Example usage: + +* Count event id 0x0 in socket 0:: + + perf stat -a -e nvidia_scf_pmu_0/event=0x0/ + +* Count event id 0x0 in socket 1:: + + perf stat -a -e nvidia_scf_pmu_1/event=0x0/ + +NVLink-C2C0 PMU +-------------------- + +The NVLink-C2C0 PMU monitors incoming traffic from a GPU/CPU connected with +NVLink-C2C (Chip-2-Chip) interconnect. The type of traffic captured by this PMU +varies dependent on the chip configuration: + +* NVIDIA Grace Hopper Superchip: Hopper GPU is connected with Grace SoC. + + In this config, the PMU captures GPU ATS translated or EGM traffic from the GPU. + +* NVIDIA Grace CPU Superchip: two Grace CPU SoCs are connected. + + In this config, the PMU captures read and relaxed ordered (RO) writes from + PCIE device of the remote SoC. + +Please see :ref:`NVIDIA_Uncore_PMU_Traffic_Coverage_Section` for more info about +the PMU traffic coverage. + +The events and configuration options of this PMU device are described in sysfs, +see /sys/bus/event_sources/devices/nvidia_nvlink_c2c0_pmu_<socket-id>. + +Example usage: + +* Count event id 0x0 from the GPU/CPU connected with socket 0:: + + perf stat -a -e nvidia_nvlink_c2c0_pmu_0/event=0x0/ + +* Count event id 0x0 from the GPU/CPU connected with socket 1:: + + perf stat -a -e nvidia_nvlink_c2c0_pmu_1/event=0x0/ + +* Count event id 0x0 from the GPU/CPU connected with socket 2:: + + perf stat -a -e nvidia_nvlink_c2c0_pmu_2/event=0x0/ + +* Count event id 0x0 from the GPU/CPU connected with socket 3:: + + perf stat -a -e nvidia_nvlink_c2c0_pmu_3/event=0x0/ + +NVLink-C2C1 PMU +------------------- + +The NVLink-C2C1 PMU monitors incoming traffic from a GPU connected with +NVLink-C2C (Chip-2-Chip) interconnect. This PMU captures untranslated GPU +traffic, in contrast with NvLink-C2C0 PMU that captures ATS translated traffic. +Please see :ref:`NVIDIA_Uncore_PMU_Traffic_Coverage_Section` for more info about +the PMU traffic coverage. + +The events and configuration options of this PMU device are described in sysfs, +see /sys/bus/event_sources/devices/nvidia_nvlink_c2c1_pmu_<socket-id>. + +Example usage: + +* Count event id 0x0 from the GPU connected with socket 0:: + + perf stat -a -e nvidia_nvlink_c2c1_pmu_0/event=0x0/ + +* Count event id 0x0 from the GPU connected with socket 1:: + + perf stat -a -e nvidia_nvlink_c2c1_pmu_1/event=0x0/ + +* Count event id 0x0 from the GPU connected with socket 2:: + + perf stat -a -e nvidia_nvlink_c2c1_pmu_2/event=0x0/ + +* Count event id 0x0 from the GPU connected with socket 3:: + + perf stat -a -e nvidia_nvlink_c2c1_pmu_3/event=0x0/ + +CNVLink PMU +--------------- + +The CNVLink PMU monitors traffic from GPU and PCIE device on remote sockets +to local memory. For PCIE traffic, this PMU captures read and relaxed ordered +(RO) write traffic. Please see :ref:`NVIDIA_Uncore_PMU_Traffic_Coverage_Section` +for more info about the PMU traffic coverage. + +The events and configuration options of this PMU device are described in sysfs, +see /sys/bus/event_sources/devices/nvidia_cnvlink_pmu_<socket-id>. + +Each SoC socket can be connected to one or more sockets via CNVLink. The user can +use "rem_socket" bitmap parameter to select the remote socket(s) to monitor. +Each bit represents the socket number, e.g. "rem_socket=0xE" corresponds to +socket 1 to 3. +/sys/bus/event_sources/devices/nvidia_cnvlink_pmu_<socket-id>/format/rem_socket +shows the valid bits that can be set in the "rem_socket" parameter. + +The PMU can not distinguish the remote traffic initiator, therefore it does not +provide filter to select the traffic source to monitor. It reports combined +traffic from remote GPU and PCIE devices. + +Example usage: + +* Count event id 0x0 for the traffic from remote socket 1, 2, and 3 to socket 0:: + + perf stat -a -e nvidia_cnvlink_pmu_0/event=0x0,rem_socket=0xE/ + +* Count event id 0x0 for the traffic from remote socket 0, 2, and 3 to socket 1:: + + perf stat -a -e nvidia_cnvlink_pmu_1/event=0x0,rem_socket=0xD/ + +* Count event id 0x0 for the traffic from remote socket 0, 1, and 3 to socket 2:: + + perf stat -a -e nvidia_cnvlink_pmu_2/event=0x0,rem_socket=0xB/ + +* Count event id 0x0 for the traffic from remote socket 0, 1, and 2 to socket 3:: + + perf stat -a -e nvidia_cnvlink_pmu_3/event=0x0,rem_socket=0x7/ + + +PCIE PMU +------------ + +The PCIE PMU monitors all read/write traffic from PCIE root ports to +local/remote memory. Please see :ref:`NVIDIA_Uncore_PMU_Traffic_Coverage_Section` +for more info about the PMU traffic coverage. + +The events and configuration options of this PMU device are described in sysfs, +see /sys/bus/event_sources/devices/nvidia_pcie_pmu_<socket-id>. + +Each SoC socket can support multiple root ports. The user can use +"root_port" bitmap parameter to select the port(s) to monitor, i.e. +"root_port=0xF" corresponds to root port 0 to 3. +/sys/bus/event_sources/devices/nvidia_pcie_pmu_<socket-id>/format/root_port +shows the valid bits that can be set in the "root_port" parameter. + +Example usage: + +* Count event id 0x0 from root port 0 and 1 of socket 0:: + + perf stat -a -e nvidia_pcie_pmu_0/event=0x0,root_port=0x3/ + +* Count event id 0x0 from root port 0 and 1 of socket 1:: + + perf stat -a -e nvidia_pcie_pmu_1/event=0x0,root_port=0x3/ + +.. _NVIDIA_Uncore_PMU_Traffic_Coverage_Section: + +Traffic Coverage +---------------- + +The PMU traffic coverage may vary dependent on the chip configuration: + +* **NVIDIA Grace Hopper Superchip**: Hopper GPU is connected with Grace SoC. + + Example configuration with two Grace SoCs:: + + ********************************* ********************************* + * SOCKET-A * * SOCKET-B * + * * * * + * :::::::: * * :::::::: * + * : PCIE : * * : PCIE : * + * :::::::: * * :::::::: * + * | * * | * + * | * * | * + * ::::::: ::::::::: * * ::::::::: ::::::: * + * : : : : * * : : : : * + * : GPU :<--NVLink-->: Grace :<---CNVLink--->: Grace :<--NVLink-->: GPU : * + * : : C2C : SoC : * * : SoC : C2C : : * + * ::::::: ::::::::: * * ::::::::: ::::::: * + * | | * * | | * + * | | * * | | * + * &&&&&&&& &&&&&&&& * * &&&&&&&& &&&&&&&& * + * & GMEM & & CMEM & * * & CMEM & & GMEM & * + * &&&&&&&& &&&&&&&& * * &&&&&&&& &&&&&&&& * + * * * * + ********************************* ********************************* + + GMEM = GPU Memory (e.g. HBM) + CMEM = CPU Memory (e.g. LPDDR5X) + + | + | Following table contains traffic coverage of Grace SoC PMU in socket-A: + + :: + + +--------------+-------+-----------+-----------+-----+----------+----------+ + | | Source | + + +-------+-----------+-----------+-----+----------+----------+ + | Destination | |GPU ATS |GPU Not-ATS| | Socket-B | Socket-B | + | |PCI R/W|Translated,|Translated | CPU | CPU/PCIE1| GPU/PCIE2| + | | |EGM | | | | | + +==============+=======+===========+===========+=====+==========+==========+ + | Local | PCIE |NVLink-C2C0|NVLink-C2C1| SCF | SCF PMU | CNVLink | + | SYSRAM/CMEM | PMU |PMU |PMU | PMU | | PMU | + +--------------+-------+-----------+-----------+-----+----------+----------+ + | Local GMEM | PCIE | N/A |NVLink-C2C1| SCF | SCF PMU | CNVLink | + | | PMU | |PMU | PMU | | PMU | + +--------------+-------+-----------+-----------+-----+----------+----------+ + | Remote | PCIE |NVLink-C2C0|NVLink-C2C1| SCF | | | + | SYSRAM/CMEM | PMU |PMU |PMU | PMU | N/A | N/A | + | over CNVLink | | | | | | | + +--------------+-------+-----------+-----------+-----+----------+----------+ + | Remote GMEM | PCIE |NVLink-C2C0|NVLink-C2C1| SCF | | | + | over CNVLink | PMU |PMU |PMU | PMU | N/A | N/A | + +--------------+-------+-----------+-----------+-----+----------+----------+ + + PCIE1 traffic represents strongly ordered (SO) writes. + PCIE2 traffic represents reads and relaxed ordered (RO) writes. + +* **NVIDIA Grace CPU Superchip**: two Grace CPU SoCs are connected. + + Example configuration with two Grace SoCs:: + + ******************* ******************* + * SOCKET-A * * SOCKET-B * + * * * * + * :::::::: * * :::::::: * + * : PCIE : * * : PCIE : * + * :::::::: * * :::::::: * + * | * * | * + * | * * | * + * ::::::::: * * ::::::::: * + * : : * * : : * + * : Grace :<--------NVLink------->: Grace : * + * : SoC : * C2C * : SoC : * + * ::::::::: * * ::::::::: * + * | * * | * + * | * * | * + * &&&&&&&& * * &&&&&&&& * + * & CMEM & * * & CMEM & * + * &&&&&&&& * * &&&&&&&& * + * * * * + ******************* ******************* + + GMEM = GPU Memory (e.g. HBM) + CMEM = CPU Memory (e.g. LPDDR5X) + + | + | Following table contains traffic coverage of Grace SoC PMU in socket-A: + + :: + + +-----------------+-----------+---------+----------+-------------+ + | | Source | + + +-----------+---------+----------+-------------+ + | Destination | | | Socket-B | Socket-B | + | | PCI R/W | CPU | CPU/PCIE1| PCIE2 | + | | | | | | + +=================+===========+=========+==========+=============+ + | Local | PCIE PMU | SCF PMU | SCF PMU | NVLink-C2C0 | + | SYSRAM/CMEM | | | | PMU | + +-----------------+-----------+---------+----------+-------------+ + | Remote | | | | | + | SYSRAM/CMEM | PCIE PMU | SCF PMU | N/A | N/A | + | over NVLink-C2C | | | | | + +-----------------+-----------+---------+----------+-------------+ + + PCIE1 traffic represents strongly ordered (SO) writes. + PCIE2 traffic represents reads and relaxed ordered (RO) writes. diff --git a/Documentation/admin-guide/pm/amd-pstate.rst b/Documentation/admin-guide/pm/amd-pstate.rst index 8f3d30c5a0d8..06e23538f79c 100644 --- a/Documentation/admin-guide/pm/amd-pstate.rst +++ b/Documentation/admin-guide/pm/amd-pstate.rst @@ -283,23 +283,19 @@ efficiency frequency management method on AMD processors. Kernel Module Options for ``amd-pstate`` ========================================= -.. _shared_mem: - -``shared_mem`` -Use a module param (shared_mem) to enable related processors manually with -**amd_pstate.shared_mem=1**. -Due to the performance issue on the processors with `Shared Memory Support -<perf_cap_>`_, we disable it presently and will re-enable this by default -once we address performance issue with this solution. - -To check whether the current processor is using `Full MSR Support <perf_cap_>`_ -or `Shared Memory Support <perf_cap_>`_ : :: - - ray@hr-test1:~$ lscpu | grep cppc - Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca fsrm - -If the CPU flags have ``cppc``, then this processor supports `Full MSR Support -<perf_cap_>`_. Otherwise, it supports `Shared Memory Support <perf_cap_>`_. +Passive Mode +------------ + +``amd_pstate=passive`` + +It will be enabled if the ``amd_pstate=passive`` is passed to the kernel in the command line. +In this mode, ``amd_pstate`` driver software specifies a desired QoS target in the CPPC +performance scale as a relative number. This can be expressed as percentage of nominal +performance (infrastructure max). Below the nominal sustained performance level, +desired performance expresses the average performance level of the processor subject +to the Performance Reduction Tolerance register. Above the nominal performance level, +processor must provide at least nominal performance requested and go higher if current +operating conditions allow. ``cpupower`` tool support for ``amd-pstate`` diff --git a/Documentation/arm64/acpi_object_usage.rst b/Documentation/arm64/acpi_object_usage.rst index 0609da73970b..484ef9676653 100644 --- a/Documentation/arm64/acpi_object_usage.rst +++ b/Documentation/arm64/acpi_object_usage.rst @@ -163,7 +163,7 @@ FPDT Section 5.2.23 (signature == "FPDT") **Firmware Performance Data Table** - Optional, not currently supported. + Optional, useful for boot performance profiling. GTDT Section 5.2.24 (signature == "GTDT") diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst index 8aefa1001ae5..96fe10ec6c24 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arm64/booting.rst @@ -121,8 +121,9 @@ Header notes: to the base of DRAM, since memory below it is not accessible via the linear mapping 1 - 2MB aligned base may be anywhere in physical - memory + 2MB aligned base such that all image_size bytes + counted from the start of the image are within + the 48-bit addressable range of physical memory Bits 4-63 Reserved. ============= =============================================================== @@ -340,7 +341,15 @@ Before jumping into the kernel, the following conditions must be met: - SMCR_EL2.LEN must be initialised to the same value for all CPUs the kernel will execute on. - For CPUs with the Scalable Matrix Extension FA64 feature (FEAT_SME_FA64) + - HWFGRTR_EL2.nTPIDR2_EL0 (bit 55) must be initialised to 0b01. + + - HWFGWTR_EL2.nTPIDR2_EL0 (bit 55) must be initialised to 0b01. + + - HWFGRTR_EL2.nSMPRI_EL1 (bit 54) must be initialised to 0b01. + + - HWFGWTR_EL2.nSMPRI_EL1 (bit 54) must be initialised to 0b01. + + For CPUs with the Scalable Matrix Extension FA64 feature (FEAT_SME_FA64): - If EL3 is present: diff --git a/Documentation/arm64/cpu-feature-registers.rst b/Documentation/arm64/cpu-feature-registers.rst index 04ba83e1965f..c7adc7897df6 100644 --- a/Documentation/arm64/cpu-feature-registers.rst +++ b/Documentation/arm64/cpu-feature-registers.rst @@ -92,7 +92,7 @@ operation if the source belongs to the supported system register space. The infrastructure emulates only the following system register space:: - Op0=3, Op1=0, CRn=0, CRm=0,4,5,6,7 + Op0=3, Op1=0, CRn=0, CRm=0,2,3,4,5,6,7 (See Table C5-6 'System instruction encodings for non-Debug System register accesses' in ARMv8 ARM DDI 0487A.h, for the list of @@ -293,6 +293,42 @@ infrastructure: | WFXT | [3-0] | y | +------------------------------+---------+---------+ + 10) MVFR0_EL1 - AArch32 Media and VFP Feature Register 0 + + +------------------------------+---------+---------+ + | Name | bits | visible | + +------------------------------+---------+---------+ + | FPDP | [11-8] | y | + +------------------------------+---------+---------+ + + 11) MVFR1_EL1 - AArch32 Media and VFP Feature Register 1 + + +------------------------------+---------+---------+ + | Name | bits | visible | + +------------------------------+---------+---------+ + | SIMDFMAC | [31-28] | y | + +------------------------------+---------+---------+ + | SIMDSP | [19-16] | y | + +------------------------------+---------+---------+ + | SIMDInt | [15-12] | y | + +------------------------------+---------+---------+ + | SIMDLS | [11-8] | y | + +------------------------------+---------+---------+ + + 12) ID_ISAR5_EL1 - AArch32 Instruction Set Attribute Register 5 + + +------------------------------+---------+---------+ + | Name | bits | visible | + +------------------------------+---------+---------+ + | CRC32 | [19-16] | y | + +------------------------------+---------+---------+ + | SHA2 | [15-12] | y | + +------------------------------+---------+---------+ + | SHA1 | [11-8] | y | + +------------------------------+---------+---------+ + | AES | [7-4] | y | + +------------------------------+---------+---------+ + Appendix I: Example ------------------- diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst index bb34287c8e01..6fed84f935df 100644 --- a/Documentation/arm64/elf_hwcaps.rst +++ b/Documentation/arm64/elf_hwcaps.rst @@ -275,6 +275,15 @@ HWCAP2_EBF16 HWCAP2_SVE_EBF16 Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0010. +HWCAP2_CSSC + Functionality implied by ID_AA64ISAR2_EL1.CSSC == 0b0001. + +HWCAP2_RPRFM + Functionality implied by ID_AA64ISAR2_EL1.RPRFM == 0b0001. + +HWCAP2_SVE2P1 + Functionality implied by ID_AA64ZFR0_EL1.SVEver == 0b0010. + 4. Unused AT_HWCAP bits ----------------------- diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst index 808ade4cc008..ec5f889d7681 100644 --- a/Documentation/arm64/silicon-errata.rst +++ b/Documentation/arm64/silicon-errata.rst @@ -120,6 +120,8 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A710 | #2224489 | ARM64_ERRATUM_2224489 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A715 | #2645198 | ARM64_ERRATUM_2645198 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-X2 | #2119858 | ARM64_ERRATUM_2119858 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 | diff --git a/Documentation/arm64/sve.rst b/Documentation/arm64/sve.rst index f338ee2df46d..c7a356bf4e8f 100644 --- a/Documentation/arm64/sve.rst +++ b/Documentation/arm64/sve.rst @@ -52,6 +52,7 @@ model features for SVE is included in Appendix A. HWCAP2_SVEBITPERM HWCAP2_SVESHA3 HWCAP2_SVESM4 + HWCAP2_SVE2P1 This list may be extended over time as the SVE architecture evolves. diff --git a/Documentation/block/ublk.rst b/Documentation/block/ublk.rst index 2122d1a4a541..ba45c46cc0da 100644 --- a/Documentation/block/ublk.rst +++ b/Documentation/block/ublk.rst @@ -144,6 +144,42 @@ managing and controlling ublk devices with help of several control commands: For retrieving device info via ``ublksrv_ctrl_dev_info``. It is the server's responsibility to save IO target specific info in userspace. +- ``UBLK_CMD_START_USER_RECOVERY`` + + This command is valid if ``UBLK_F_USER_RECOVERY`` feature is enabled. This + command is accepted after the old process has exited, ublk device is quiesced + and ``/dev/ublkc*`` is released. User should send this command before he starts + a new process which re-opens ``/dev/ublkc*``. When this command returns, the + ublk device is ready for the new process. + +- ``UBLK_CMD_END_USER_RECOVERY`` + + This command is valid if ``UBLK_F_USER_RECOVERY`` feature is enabled. This + command is accepted after ublk device is quiesced and a new process has + opened ``/dev/ublkc*`` and get all ublk queues be ready. When this command + returns, ublk device is unquiesced and new I/O requests are passed to the + new process. + +- user recovery feature description + + Two new features are added for user recovery: ``UBLK_F_USER_RECOVERY`` and + ``UBLK_F_USER_RECOVERY_REISSUE``. + + With ``UBLK_F_USER_RECOVERY`` set, after one ubq_daemon(ublk server's io + handler) is dying, ublk does not delete ``/dev/ublkb*`` during the whole + recovery stage and ublk device ID is kept. It is ublk server's + responsibility to recover the device context by its own knowledge. + Requests which have not been issued to userspace are requeued. Requests + which have been issued to userspace are aborted. + + With ``UBLK_F_USER_RECOVERY_REISSUE`` set, after one ubq_daemon(ublk + server's io handler) is dying, contrary to ``UBLK_F_USER_RECOVERY``, + requests which have been issued to userspace are requeued and will be + re-issued to the new process after handling ``UBLK_CMD_END_USER_RECOVERY``. + ``UBLK_F_USER_RECOVERY_REISSUE`` is designed for backends who tolerate + double-write since the driver may issue the same I/O request twice. It + might be useful to a read-only FS or a VM backend. + Data plane ---------- diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index 0793c400d4b0..06f4ab122697 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -118,6 +118,12 @@ Text Searching CRC and Math Functions in Linux =============================== +Arithmetic Overflow Checking +---------------------------- + +.. kernel-doc:: include/linux/overflow.h + :internal: + CRC Functions ------------- diff --git a/Documentation/dev-tools/kmsan.rst b/Documentation/dev-tools/kmsan.rst index 2a53a801198c..55fa82212eb2 100644 --- a/Documentation/dev-tools/kmsan.rst +++ b/Documentation/dev-tools/kmsan.rst @@ -67,6 +67,7 @@ uninitialized in the local variable, as well as the stack where the value was copied to another memory location before use. A use of uninitialized value ``v`` is reported by KMSAN in the following cases: + - in a condition, e.g. ``if (v) { ... }``; - in an indexing or pointer dereferencing, e.g. ``array[v]`` or ``*v``; - when it is copied to userspace or hardware, e.g. ``copy_to_user(..., &v, ...)``; diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 9fda2436c618..e16b5fa55847 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -163,6 +163,7 @@ properties: - azw,gsking-x - azw,gtking - azw,gtking-pro + - hardkernel,odroid-go-ultra - hardkernel,odroid-n2 - hardkernel,odroid-n2-plus - khadas,vim3 diff --git a/Documentation/devicetree/bindings/arm/apple.yaml b/Documentation/devicetree/bindings/arm/apple.yaml index 7262f3c09867..da78c69774f2 100644 --- a/Documentation/devicetree/bindings/arm/apple.yaml +++ b/Documentation/devicetree/bindings/arm/apple.yaml @@ -19,12 +19,14 @@ description: | - MacBook Air (M1, 2020) - iMac (24-inch, M1, 2021) - And devices based on the "M1 Pro" and "M1 Max" SoCs: + And devices based on the "M1 Pro", "M1 Max" and "M1 Ultra" SoCs: - MacBook Pro (14-inch, M1 Pro, 2021) - MacBook Pro (14-inch, M1 Max, 2021) - MacBook Pro (16-inch, M1 Pro, 2021) - MacBook Pro (16-inch, M1 Max, 2021) + - Mac Studio (M1 Max, 2022) + - Mac Studio (M1 Ultra, 2022) The compatible property should follow this format: @@ -67,6 +69,7 @@ properties: - apple,j457 # iMac (24-inch, 2x USB-C, M1, 2021) - const: apple,t8103 - const: apple,arm-platform + - description: Apple M1 Pro SoC based platforms items: - enum: @@ -74,14 +77,23 @@ properties: - apple,j316s # MacBook Pro (16-inch, M1 Pro, 2021) - const: apple,t6000 - const: apple,arm-platform + - description: Apple M1 Max SoC based platforms items: - enum: - apple,j314c # MacBook Pro (14-inch, M1 Max, 2021) - apple,j316c # MacBook Pro (16-inch, M1 Max, 2021) + - apple,j375c # Mac Studio (M1 Max, 2022) - const: apple,t6001 - const: apple,arm-platform + - description: Apple M1 Ultra SoC based platforms + items: + - enum: + - apple,j375d # Mac Studio (M1 Ultra, 2022) + - const: apple,t6002 + - const: apple,arm-platform + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml index 217a1d674863..73f272664e83 100644 --- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml +++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml @@ -17,6 +17,7 @@ properties: - description: AST2400 based boards items: - enum: + - delta,ahe50dc-bmc - facebook,galaxy100-bmc - facebook,wedge100-bmc - facebook,wedge40-bmc @@ -82,7 +83,7 @@ properties: - ibm,tacoma-bmc - inventec,transformer-bmc - jabil,rbp-bmc - - nuvia,dc-scm-bmc + - qcom,dc-scm-v1-bmc - quanta,s6q-bmc - const: aspeed,ast2600 diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml index 958df32b4899..52b575c40599 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml @@ -66,6 +66,7 @@ properties: - enum: - asus,rt-ac88u - dlink,dir-885l + - dlink,dir-890l - linksys,panamera - luxul,abr-4500-v1 - luxul,xap-1610-v1 @@ -97,6 +98,7 @@ properties: - description: BCM53016 based boards items: - enum: + - dlink,dwl-8610ap - meraki,mr32 - const: brcm,bcm53016 - const: brcm,bcm4708 diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index 5c13b73e4d57..7dd84f8f8e4f 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -178,11 +178,13 @@ properties: - qcom,kryo250 - qcom,kryo260 - qcom,kryo280 + - qcom,kryo360 - qcom,kryo385 - qcom,kryo468 - qcom,kryo485 - qcom,kryo560 - qcom,kryo570 + - qcom,kryo660 - qcom,kryo685 - qcom,kryo780 - qcom,scorpion diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index fbfc4f99c01e..0a5c4e29067a 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -520,6 +520,7 @@ properties: items: - enum: - fsl,imx6sl-evk # i.MX6 SoloLite EVK Board + - kobo,aura2 - kobo,tolino-shine2hd - kobo,tolino-shine3 - kobo,tolino-vision5 @@ -814,6 +815,7 @@ properties: - enum: - beacon,imx8mm-beacon-kit # i.MX8MM Beacon Development Kit - boundary,imx8mm-nitrogen8mm # i.MX8MM Nitrogen Board + - cloos,imx8mm-phg # i.MX8MM Cloos PHG Board - dmo,imx8mm-data-modul-edm-sbc # i.MX8MM eDM SBC - emtrion,emcon-mx8mm-avari # emCON-MX8MM SoM on Avari Base - fsl,imx8mm-ddr4-evk # i.MX8MM DDR4 EVK Board @@ -825,6 +827,7 @@ properties: - gw,imx8mm-gw7901 # i.MX8MM Gateworks Board - gw,imx8mm-gw7902 # i.MX8MM Gateworks Board - gw,imx8mm-gw7903 # i.MX8MM Gateworks Board + - innocomm,wb15-evk # i.MX8MM Innocomm EVK board with WB15 SoM - kontron,imx8mm-sl # i.MX8MM Kontron SL (N801X) SOM - kontron,imx8mm-osm-s # i.MX8MM Kontron OSM-S (N802X) SOM - menlo,mx8menlo # i.MX8MM Menlo board with Verdin SoM diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index d76ce4c3819d..2275e5d93721 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -58,6 +58,7 @@ properties: - items: - enum: - mediatek,mt6795-evb + - sony,xperia-m5 - const: mediatek,mt6795 - items: - enum: @@ -83,6 +84,7 @@ properties: - const: mediatek,mt7629 - items: - enum: + - bananapi,bpi-r3 - mediatek,mt7986a-rfb - const: mediatek,mt7986a - items: diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml index eb451bec23d3..0711f1834fbd 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml @@ -32,14 +32,26 @@ properties: - mediatek,mt8183-mmsys - mediatek,mt8186-mmsys - mediatek,mt8192-mmsys - - mediatek,mt8195-mmsys - mediatek,mt8365-mmsys - const: syscon + + - description: vdosys0 and vdosys1 are 2 display HW pipelines, + so mt8195 binding should be deprecated. + deprecated: true + items: + - const: mediatek,mt8195-mmsys + - const: syscon + - items: - const: mediatek,mt7623-mmsys - const: mediatek,mt2701-mmsys - const: syscon + - items: + - const: mediatek,mt8195-vdosys0 + - const: mediatek,mt8195-mmsys + - const: syscon + reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml index 5ea506412b4e..38efcad56dbd 100644 --- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml +++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml @@ -31,6 +31,7 @@ properties: - qcom,sm8250-llcc - qcom,sm8350-llcc - qcom,sm8450-llcc + - qcom,sm8550-llcc reg: items: diff --git a/Documentation/devicetree/bindings/arm/qcom-soc.yaml b/Documentation/devicetree/bindings/arm/qcom-soc.yaml new file mode 100644 index 000000000000..e333ec4a9c5f --- /dev/null +++ b/Documentation/devicetree/bindings/arm/qcom-soc.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/qcom-soc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SoC compatibles naming convention + +maintainers: + - Bjorn Andersson <andersson@kernel.org> + +description: | + Guidelines for new compatibles for SoC blocks/components. + When adding new compatibles in new bindings, use the format:: + qcom,SoC-IP + + For example:: + qcom,sdm845-llcc-bwmon + + When adding new compatibles to existing bindings, use the format in the + existing binding, even if it contradicts the above. + +select: + properties: + compatible: + pattern: "^qcom,.*(apq|ipq|mdm|msm|qcm|qcs|sa|sc|sdm|sdx|sm)[0-9]+.*$" + required: + - compatible + +properties: + compatible: + oneOf: + # Preferred naming style for compatibles of SoC components: + - pattern: "^qcom,(apq|ipq|mdm|msm|qcm|qcs|sa|sc|sdm|sdx|sm)[0-9]+-.*$" + - pattern: "^qcom,(sa|sc)8[0-9]+[a-z][a-z]?-.*$" + + # Legacy namings - variations of existing patterns/compatibles are OK, + # but do not add completely new entries to these: + - pattern: "^qcom,[ak]pss-wdt-(apq|ipq|mdm|msm|qcm|qcs|sa|sc|sdm|sdx|sm)[0-9]+.*$" + - pattern: "^qcom,gcc-(apq|ipq|mdm|msm|qcm|qcs|sa|sc|sdm|sdx|sm)[0-9]+.*$" + - pattern: "^qcom,mmcc-(apq|ipq|mdm|msm|qcm|qcs|sa|sc|sdm|sdx|sm)[0-9]+.*$" + - pattern: "^qcom,pcie-(apq|ipq|mdm|msm|qcm|qcs|sa|sc|sdm|sdx|sm)[0-9]+.*$" + - pattern: "^qcom,rpm-(apq|ipq|mdm|msm|qcm|qcs|sa|sc|sdm|sdx|sm)[0-9]+.*$" + - pattern: "^qcom,scm-(apq|ipq|mdm|msm|qcm|qcs|sa|sc|sdm|sdx|sm)[0-9]+.*$" + - enum: + - qcom,dsi-ctrl-6g-qcm2290 + - qcom,gpucc-sdm630 + - qcom,gpucc-sdm660 + - qcom,lcc-apq8064 + - qcom,lcc-ipq8064 + - qcom,lcc-mdm9615 + - qcom,lcc-msm8960 + - qcom,lpass-cpu-apq8016 + - qcom,usb-ss-ipq4019-phy + - qcom,usb-hs-ipq4019-phy + - qcom,vqmmc-ipq4019-regulator + + # Legacy compatibles with wild-cards - list cannot grow with new bindings: + - enum: + - qcom,ipq806x-gmac + - qcom,ipq806x-nand + - qcom,ipq806x-sata-phy + - qcom,ipq806x-usb-phy-ss + - qcom,ipq806x-usb-phy-hs + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 1b5ac6b02bc5..27063a045bd0 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -29,17 +29,22 @@ description: | apq8074 apq8084 apq8096 + ipq4018 ipq6018 ipq8074 mdm9615 msm8226 msm8916 + msm8956 msm8974 + msm8976 msm8992 msm8994 msm8996 msm8998 qcs404 + qdu1000 + qru1000 sa8155p sa8540p sc7180 @@ -51,11 +56,15 @@ description: | sdm632 sdm636 sdm660 + sdm670 sdm845 sdx55 sdx65 + sm4250 + sm6115 sm6125 sm6350 + sm6375 sm7225 sm8150 sm8250 @@ -76,6 +85,7 @@ description: | mtp qrd sbc + x100 The 'soc_version' and 'board_version' elements take the form of v<Major>.<Minor> where the minor number may be omitted when it's zero, i.e. v1.0 is the same @@ -114,7 +124,9 @@ properties: - items: - enum: - asus,sparrow + - huawei,sturgeon - lg,lenok + - samsung,matisse-wifi - const: qcom,apq8026 - items: @@ -150,20 +162,32 @@ properties: - items: - enum: + - sony,kugo-row + - sony,suzu-row + - const: qcom,msm8956 + + - items: + - enum: - qcom,msm8960-cdp - const: qcom,msm8960 - items: - enum: - - fairphone,fp2 - lge,hammerhead - - samsung,klte - sony,xperia-amami - - sony,xperia-castor - sony,xperia-honami - const: qcom,msm8974 - items: + - enum: + - fairphone,fp2 + - oneplus,bacon + - samsung,klte + - sony,xperia-castor + - const: qcom,msm8974pro + - const: qcom,msm8974 + + - items: - const: qcom,msm8916-mtp - const: qcom,msm8916-mtp/1 - const: qcom,msm8916 @@ -221,13 +245,20 @@ properties: - items: - enum: + - oneplus,oneplus3 + - oneplus,oneplus3t - qcom,msm8996-mtp - sony,dora-row - sony,kagura-row - sony,keyaki-row - xiaomi,gemini + - const: qcom,msm8996 + + - items: + - enum: - xiaomi,natrium - xiaomi,scorpio + - const: qcom,msm8996pro - const: qcom,msm8996 - items: @@ -242,10 +273,17 @@ properties: - sony,xperia-lilac - sony,xperia-maple - sony,xperia-poplar + - xiaomi,sagit - const: qcom,msm8998 - items: - enum: + - 8dev,jalapeno + - alfa-network,ap120c-ac + - const: qcom,ipq4018 + + - items: + - enum: - qcom,ipq4019-ap-dk01.1-c1 - qcom,ipq4019-ap-dk04.1-c3 - qcom,ipq4019-ap-dk07.1-c1 @@ -255,6 +293,7 @@ properties: - items: - enum: + - mikrotik,rb3011 - qcom,ipq8064-ap148 - const: qcom,ipq8064 @@ -265,6 +304,25 @@ properties: - qcom,ipq8074-hk10-c2 - const: qcom,ipq8074 + - description: Sierra Wireless MangOH Green with WP8548 Module + items: + - const: swir,mangoh-green-wp8548 + - const: swir,wp8548 + - const: qcom,mdm9615 + + - description: Qualcomm Technologies, Inc. Distributed Unit 1000 platform + items: + - enum: + - qcom,qdu1000-idp + - qcom,qdu1000-x100 + - const: qcom,qdu1000 + + - description: Qualcomm Technologies, Inc. Radio Unit 1000 platform + items: + - enum: + - qcom,qru1000-idp + - const: qcom,qru1000 + - description: Qualcomm Technologies, Inc. SC7180 IDP items: - enum: @@ -463,6 +521,17 @@ properties: - const: google,pazquel-sku2 - const: qcom,sc7180 + - description: Google Pazquel360 with LTE (newest rev) + items: + - const: google,pazquel-sku22 + - const: google,pazquel-sku20 + - const: qcom,sc7180 + + - description: Google Pazquel360 with WiFi (newest rev) + items: + - const: google,pazquel-sku21 + - const: qcom,sc7180 + - description: Sharp Dynabook Chromebook C1 (rev1) items: - const: google,pompom-rev1 @@ -575,6 +644,11 @@ properties: - const: google,evoker - const: qcom,sc7280 + - description: Google Evoker with LTE (newest rev) + items: + - const: google,evoker-sku512 + - const: qcom,sc7280 + - description: Google Herobrine (newest rev) items: - const: google,herobrine @@ -595,6 +669,16 @@ properties: - const: google,villager-sku512 - const: qcom,sc7280 + - description: Google Zombie (newest rev) + items: + - const: google,zombie + - const: qcom,sc7280 + + - description: Google Zombie with LTE (newest rev) + items: + - const: google,zombie-sku512 + - const: qcom,sc7280 + - items: - enum: - lenovo,flex-5g @@ -639,6 +723,11 @@ properties: - items: - enum: + - google,sargo + - const: qcom,sdm670 + + - items: + - enum: - qcom,sdx55-mtp - qcom,sdx55-telit-fn980-tlb - qcom,sdx55-t55 @@ -670,10 +759,14 @@ properties: - items: - enum: - qcom,sa8295p-adp + - qcom,sa8540p-ride - const: qcom,sa8540p - items: - enum: + - google,cheza + - google,cheza-rev1 + - google,cheza-rev2 - lenovo,yoga-c630 - lg,judyln - lg,judyp @@ -681,17 +774,24 @@ properties: - oneplus,fajita - qcom,sdm845-mtp - shift,axolotl + - samsung,starqltechn - samsung,w737 - sony,akari-row - sony,akatsuki-row - sony,apollo-row - thundercomm,db845c - xiaomi,beryllium + - xiaomi,beryllium-ebbg - xiaomi,polaris - const: qcom,sdm845 - items: - enum: + - oneplus,billie2 + - const: qcom,sm4250 + + - items: + - enum: - sony,pdx201 - const: qcom,sm6125 @@ -702,6 +802,11 @@ properties: - items: - enum: + - sony,pdx225 + - const: qcom,sm6375 + + - items: + - enum: - fairphone,fp4 - const: qcom,sm7225 @@ -737,8 +842,129 @@ properties: - qcom,sm8450-hdk - qcom,sm8450-qrd - sony,pdx223 + - sony,pdx224 - const: qcom,sm8450 + # Board compatibles go above + + qcom,msm-id: + $ref: /schemas/types.yaml#/definitions/uint32-matrix + minItems: 1 + maxItems: 8 + items: + items: + - description: | + MSM chipset ID - an exact match value consisting of two bitfields:: + - bits 0-15 - The unique MSM chipset ID + - bits 16-31 - Reserved; should be 0 + - description: | + Hardware revision ID - a chipset specific 32-bit ID representing + the version of the chipset. It is best a match value - the + bootloader will look for the closest possible match. + deprecated: true + description: + The MSM chipset and hardware revision used Qualcomm bootloaders. It + can optionally be an array of these to indicate multiple hardware that + use the same device tree. It is expected that the bootloader will use + this information at boot-up to decide which device tree to use when given + multiple device trees, some of which may not be compatible with the + actual hardware. It is the bootloader's responsibility to pass the + correct device tree to the kernel. + The property is deprecated. + + qcom,board-id: + $ref: /schemas/types.yaml#/definitions/uint32-matrix + minItems: 1 + maxItems: 8 + oneOf: + - items: + - items: + - description: | + Board ID consisting of three bitfields:: + - bits 31-24 - Unused + - bits 23-16 - Platform Version Major + - bits 15-8 - Platform Version Minor + - bits 7-0 - Platform Type + Platform Type field is an exact match value. The + Platform Major/Minor field is a best match. The bootloader will + look for the closest possible match. + - description: | + Subtype ID unique to a Platform Type/Chipset ID. For a given + Platform Type, there will typically only be a single board and the + subtype_id will be 0. However in some cases board variants may + need to be distinguished by different subtype_id values. + - items: + # OnePlus uses a variant of board-id with four elements: + - items: + - const: 8 + - const: 0 + - description: OnePlus board ID + - description: OnePlus subtype ID + deprecated: true + description: + The board type and revision information. It can optionally be an array + of these to indicate multiple boards that use the same device tree. It + is expected that the bootloader will use this information at boot-up to + decide which device tree to use when given multiple device trees, some of + which may not be compatible with the actual hardware. It is the + bootloader's responsibility to pass the correct device tree to the + kernel + The property is deprecated. + +allOf: + # Explicit allow-list for older SoCs. The legacy properties are not allowed + # on newer SoCs. + - if: + properties: + compatible: + contains: + enum: + - qcom,apq8026 + - qcom,apq8094 + - qcom,apq8096 + - qcom,msm8992 + - qcom,msm8994 + - qcom,msm8996 + - qcom,msm8998 + - qcom,sdm630 + - qcom,sdm632 + - qcom,sdm845 + - qcom,sdx55 + - qcom,sdx65 + - qcom,sm6125 + - qcom,sm6350 + - qcom,sm7225 + - qcom,sm8150 + - qcom,sm8250 + then: + properties: + qcom,board-id: true + qcom,msm-id: true + else: + properties: + qcom,board-id: false + qcom,msm-id: false + + - if: + properties: + compatible: + contains: + enum: + - oneplus,cheeseburger + - oneplus,dumpling + - oneplus,enchilada + - oneplus,fajita + then: + properties: + qcom,board-id: + items: + minItems: 4 + else: + properties: + qcom,board-id: + items: + maxItems: 2 + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index c6c69a4e3777..88ff4422a8c1 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -30,11 +30,26 @@ properties: - const: amarula,vyasa-rk3288 - const: rockchip,rk3288 + - description: Anbernic RG351M + items: + - const: anbernic,rg351m + - const: rockchip,rk3326 + - description: Anbernic RG353P items: - const: anbernic,rg353p - const: rockchip,rk3566 + - description: Anbernic RG353V + items: + - const: anbernic,rg353v + - const: rockchip,rk3566 + + - description: Anbernic RG353VS + items: + - const: anbernic,rg353vs + - const: rockchip,rk3566 + - description: Anbernic RG503 items: - const: anbernic,rg503 @@ -468,6 +483,21 @@ properties: - const: hardkernel,rk3326-odroid-go2 - const: rockchip,rk3326 + - description: Hardkernel Odroid Go Advance Black Edition + items: + - const: hardkernel,rk3326-odroid-go2-v11 + - const: rockchip,rk3326 + + - description: Hardkernel Odroid Go Super + items: + - const: hardkernel,rk3326-odroid-go3 + - const: rockchip,rk3326 + + - description: Hardkernel Odroid M1 + items: + - const: rockchip,rk3568-odroid-m1 + - const: rockchip,rk3568 + - description: Hugsun X99 TV Box items: - const: hugsun,x99 @@ -563,7 +593,9 @@ properties: - description: Pine64 SoQuartz SoM items: - enum: + - pine64,soquartz-blade - pine64,soquartz-cm4io + - pine64,soquartz-model-a - const: pine64,soquartz - const: rockchip,rk3566 @@ -709,6 +741,11 @@ properties: - const: rockchip,rv1108-evb - const: rockchip,rv1108 + - description: Theobroma Systems PX30-uQ7 with Haikou baseboard + items: + - const: tsd,px30-ringneck-haikou + - const: rockchip,px30 + - description: Theobroma Systems RK3368-uQ7 with Haikou baseboard items: - const: tsd,rk3368-lion-haikou @@ -729,6 +766,11 @@ properties: - const: zkmagic,a95x-z2 - const: rockchip,rk3318 + - description: Rockchip RK3566 BOX Evaluation Demo board + items: + - const: rockchip,rk3566-box-demo + - const: rockchip,rk3566 + - description: Rockchip RK3568 Evaluation board items: - const: rockchip,rk3568-evb1-v10 diff --git a/Documentation/devicetree/bindings/arm/socionext/uniphier.yaml b/Documentation/devicetree/bindings/arm/socionext/uniphier.yaml index 8c0e91658474..c2cea1c90f3c 100644 --- a/Documentation/devicetree/bindings/arm/socionext/uniphier.yaml +++ b/Documentation/devicetree/bindings/arm/socionext/uniphier.yaml @@ -26,6 +26,12 @@ properties: - socionext,uniphier-pro4-ref - socionext,uniphier-pro4-sanji - const: socionext,uniphier-pro4 + - description: Pro5 SoC boards + items: + - enum: + - socionext,uniphier-pro5-epcore + - socionext,uniphier-pro5-proex + - const: socionext,uniphier-pro5 - description: sLD8 SoC boards items: - enum: diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index 4c605bccc474..44f5c5855af8 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -59,6 +59,12 @@ properties: - prt,prtt1s # Protonic PRTT1S - const: st,stm32mp151 + - description: DH STM32MP151 DHCOR SoM based Boards + items: + - const: dh,stm32mp151a-dhcor-testbench + - const: dh,stm32mp151a-dhcor-som + - const: st,stm32mp151 + - description: DH STM32MP153 DHCOM SoM based Boards items: - const: dh,stm32mp153c-dhcom-drc02 diff --git a/Documentation/devicetree/bindings/arm/swir.txt b/Documentation/devicetree/bindings/arm/swir.txt deleted file mode 100644 index 042be73a95d3..000000000000 --- a/Documentation/devicetree/bindings/arm/swir.txt +++ /dev/null @@ -1,12 +0,0 @@ -Sierra Wireless Modules device tree bindings --------------------------------------------- - -Supported Modules : - - WP8548 : Includes MDM9615 and PM8018 in a module - -Sierra Wireless modules shall have the following properties : - Required root node property - - compatible: "swir,wp8548" for the WP8548 CF3 Module - -Board compatible values: - - "swir,mangoh-green-wp8548" for the mangOH green board with the WP8548 module diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml index 28b8232e1c5b..09e6845ff243 100644 --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml @@ -61,6 +61,7 @@ properties: - const: ti,j721e - items: - enum: + - beagle,j721e-beagleboneai64 - ti,j721e-evm - ti,j721e-sk - const: ti,j721e diff --git a/Documentation/devicetree/bindings/clock/fsl,imx8m-anatop.yaml b/Documentation/devicetree/bindings/clock/fsl,imx8m-anatop.yaml new file mode 100644 index 000000000000..bbd22e95b319 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/fsl,imx8m-anatop.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/fsl,imx8m-anatop.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8M Family Anatop Module + +maintainers: + - Peng Fan <peng.fan@nxp.com> + +description: | + NXP i.MX8M Family anatop PLL module which generates PLL to CCM root. + +properties: + compatible: + oneOf: + - enum: + - fsl,imx8mm-anatop + - fsl,imx8mq-anatop + - items: + - enum: + - fsl,imx8mn-anatop + - fsl,imx8mp-anatop + - const: fsl,imx8mm-anatop + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + anatop: clock-controller@30360000 { + compatible = "fsl,imx8mn-anatop", "fsl,imx8mm-anatop"; + reg = <0x30360000 0x10000>; + #clock-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt index 958e0ad78c52..f7d347385b57 100644 --- a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt @@ -136,7 +136,7 @@ clock@70110000 { }; /* pinmux nodes added for completeness. Binding doc can be found in: - * Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.txt + * Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml */ pinmux: pinmux@700008d4 { diff --git a/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml index 2ab4642679c0..55c4f94a14d1 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml @@ -148,7 +148,7 @@ allOf: items: - const: oscclk - const: dout_clkcmu_fsys1_bus - - const: dout_clkcmu_fsys1_mmc_card + - const: gout_clkcmu_fsys1_mmc_card - const: dout_clkcmu_fsys1_usbdrd - if: diff --git a/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml new file mode 100644 index 000000000000..76cb9726660e --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml @@ -0,0 +1,117 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/cpufreq/apple,cluster-cpufreq.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple SoC cluster cpufreq device + +maintainers: + - Hector Martin <marcan@marcan.st> + +description: | + Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of + the cluster management register block. This binding uses the standard + operating-points-v2 table to define the CPU performance states, with the + opp-level property specifying the hardware p-state index for that level. + +properties: + compatible: + oneOf: + - items: + - enum: + - apple,t8103-cluster-cpufreq + - apple,t8112-cluster-cpufreq + - const: apple,cluster-cpufreq + - items: + - const: apple,t6000-cluster-cpufreq + - const: apple,t8103-cluster-cpufreq + - const: apple,cluster-cpufreq + + reg: + maxItems: 1 + + '#performance-domain-cells': + const: 0 + +required: + - compatible + - reg + - '#performance-domain-cells' + +additionalProperties: false + +examples: + - | + // This example shows a single CPU per domain and 2 domains, + // with two p-states per domain. + // Shipping hardware has 2-4 CPUs per domain and 2-6 domains. + cpus { + #address-cells = <2>; + #size-cells = <0>; + + cpu@0 { + compatible = "apple,icestorm"; + device_type = "cpu"; + reg = <0x0 0x0>; + operating-points-v2 = <&ecluster_opp>; + performance-domains = <&cpufreq_e>; + }; + + cpu@10100 { + compatible = "apple,firestorm"; + device_type = "cpu"; + reg = <0x0 0x10100>; + operating-points-v2 = <&pcluster_opp>; + performance-domains = <&cpufreq_p>; + }; + }; + + ecluster_opp: opp-table-0 { + compatible = "operating-points-v2"; + opp-shared; + + opp01 { + opp-hz = /bits/ 64 <600000000>; + opp-level = <1>; + clock-latency-ns = <7500>; + }; + opp02 { + opp-hz = /bits/ 64 <972000000>; + opp-level = <2>; + clock-latency-ns = <22000>; + }; + }; + + pcluster_opp: opp-table-1 { + compatible = "operating-points-v2"; + opp-shared; + + opp01 { + opp-hz = /bits/ 64 <600000000>; + opp-level = <1>; + clock-latency-ns = <8000>; + }; + opp02 { + opp-hz = /bits/ 64 <828000000>; + opp-level = <2>; + clock-latency-ns = <19000>; + }; + }; + + soc { + #address-cells = <2>; + #size-cells = <2>; + + cpufreq_e: performance-controller@210e20000 { + compatible = "apple,t8103-cluster-cpufreq", "apple,cluster-cpufreq"; + reg = <0x2 0x10e20000 0 0x1000>; + #performance-domain-cells = <0>; + }; + + cpufreq_p: performance-controller@211e20000 { + compatible = "apple,t8103-cluster-cpufreq", "apple,cluster-cpufreq"; + reg = <0x2 0x11e20000 0 0x1000>; + #performance-domain-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/dma/apple,admac.yaml b/Documentation/devicetree/bindings/dma/apple,admac.yaml index 3b1e667f7ea0..97282469e4af 100644 --- a/Documentation/devicetree/bindings/dma/apple,admac.yaml +++ b/Documentation/devicetree/bindings/dma/apple,admac.yaml @@ -56,6 +56,9 @@ properties: power-domains: maxItems: 1 + resets: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml index c5b76c9f7ad0..25688571ee7c 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml @@ -41,12 +41,14 @@ properties: - qcom,scm-sc7180 - qcom,scm-sc7280 - qcom,scm-sc8280xp + - qcom,scm-sdm670 - qcom,scm-sdm845 - qcom,scm-sdx55 - qcom,scm-sdx65 - qcom,scm-sm6115 - qcom,scm-sm6125 - qcom,scm-sm6350 + - qcom,scm-sm6375 - qcom,scm-sm8150 - qcom,scm-sm8250 - qcom,scm-sm8350 @@ -88,6 +90,7 @@ allOf: - qcom,scm-apq8064 - qcom,scm-msm8660 - qcom,scm-msm8960 + - qcom,scm-sm6375 then: properties: clock-names: diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml new file mode 100644 index 000000000000..7cc2dd525a96 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml @@ -0,0 +1,156 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Device tree binding for NVIDIA Tegra234 NVDEC + +description: | + NVDEC is the hardware video decoder present on NVIDIA Tegra210 + and newer chips. It is located on the Host1x bus and typically + programmed through Host1x channels. + +maintainers: + - Thierry Reding <treding@gmail.com> + - Mikko Perttunen <mperttunen@nvidia.com> + +properties: + $nodename: + pattern: "^nvdec@[0-9a-f]*$" + + compatible: + enum: + - nvidia,tegra234-nvdec + + reg: + maxItems: 1 + + clocks: + maxItems: 3 + + clock-names: + items: + - const: nvdec + - const: fuse + - const: tsec_pka + + resets: + maxItems: 1 + + reset-names: + items: + - const: nvdec + + power-domains: + maxItems: 1 + + iommus: + maxItems: 1 + + dma-coherent: true + + interconnects: + items: + - description: DMA read memory client + - description: DMA write memory client + + interconnect-names: + items: + - const: dma-mem + - const: write + + nvidia,memory-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle to the memory controller for determining information for the NVDEC + firmware secure carveout. This carveout is configured by the bootloader and + not accessible to CPU. + + nvidia,bl-manifest-offset: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Offset to bootloader manifest from beginning of firmware that was configured by + the bootloader. + + nvidia,bl-code-offset: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Offset to bootloader code section from beginning of firmware that was configured by + the bootloader. + + nvidia,bl-data-offset: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Offset to bootloader data section from beginning of firmware that was configured by + the bootloader. + + nvidia,os-manifest-offset: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Offset to operating system manifest from beginning of firmware that was configured by + the bootloader. + + nvidia,os-code-offset: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Offset to operating system code section from beginning of firmware that was configured by + the bootloader. + + nvidia,os-data-offset: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Offset to operating system data section from beginning of firmware that was configured + by the bootloader. + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + - power-domains + - nvidia,memory-controller + - nvidia,bl-manifest-offset + - nvidia,bl-code-offset + - nvidia,bl-data-offset + - nvidia,os-manifest-offset + - nvidia,os-code-offset + - nvidia,os-data-offset + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra234-clock.h> + #include <dt-bindings/memory/tegra234-mc.h> + #include <dt-bindings/power/tegra234-powergate.h> + #include <dt-bindings/reset/tegra234-reset.h> + + nvdec@15480000 { + compatible = "nvidia,tegra234-nvdec"; + reg = <0x15480000 0x00040000>; + clocks = <&bpmp TEGRA234_CLK_NVDEC>, + <&bpmp TEGRA234_CLK_FUSE>, + <&bpmp TEGRA234_CLK_TSEC_PKA>; + clock-names = "nvdec", "fuse", "tsec_pka"; + resets = <&bpmp TEGRA234_RESET_NVDEC>; + reset-names = "nvdec"; + power-domains = <&bpmp TEGRA234_POWER_DOMAIN_NVDEC>; + interconnects = <&mc TEGRA234_MEMORY_CLIENT_NVDECSRD &emc>, + <&mc TEGRA234_MEMORY_CLIENT_NVDECSWR &emc>; + interconnect-names = "dma-mem", "write"; + iommus = <&smmu_niso1 TEGRA234_SID_NVDEC>; + dma-coherent; + + nvidia,memory-controller = <&mc>; + + /* Placeholder values, to be replaced with values from overlay */ + nvidia,bl-manifest-offset = <0>; + nvidia,bl-data-offset = <0>; + nvidia,bl-code-offset = <0>; + nvidia,os-manifest-offset = <0>; + nvidia,os-data-offset = <0>; + nvidia,os-code-offset = <0>; + }; diff --git a/Documentation/devicetree/bindings/hwinfo/loongson,ls2k-chipid.yaml b/Documentation/devicetree/bindings/hwinfo/loongson,ls2k-chipid.yaml new file mode 100644 index 000000000000..9d0c36ec1982 --- /dev/null +++ b/Documentation/devicetree/bindings/hwinfo/loongson,ls2k-chipid.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwinfo/loongson,ls2k-chipid.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson-2 SoC ChipID + +maintainers: + - Yinbo Zhu <zhuyinbo@loongson.cn> + +description: | + Loongson-2 SoC contains many groups of global utilities register + blocks, of which the ChipID group registers record SoC version, + feature, vendor and id information. + +properties: + compatible: + const: loongson,ls2k-chipid + + reg: + maxItems: 1 + + little-endian: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + chipid: chipid@1fe00000 { + compatible = "loongson,ls2k-chipid"; + reg = <0x1fe00000 0x3ffc>; + little-endian; + }; diff --git a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml index 1c7149f7d171..ee2726149cf3 100644 --- a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml +++ b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml @@ -15,9 +15,22 @@ description: properties: compatible: - enum: - - qcom,sfpb-mutex - - qcom,tcsr-mutex + oneOf: + - enum: + - qcom,sfpb-mutex + - qcom,tcsr-mutex + - items: + - enum: + - qcom,apq8084-tcsr-mutex + - qcom,ipq6018-tcsr-mutex + - qcom,msm8226-tcsr-mutex + - qcom,msm8994-tcsr-mutex + - const: qcom,tcsr-mutex + - items: + - enum: + - qcom,msm8974-tcsr-mutex + - const: qcom,tcsr-mutex + - const: syscon reg: maxItems: 1 @@ -34,9 +47,9 @@ additionalProperties: false examples: - | - tcsr_mutex: hwlock@1f40000 { - compatible = "qcom,tcsr-mutex"; - reg = <0x01f40000 0x40000>; - #hwlock-cells = <1>; - }; + hwlock@1f40000 { + compatible = "qcom,tcsr-mutex"; + reg = <0x01f40000 0x40000>; + #hwlock-cells = <1>; + }; ... diff --git a/Documentation/devicetree/bindings/iio/adc/aspeed,ast2600-adc.yaml b/Documentation/devicetree/bindings/iio/adc/aspeed,ast2600-adc.yaml index b283c8ca2bbf..5c08d8b6e995 100644 --- a/Documentation/devicetree/bindings/iio/adc/aspeed,ast2600-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/aspeed,ast2600-adc.yaml @@ -62,13 +62,6 @@ properties: description: Inform the driver that last channel will be used to sensor battery. - aspeed,trim-data-valid: - type: boolean - description: | - The ADC reference voltage can be calibrated to obtain the trimming - data which will be stored in otp. This property informs the driver that - the data store in the otp is valid. - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml index 8bac0c4120dd..e94beb2255ba 100644 --- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml @@ -238,42 +238,72 @@ additionalProperties: false examples: - | - spmi_bus { - #address-cells = <1>; - #size-cells = <0>; - /* VADC node */ - pmic_vadc: adc@3100 { - compatible = "qcom,spmi-vadc"; - reg = <0x3100>; - interrupts = <0x0 0x31 0x0 0x1>; + spmi { #address-cells = <1>; #size-cells = <0>; - #io-channel-cells = <1>; - - /* Channel node */ - adc-chan@39 { - reg = <0x39>; - qcom,decimation = <512>; - qcom,ratiometric; - qcom,hw-settle-time = <200>; - qcom,avg-samples = <1>; - qcom,pre-scaling = <1 3>; - }; - - adc-chan@9 { - reg = <0x9>; - }; - - adc-chan@a { - reg = <0xa>; + /* VADC node */ + pmic_vadc: adc@3100 { + compatible = "qcom,spmi-vadc"; + reg = <0x3100>; + interrupts = <0x0 0x31 0x0 0x1>; + #address-cells = <1>; + #size-cells = <0>; + #io-channel-cells = <1>; + + /* Channel node */ + adc-chan@39 { + reg = <0x39>; + qcom,decimation = <512>; + qcom,ratiometric; + qcom,hw-settle-time = <200>; + qcom,avg-samples = <1>; + qcom,pre-scaling = <1 3>; + }; + + adc-chan@9 { + reg = <0x9>; + }; + + adc-chan@a { + reg = <0xa>; + }; + + adc-chan@e { + reg = <0xe>; + }; + + adc-chan@f { + reg = <0xf>; + }; }; + }; - adc-chan@e { - reg = <0xe>; - }; + - | + #include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h> + #include <dt-bindings/iio/qcom,spmi-adc7-pm8350.h> + #include <dt-bindings/interrupt-controller/irq.h> - adc-chan@f { - reg = <0xf>; + spmi { + #address-cells = <1>; + #size-cells = <0>; + adc@3100 { + reg = <0x3100>; + compatible = "qcom,spmi-adc7"; + #address-cells = <1>; + #size-cells = <0>; + #io-channel-cells = <1>; + + /* Other properties are omitted */ + xo-therm@44 { + reg = <PMK8350_ADC7_AMUX_THM1_100K_PU>; + qcom,ratiometric; + qcom,hw-settle-time = <200>; + }; + + conn-therm@47 { + reg = <PM8350_ADC7_AMUX_THM4_100K_PU(1)>; + qcom,ratiometric; + qcom,hw-settle-time = <200>; + }; }; - }; }; diff --git a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml index fe1c5016f7f3..1c191bc5a178 100644 --- a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml +++ b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml @@ -16,8 +16,11 @@ description: properties: compatible: - items: + oneOf: - const: goodix,gt7375p + - items: + - const: goodix,gt7986u + - const: goodix,gt7375p reg: enum: diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml index 2684562df4d9..be29e0b80995 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml @@ -24,7 +24,7 @@ properties: oneOf: - items: - enum: - - qcom,sc7280-bwmon + - qcom,sc7280-cpu-bwmon - qcom,sdm845-bwmon - const: qcom,msm8998-bwmon - const: qcom,msm8998-bwmon # BWMON v4 diff --git a/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml b/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml index 47a78a167aba..06948c0e36a5 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml @@ -69,6 +69,35 @@ properties: power-domains: maxItems: 1 + affinities: + type: object + additionalProperties: false + description: + FIQ affinity can be expressed as a single "affinities" node, + containing a set of sub-nodes, one per FIQ with a non-default + affinity. + patternProperties: + "^.+-affinity$": + type: object + additionalProperties: false + properties: + apple,fiq-index: + description: + The interrupt number specified as a FIQ, and for which + the affinity is not the default. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 5 + + cpus: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Should be a list of phandles to CPU nodes (as described in + Documentation/devicetree/bindings/arm/cpus.yaml). + + required: + - apple,fiq-index + - cpus + required: - compatible - '#interrupt-cells' diff --git a/Documentation/devicetree/bindings/iommu/apple,dart.yaml b/Documentation/devicetree/bindings/iommu/apple,dart.yaml index 82ad669feef7..06af2bacbe97 100644 --- a/Documentation/devicetree/bindings/iommu/apple,dart.yaml +++ b/Documentation/devicetree/bindings/iommu/apple,dart.yaml @@ -22,7 +22,9 @@ description: |+ properties: compatible: - const: apple,t8103-dart + enum: + - apple,t8103-dart + - apple,t6000-dart reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml index 704033e21ee8..53945c61325c 100644 --- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml +++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml @@ -21,6 +21,7 @@ properties: - const: allwinner,sun6i-a31-ir - items: - enum: + - allwinner,suniv-f1c100s-ir - allwinner,sun8i-a83t-ir - allwinner,sun8i-r40-ir - allwinner,sun50i-a64-ir diff --git a/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml b/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml index 24d7bf21499e..9d44236f2deb 100644 --- a/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml +++ b/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml @@ -36,6 +36,9 @@ properties: resets: maxItems: 1 + iommus: + maxItems: 1 + required: - compatible - reg @@ -43,6 +46,7 @@ required: - clocks - clock-names - resets + - iommus additionalProperties: false @@ -59,6 +63,7 @@ examples: clocks = <&ccu CLK_BUS_VP9>, <&ccu CLK_VP9>; clock-names = "bus", "mod"; resets = <&ccu RST_BUS_VP9>; + iommus = <&iommu 5>; }; ... diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.txt b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.txt deleted file mode 100644 index b88dcdd41def..000000000000 --- a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.txt +++ /dev/null @@ -1,9 +0,0 @@ -Dongwoon Anatech DW9714 camera voice coil lens driver - -DW9174 is a 10-bit DAC with current sink capability. It is intended -for driving voice coil lenses in camera modules. - -Mandatory properties: - -- compatible: "dongwoon,dw9714" -- reg: I²C slave address diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.yaml b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.yaml new file mode 100644 index 000000000000..66229a3dc05d --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/dongwoon,dw9714.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Dongwoon Anatech DW9714 camera voice coil lens driver + +maintainers: + - Krzysztof Kozlowski <krzk@kernel.org> + +description: + DW9174 is a 10-bit DAC with current sink capability. It is intended for + driving voice coil lenses in camera modules. + +properties: + compatible: + const: dongwoon,dw9714 + + reg: + maxItems: 1 + + powerdown-gpios: + description: + XSD pin for shutdown (active low) + + vcc-supply: + description: VDD power supply + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + camera-lens@c { + compatible = "dongwoon,dw9714"; + reg = <0x0c>; + vcc-supply = <®_csi_1v8>; + }; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml b/Documentation/devicetree/bindings/memory-controllers/arm,pl35x-smc.yaml index 01c9acf9275d..bd23257fe021 100644 --- a/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/arm,pl35x-smc.yaml @@ -1,26 +1,31 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/memory-controllers/arm,pl353-smc.yaml# +$id: http://devicetree.org/schemas/memory-controllers/arm,pl35x-smc.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: ARM PL353 Static Memory Controller (SMC) device-tree bindings +title: Arm PL35x Series Static Memory Controller (SMC) maintainers: - Miquel Raynal <miquel.raynal@bootlin.com> - Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> -description: - The PL353 Static Memory Controller is a bus where you can connect two kinds +description: | + The PL35x Static Memory Controller is a bus where you can connect two kinds of memory interfaces, which are NAND and memory mapped interfaces (such as - SRAM or NOR). + SRAM or NOR) depending on the specific configuration. + + The TRM is available here: + https://documentation-service.arm.com/static/5e8e2524fd977155116a58aa # We need a select here so we don't match all nodes with 'arm,primecell' select: properties: compatible: contains: - const: arm,pl353-smc-r2p1 + enum: + - arm,pl353-smc-r2p1 + - arm,pl354 required: - compatible @@ -30,7 +35,9 @@ properties: compatible: items: - - const: arm,pl353-smc-r2p1 + - enum: + - arm,pl353-smc-r2p1 + - arm,pl354 - const: arm,primecell "#address-cells": @@ -46,30 +53,25 @@ properties: The three chip select regions are defined in 'ranges'. clocks: - items: - - description: clock for the memory device bus - - description: main clock of the SMC + minItems: 1 + maxItems: 2 clock-names: - items: - - const: memclk - - const: apb_pclk + minItems: 1 + maxItems: 2 ranges: minItems: 1 - description: | - Memory bus areas for interacting with the devices. Reflects - the memory layout with four integer values following: - <cs-number> 0 <offset> <size> - items: - - description: NAND bank 0 - - description: NOR/SRAM bank 0 - - description: NOR/SRAM bank 1 + maxItems: 8 - interrupts: true + interrupts: + minItems: 1 + items: + - description: Combined or Memory interface 0 IRQ + - description: Memory interface 1 IRQ patternProperties: - "@[0-3],[a-f0-9]+$": + "@[0-7],[a-f0-9]+$": type: object description: | The child device node represents the controller connected to the SMC @@ -87,7 +89,7 @@ patternProperties: - description: | Chip-select ID, as in the parent range property. minimum: 0 - maximum: 2 + maximum: 7 - description: | Offset of the memory region requested by the device. - description: | @@ -102,12 +104,36 @@ required: - reg - clock-names - clocks - - "#address-cells" - - "#size-cells" - - ranges additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + const: arm,pl354 + then: + properties: + clocks: + # According to TRM, really should be 3 clocks + maxItems: 1 + + clock-names: + const: apb_pclk + + else: + properties: + clocks: + items: + - description: clock for the memory device bus + - description: main clock of the SMC + + clock-names: + items: + - const: memclk + - const: apb_pclk + examples: - | smcc: memory-controller@e000e000 { diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml new file mode 100644 index 000000000000..34b5bd153f63 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml @@ -0,0 +1,146 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr-channel.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LPDDR channel with chip/rank topology description + +description: + An LPDDR channel is a completely independent set of LPDDR pins (DQ, CA, CS, + CK, etc.) that connect one or more LPDDR chips to a host system. The main + purpose of this node is to overall LPDDR topology of the system, including the + amount of individual LPDDR chips and the ranks per chip. + +maintainers: + - Julius Werner <jwerner@chromium.org> + +properties: + compatible: + enum: + - jedec,lpddr2-channel + - jedec,lpddr3-channel + - jedec,lpddr4-channel + - jedec,lpddr5-channel + + io-width: + description: + The number of DQ pins in the channel. If this number is different + from (a multiple of) the io-width of the LPDDR chip, that means that + multiple instances of that type of chip are wired in parallel on this + channel (with the channel's DQ pins split up between the different + chips, and the CA, CS, etc. pins of the different chips all shorted + together). This means that the total physical memory controlled by a + channel is equal to the sum of the densities of each rank on the + connected LPDDR chip, times the io-width of the channel divided by + the io-width of the LPDDR chip. + enum: + - 8 + - 16 + - 32 + - 64 + - 128 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^rank@[0-9]+$": + type: object + description: + Each physical LPDDR chip may have one or more ranks. Ranks are + internal but fully independent sub-units of the chip. Each LPDDR bus + transaction on the channel targets exactly one rank, based on the + state of the CS pins. Different ranks may have different densities and + timing requirements. + required: + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: jedec,lpddr2-channel + then: + patternProperties: + "^rank@[0-9]+$": + $ref: /schemas/memory-controllers/ddr/jedec,lpddr2.yaml# + - if: + properties: + compatible: + contains: + const: jedec,lpddr3-channel + then: + patternProperties: + "^rank@[0-9]+$": + $ref: /schemas/memory-controllers/ddr/jedec,lpddr3.yaml# + - if: + properties: + compatible: + contains: + const: jedec,lpddr4-channel + then: + patternProperties: + "^rank@[0-9]+$": + $ref: /schemas/memory-controllers/ddr/jedec,lpddr4.yaml# + - if: + properties: + compatible: + contains: + const: jedec,lpddr5-channel + then: + patternProperties: + "^rank@[0-9]+$": + $ref: /schemas/memory-controllers/ddr/jedec,lpddr5.yaml# + +required: + - compatible + - io-width + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + lpddr-channel0 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "jedec,lpddr3-channel"; + io-width = <32>; + + rank@0 { + compatible = "lpddr3-ff,0100", "jedec,lpddr3"; + reg = <0>; + density = <8192>; + io-width = <16>; + revision-id = <1 0>; + }; + }; + + lpddr-channel1 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "jedec,lpddr4-channel"; + io-width = <32>; + + rank@0 { + compatible = "lpddr4-05,0301", "jedec,lpddr4"; + reg = <0>; + density = <4096>; + io-width = <32>; + revision-id = <3 1>; + }; + + rank@1 { + compatible = "lpddr4-05,0301", "jedec,lpddr4"; + reg = <1>; + density = <2048>; + io-width = <32>; + revision-id = <3 1>; + }; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml new file mode 100644 index 000000000000..30267ce70124 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr-props.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common properties for LPDDR types + +description: + Different LPDDR types generally use the same properties and only differ in the + range of legal values for each. This file defines the common parts that can be + reused for each type. Nodes using this schema should generally be nested under + an LPDDR channel node. + +maintainers: + - Krzysztof Kozlowski <krzk@kernel.org> + +properties: + compatible: + description: + Compatible strings can be either explicit vendor names and part numbers + (e.g. elpida,ECB240ABACN), or generated strings of the form + lpddrX-YY,ZZZZ where X is the LPDDR version, YY is the manufacturer ID + (from MR5) and ZZZZ is the revision ID (from MR6 and MR7). Both IDs are + formatted in lower case hexadecimal representation with leading zeroes. + The latter form can be useful when LPDDR nodes are created at runtime by + boot firmware that doesn't have access to static part number information. + + reg: + description: + The rank number of this LPDDR rank when used as a subnode to an LPDDR + channel. + minimum: 0 + maximum: 3 + + revision-id: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + Revision IDs read from Mode Register 6 and 7. One byte per uint32 cell (i.e. <MR6 MR7>). + maxItems: 2 + items: + minimum: 0 + maximum: 255 + + density: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Density in megabits of SDRAM chip. Decoded from Mode Register 8. + enum: + - 64 + - 128 + - 256 + - 512 + - 1024 + - 2048 + - 3072 + - 4096 + - 6144 + - 8192 + - 12288 + - 16384 + - 24576 + - 32768 + + io-width: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + IO bus width in bits of SDRAM chip. Decoded from Mode Register 8. + enum: + - 8 + - 16 + - 32 + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml index 9d78f140609b..a237bc259273 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml @@ -9,6 +9,9 @@ title: LPDDR2 SDRAM compliant to JEDEC JESD209-2 maintainers: - Krzysztof Kozlowski <krzk@kernel.org> +allOf: + - $ref: jedec,lpddr-props.yaml# + properties: compatible: oneOf: @@ -17,13 +20,15 @@ properties: - elpida,ECB240ABACN - elpida,B8132B2PB-6D-F - enum: - - jedec,lpddr2-s4 - - items: - - enum: + - jedec,lpddr2-nvm - jedec,lpddr2-s2 + - jedec,lpddr2-s4 - items: + - pattern: "^lpddr2-[0-9a-f]{2},[0-9a-f]{4}$" - enum: - jedec,lpddr2-nvm + - jedec,lpddr2-s2 + - jedec,lpddr2-s4 revision-id1: $ref: /schemas/types.yaml#/definitions/uint32 @@ -41,41 +46,6 @@ properties: Property is deprecated, use revision-id instead. deprecated: true - revision-id: - $ref: /schemas/types.yaml#/definitions/uint32-array - description: | - Revision IDs read from Mode Register 6 and 7. One byte per uint32 cell (i.e. <MR6 MR7>). - minItems: 2 - maxItems: 2 - items: - minimum: 0 - maximum: 255 - - density: - $ref: /schemas/types.yaml#/definitions/uint32 - description: | - Density in megabits of SDRAM chip. Obtained from device datasheet. - enum: - - 64 - - 128 - - 256 - - 512 - - 1024 - - 2048 - - 4096 - - 8192 - - 16384 - - 32768 - - io-width: - $ref: /schemas/types.yaml#/definitions/uint32 - description: | - IO bus width in bits of SDRAM chip. Obtained from device datasheet. - enum: - - 32 - - 16 - - 8 - tRRD-min-tck: $ref: /schemas/types.yaml#/definitions/uint32 maximum: 16 @@ -168,7 +138,7 @@ required: - density - io-width -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml index 48908a19473c..e328a1195ba6 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml @@ -9,35 +9,24 @@ title: LPDDR3 SDRAM compliant to JEDEC JESD209-3 maintainers: - Krzysztof Kozlowski <krzk@kernel.org> +allOf: + - $ref: jedec,lpddr-props.yaml# + properties: compatible: - items: - - enum: - - samsung,K3QF2F20DB - - const: jedec,lpddr3 + oneOf: + - items: + - enum: + - samsung,K3QF2F20DB + - const: jedec,lpddr3 + - items: + - pattern: "^lpddr3-[0-9a-f]{2},[0-9a-f]{4}$" + - const: jedec,lpddr3 '#address-cells': const: 1 deprecated: true - density: - $ref: /schemas/types.yaml#/definitions/uint32 - description: | - Density in megabits of SDRAM chip. - enum: - - 4096 - - 8192 - - 16384 - - 32768 - - io-width: - $ref: /schemas/types.yaml#/definitions/uint32 - description: | - IO bus width in bits of SDRAM chip. - enum: - - 32 - - 16 - manufacturer-id: $ref: /schemas/types.yaml#/definitions/uint32 description: | @@ -45,15 +34,6 @@ properties: deprecated, manufacturer should be derived from the compatible. deprecated: true - revision-id: - $ref: /schemas/types.yaml#/definitions/uint32-array - minItems: 2 - maxItems: 2 - items: - maximum: 255 - description: | - Revision value of SDRAM chip read from Mode Registers 6 and 7. - '#size-cells': const: 0 deprecated: true @@ -206,7 +186,7 @@ required: - density - io-width -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr4.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr4.yaml new file mode 100644 index 000000000000..a078892fecee --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr4.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr4.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LPDDR4 SDRAM compliant to JEDEC JESD209-4 + +maintainers: + - Krzysztof Kozlowski <krzk@kernel.org> + +allOf: + - $ref: jedec,lpddr-props.yaml# + +properties: + compatible: + items: + - pattern: "^lpddr4-[0-9a-f]{2},[0-9a-f]{4}$" + - const: jedec,lpddr4 + +required: + - compatible + - density + - io-width + +unevaluatedProperties: false + +examples: + - | + lpddr { + compatible = "lpddr4-ff,0100", "jedec,lpddr4"; + density = <8192>; + io-width = <16>; + revision-id = <1 0>; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr5.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr5.yaml new file mode 100644 index 000000000000..e441dac5f154 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr5.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr5.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LPDDR5 SDRAM compliant to JEDEC JESD209-5 + +maintainers: + - Krzysztof Kozlowski <krzk@kernel.org> + +allOf: + - $ref: jedec,lpddr-props.yaml# + +properties: + compatible: + items: + - pattern: "^lpddr5-[0-9a-f]{2},[0-9a-f]{4}$" + - const: jedec,lpddr5 + + serial-id: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + Serial IDs read from Mode Registers 47 through 54. One byte per uint32 + cell (i.e. <MR47 MR48 MR49 MR50 MR51 MR52 MR53 MR54>). + maxItems: 8 + items: + minimum: 0 + maximum: 255 + +required: + - compatible + - density + - io-width + +unevaluatedProperties: false + +examples: + - | + lpddr { + compatible = "lpddr5-01,0200", "jedec,lpddr5"; + density = <8192>; + io-width = <8>; + revision-id = <2 0>; + serial-id = <3 1 0 0 0 0 0 0>; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml b/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml new file mode 100644 index 000000000000..53ae995462db --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/mc-peripheral-props.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Peripheral-specific properties for a Memory Controller bus. + +description: + Many Memory Controllers need to add properties to peripheral devices. + They could be common properties like reg or they could be controller + specific like delay in clock or data lines, etc. These properties need + to be defined in the peripheral node because they are per-peripheral + and there can be multiple peripherals attached to a controller. All + those properties are listed here. The controller specific properties + should go in their own separate schema that should be referenced + from here. + +maintainers: + - Marek Vasut <marex@denx.de> + +properties: + reg: + description: Bank number, base address and size of the device. + + bank-width: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Bank width of the device, in bytes. + enum: [1, 2, 4] + +required: + - reg + +# The controller specific properties go here. +allOf: + - $ref: st,stm32-fmc2-ebi-props.yaml# + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml index 645249ea21d1..30a403b1b79a 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml @@ -44,6 +44,11 @@ properties: - items: - enum: + - renesas,r8a779g0-rpc-if # R-Car V4H + - const: renesas,rcar-gen4-rpc-if # a generic R-Car gen4 device + + - items: + - enum: - renesas,r9a07g043-rpc-if # RZ/G2UL - renesas,r9a07g044-rpc-if # RZ/G2{L,LC} - renesas,r9a07g054-rpc-if # RZ/V2L diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi-props.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi-props.yaml new file mode 100644 index 000000000000..475e4095068c --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi-props.yaml @@ -0,0 +1,144 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/st,stm32-fmc2-ebi-props.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Peripheral properties for ST FMC2 Controller + +maintainers: + - Christophe Kerello <christophe.kerello@foss.st.com> + - Marek Vasut <marex@denx.de> + +properties: + st,fmc2-ebi-cs-transaction-type: + description: | + Select one of the transactions type supported + 0: Asynchronous mode 1 SRAM/FRAM. + 1: Asynchronous mode 1 PSRAM. + 2: Asynchronous mode A SRAM/FRAM. + 3: Asynchronous mode A PSRAM. + 4: Asynchronous mode 2 NOR. + 5: Asynchronous mode B NOR. + 6: Asynchronous mode C NOR. + 7: Asynchronous mode D NOR. + 8: Synchronous read synchronous write PSRAM. + 9: Synchronous read asynchronous write PSRAM. + 10: Synchronous read synchronous write NOR. + 11: Synchronous read asynchronous write NOR. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 11 + + st,fmc2-ebi-cs-cclk-enable: + description: Continuous clock enable (first bank must be configured + in synchronous mode). The FMC_CLK is generated continuously + during asynchronous and synchronous access. By default, the + FMC_CLK is only generated during synchronous access. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-mux-enable: + description: Address/Data multiplexed on databus (valid only with + NOR and PSRAM transactions type). By default, Address/Data + are not multiplexed. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-buswidth: + description: Data bus width + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 8, 16 ] + default: 16 + + st,fmc2-ebi-cs-waitpol-high: + description: Wait signal polarity (NWAIT signal active high). + By default, NWAIT is active low. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-waitcfg-enable: + description: The NWAIT signal indicates wheither the data from the + device are valid or if a wait state must be inserted when accessing + the device in synchronous mode. By default, the NWAIT signal is + active one data cycle before wait state. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-wait-enable: + description: The NWAIT signal is enabled (its level is taken into + account after the programmed latency period to insert wait states + if asserted). By default, the NWAIT signal is disabled. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-asyncwait-enable: + description: The NWAIT signal is taken into account during asynchronous + transactions. By default, the NWAIT signal is not taken into account + during asynchronous transactions. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-cpsize: + description: CRAM page size. The controller splits the burst access + when the memory page is reached. By default, no burst split when + crossing page boundary. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 128, 256, 512, 1024 ] + default: 0 + + st,fmc2-ebi-cs-byte-lane-setup-ns: + description: This property configures the byte lane setup timing + defined in nanoseconds from NBLx low to Chip Select NEx low. + + st,fmc2-ebi-cs-address-setup-ns: + description: This property defines the duration of the address setup + phase in nanoseconds used for asynchronous read/write transactions. + + st,fmc2-ebi-cs-address-hold-ns: + description: This property defines the duration of the address hold + phase in nanoseconds used for asynchronous multiplexed read/write + transactions. + + st,fmc2-ebi-cs-data-setup-ns: + description: This property defines the duration of the data setup phase + in nanoseconds used for asynchronous read/write transactions. + + st,fmc2-ebi-cs-bus-turnaround-ns: + description: This property defines the delay in nanoseconds between the + end of current read/write transaction and the next transaction. + + st,fmc2-ebi-cs-data-hold-ns: + description: This property defines the duration of the data hold phase + in nanoseconds used for asynchronous read/write transactions. + + st,fmc2-ebi-cs-clk-period-ns: + description: This property defines the FMC_CLK output signal period in + nanoseconds. + + st,fmc2-ebi-cs-data-latency-ns: + description: This property defines the data latency before reading or + writing the first data in nanoseconds. + + st,fmc2-ebi-cs-write-address-setup-ns: + description: This property defines the duration of the address setup + phase in nanoseconds used for asynchronous write transactions. + + st,fmc2-ebi-cs-write-address-hold-ns: + description: This property defines the duration of the address hold + phase in nanoseconds used for asynchronous multiplexed write + transactions. + + st,fmc2-ebi-cs-write-data-setup-ns: + description: This property defines the duration of the data setup + phase in nanoseconds used for asynchronous write transactions. + + st,fmc2-ebi-cs-write-bus-turnaround-ns: + description: This property defines the delay between the end of current + write transaction and the next transaction in nanoseconds. + + st,fmc2-ebi-cs-write-data-hold-ns: + description: This property defines the duration of the data hold phase + in nanoseconds used for asynchronous write transactions. + + st,fmc2-ebi-cs-max-low-pulse-ns: + description: This property defines the maximum chip select low pulse + duration in nanoseconds for synchronous transactions. When this timing + reaches 0, the controller splits the current access, toggles NE to + allow device refresh and restarts a new access. + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml index 6b516d3895af..d71af02b7f16 100644 --- a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml @@ -48,143 +48,7 @@ properties: patternProperties: "^.*@[0-4],[a-f0-9]+$": type: object - - properties: - reg: - description: Bank number, base address and size of the device. - - st,fmc2-ebi-cs-transaction-type: - description: | - Select one of the transactions type supported - 0: Asynchronous mode 1 SRAM/FRAM. - 1: Asynchronous mode 1 PSRAM. - 2: Asynchronous mode A SRAM/FRAM. - 3: Asynchronous mode A PSRAM. - 4: Asynchronous mode 2 NOR. - 5: Asynchronous mode B NOR. - 6: Asynchronous mode C NOR. - 7: Asynchronous mode D NOR. - 8: Synchronous read synchronous write PSRAM. - 9: Synchronous read asynchronous write PSRAM. - 10: Synchronous read synchronous write NOR. - 11: Synchronous read asynchronous write NOR. - $ref: /schemas/types.yaml#/definitions/uint32 - minimum: 0 - maximum: 11 - - st,fmc2-ebi-cs-cclk-enable: - description: Continuous clock enable (first bank must be configured - in synchronous mode). The FMC_CLK is generated continuously - during asynchronous and synchronous access. By default, the - FMC_CLK is only generated during synchronous access. - $ref: /schemas/types.yaml#/definitions/flag - - st,fmc2-ebi-cs-mux-enable: - description: Address/Data multiplexed on databus (valid only with - NOR and PSRAM transactions type). By default, Address/Data - are not multiplexed. - $ref: /schemas/types.yaml#/definitions/flag - - st,fmc2-ebi-cs-buswidth: - description: Data bus width - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [ 8, 16 ] - default: 16 - - st,fmc2-ebi-cs-waitpol-high: - description: Wait signal polarity (NWAIT signal active high). - By default, NWAIT is active low. - $ref: /schemas/types.yaml#/definitions/flag - - st,fmc2-ebi-cs-waitcfg-enable: - description: The NWAIT signal indicates wheither the data from the - device are valid or if a wait state must be inserted when accessing - the device in synchronous mode. By default, the NWAIT signal is - active one data cycle before wait state. - $ref: /schemas/types.yaml#/definitions/flag - - st,fmc2-ebi-cs-wait-enable: - description: The NWAIT signal is enabled (its level is taken into - account after the programmed latency period to insert wait states - if asserted). By default, the NWAIT signal is disabled. - $ref: /schemas/types.yaml#/definitions/flag - - st,fmc2-ebi-cs-asyncwait-enable: - description: The NWAIT signal is taken into account during asynchronous - transactions. By default, the NWAIT signal is not taken into account - during asynchronous transactions. - $ref: /schemas/types.yaml#/definitions/flag - - st,fmc2-ebi-cs-cpsize: - description: CRAM page size. The controller splits the burst access - when the memory page is reached. By default, no burst split when - crossing page boundary. - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [ 0, 128, 256, 512, 1024 ] - default: 0 - - st,fmc2-ebi-cs-byte-lane-setup-ns: - description: This property configures the byte lane setup timing - defined in nanoseconds from NBLx low to Chip Select NEx low. - - st,fmc2-ebi-cs-address-setup-ns: - description: This property defines the duration of the address setup - phase in nanoseconds used for asynchronous read/write transactions. - - st,fmc2-ebi-cs-address-hold-ns: - description: This property defines the duration of the address hold - phase in nanoseconds used for asynchronous multiplexed read/write - transactions. - - st,fmc2-ebi-cs-data-setup-ns: - description: This property defines the duration of the data setup phase - in nanoseconds used for asynchronous read/write transactions. - - st,fmc2-ebi-cs-bus-turnaround-ns: - description: This property defines the delay in nanoseconds between the - end of current read/write transaction and the next transaction. - - st,fmc2-ebi-cs-data-hold-ns: - description: This property defines the duration of the data hold phase - in nanoseconds used for asynchronous read/write transactions. - - st,fmc2-ebi-cs-clk-period-ns: - description: This property defines the FMC_CLK output signal period in - nanoseconds. - - st,fmc2-ebi-cs-data-latency-ns: - description: This property defines the data latency before reading or - writing the first data in nanoseconds. - - st,fmc2_ebi-cs-write-address-setup-ns: - description: This property defines the duration of the address setup - phase in nanoseconds used for asynchronous write transactions. - - st,fmc2-ebi-cs-write-address-hold-ns: - description: This property defines the duration of the address hold - phase in nanoseconds used for asynchronous multiplexed write - transactions. - - st,fmc2-ebi-cs-write-data-setup-ns: - description: This property defines the duration of the data setup - phase in nanoseconds used for asynchronous write transactions. - - st,fmc2-ebi-cs-write-bus-turnaround-ns: - description: This property defines the delay between the end of current - write transaction and the next transaction in nanoseconds. - - st,fmc2-ebi-cs-write-data-hold-ns: - description: This property defines the duration of the data hold phase - in nanoseconds used for asynchronous write transactions. - - st,fmc2-ebi-cs-max-low-pulse-ns: - description: This property defines the maximum chip select low pulse - duration in nanoseconds for synchronous transactions. When this timing - reaches 0, the controller splits the current access, toggles NE to - allow device refresh and restarts a new access. - - required: - - reg + $ref: mc-peripheral-props.yaml# required: - "#address-cells" diff --git a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc-child.yaml b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc-child.yaml index 6e3995bb1630..4a257fac577e 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc-child.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc-child.yaml @@ -230,6 +230,13 @@ properties: Wait-pin used by client. Must be less than "gpmc,num-waitpins". $ref: /schemas/types.yaml#/definitions/uint32 + ti,wait-pin-polarity: + description: | + Set the desired polarity for the selected wait pin. + 0 for active low, 1 for active high. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + gpmc,wait-on-read: description: Enables wait monitoring on reads. type: boolean diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml index 6a3e3ede1ede..a5edab6f2e40 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml @@ -33,6 +33,7 @@ properties: compatible: items: - enum: + - qcom,pm6125 - qcom,pm6150 - qcom,pm6150l - qcom,pm6350 diff --git a/Documentation/devicetree/bindings/net/engleder,tsnep.yaml b/Documentation/devicetree/bindings/net/engleder,tsnep.yaml index 5bd964a46a9d..a6921e805e37 100644 --- a/Documentation/devicetree/bindings/net/engleder,tsnep.yaml +++ b/Documentation/devicetree/bindings/net/engleder,tsnep.yaml @@ -47,7 +47,7 @@ properties: nvmem-cells: true - nvmem-cells-names: true + nvmem-cell-names: true phy-connection-type: enum: diff --git a/Documentation/devicetree/bindings/net/micrel,ks8851.yaml b/Documentation/devicetree/bindings/net/micrel,ks8851.yaml index 5aa7cf2eacb1..b44d83554ef5 100644 --- a/Documentation/devicetree/bindings/net/micrel,ks8851.yaml +++ b/Documentation/devicetree/bindings/net/micrel,ks8851.yaml @@ -44,6 +44,7 @@ required: allOf: - $ref: ethernet-controller.yaml# + - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml index 64995cbb0f97..41c9760227cd 100644 --- a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml +++ b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml @@ -8,7 +8,6 @@ title: Samsung S3FWRN5 NCI NFC Controller maintainers: - Krzysztof Kozlowski <krzk@kernel.org> - - Krzysztof Opasiak <k.opasiak@samsung.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.yaml b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.yaml index e374aa7891ae..ec20e33d9b8f 100644 --- a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.yaml +++ b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.yaml @@ -11,14 +11,18 @@ maintainers: properties: compatible: - enum: - - fsl,imx6q-snvs-lpgpr - - fsl,imx6ul-snvs-lpgpr - - fsl,imx7d-snvs-lpgpr - - fsl,imx8mm-snvs-lpgpr - - fsl,imx8mn-snvs-lpgpr - - fsl,imx8mp-snvs-lpgpr - - fsl,imx8mq-snvs-lpgpr + oneOf: + - items: + - enum: + - fsl,imx8mm-snvs-lpgpr + - fsl,imx8mn-snvs-lpgpr + - fsl,imx8mp-snvs-lpgpr + - fsl,imx8mq-snvs-lpgpr + - const: fsl,imx7d-snvs-lpgpr + - enum: + - fsl,imx6q-snvs-lpgpr + - fsl,imx6ul-snvs-lpgpr + - fsl,imx7d-snvs-lpgpr required: - compatible diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.yaml index 75da3e8eecb9..fe81d52c7277 100644 --- a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.yaml @@ -27,6 +27,7 @@ properties: - nvidia,tegra234-pcie reg: + minItems: 4 items: - description: controller's application logic registers - description: configuration registers @@ -35,13 +36,16 @@ properties: available for software access. - description: aperture where the Root Port's own configuration registers are available. + - description: aperture to access the configuration space through ECAM. reg-names: + minItems: 4 items: - const: appl - const: config - const: atu_dma - const: dbi + - const: ecam interrupts: items: @@ -202,6 +206,31 @@ properties: allOf: - $ref: /schemas/pci/snps,dw-pcie.yaml# + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra194-pcie + then: + properties: + reg: + maxItems: 4 + reg-names: + maxItems: 4 + + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra234-pcie + then: + properties: + reg: + minItems: 5 + reg-names: + minItems: 5 unevaluatedProperties: false @@ -305,8 +334,9 @@ examples: reg = <0x00 0x14160000 0x0 0x00020000>, /* appl registers (128K) */ <0x00 0x36000000 0x0 0x00040000>, /* configuration space (256K) */ <0x00 0x36040000 0x0 0x00040000>, /* iATU_DMA reg space (256K) */ - <0x00 0x36080000 0x0 0x00040000>; /* DBI reg space (256K) */ - reg-names = "appl", "config", "atu_dma", "dbi"; + <0x00 0x36080000 0x0 0x00040000>, /* DBI reg space (256K) */ + <0x24 0x30000000 0x0 0x10000000>; /* ECAM (256MB) */ + reg-names = "appl", "config", "atu_dma", "dbi", "ecam"; #address-cells = <3>; #size-cells = <2>; diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml index 7287d395e1b6..7e0b015f1414 100644 --- a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml @@ -35,7 +35,7 @@ properties: maxItems: 5 items: enum: [ dbi, dbi2, config, atu, atu_dma, app, appl, elbi, mgmt, ctrl, - parf, cfg, link, ulreg, smu, mpu, apb, phy ] + parf, cfg, link, ulreg, smu, mpu, apb, phy, ecam ] num-lanes: description: | diff --git a/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml b/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml new file mode 100644 index 000000000000..50f46a6898b1 --- /dev/null +++ b/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/perf/amlogic,g12-ddr-pmu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic G12 DDR performance monitor + +maintainers: + - Jiucheng Xu <jiucheng.xu@amlogic.com> + +description: | + Amlogic G12 series SoC integrate DDR bandwidth monitor. + A timer is inside and can generate interrupt when timeout. + The bandwidth is counted in the timer ISR. Different platform + has different subset of event format attribute. + +properties: + compatible: + enum: + - amlogic,g12a-ddr-pmu + - amlogic,g12b-ddr-pmu + - amlogic,sm1-ddr-pmu + + reg: + items: + - description: DMC bandwidth register space. + - description: DMC PLL register space. + + interrupts: + items: + - description: The IRQ of the inside timer timeout. + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + pmu { + #address-cells=<2>; + #size-cells=<2>; + + pmu@ff638000 { + compatible = "amlogic,g12a-ddr-pmu"; + reg = <0x0 0xff638000 0x0 0x100>, + <0x0 0xff638c00 0x0 0x100>; + interrupts = <GIC_SPI 52 IRQ_TYPE_EDGE_RISING>; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-pinmux-common.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-pinmux-common.yaml new file mode 100644 index 000000000000..96c608bcb87e --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-pinmux-common.yaml @@ -0,0 +1,178 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra-pinmux-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Pinmux Controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jonathan Hunter <jonathanh@nvidia.com> + +description: | + 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". + + Tegra's 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, tristate, drive strength, + etc. + + 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 or tristate parameter. For this + reason, even seemingly boolean values are actually tristates in this + binding: unspecified, off, or on. Unspecified is represented as an absent + property, and off/on are represented as integer values 0 and 1. + + Note that many of these properties are only valid for certain specific pins + or groups. See the Tegra TRM and various pinmux spreadsheets for complete + details regarding which groups support which functionality. The Linux + pinctrl driver may also be a useful reference, since it consolidates, + disambiguates, and corrects data from all those sources. + +properties: + nvidia,pins: + $ref: /schemas/types.yaml#/definitions/string-array + description: An array of strings. Each string contains the name of a pin + or group. Valid values for these names are listed below. + + nvidia,function: + $ref: /schemas/types.yaml#/definitions/string + description: A string containing the name of the function to mux to the + pin or group. Valid values for function names are listed below. See the + Tegra TRM to determine which are valid for each pin or group. + + nvidia,pull: + description: Pull-down/up setting to apply to the pin. + $ref: /schemas/types.yaml#/definitions/uint32 + oneOf: + - description: none + const: 0 + - description: down + const: 1 + - description: up + const: 2 + + nvidia,tristate: + description: Tristate setting to apply to the pin. + $ref: /schemas/types.yaml#/definitions/uint32 + oneOf: + - description: drive + const: 0 + - description: tristate + const: 1 + + nvidia,schmitt: + description: Enable Schmitt trigger on the input. + $ref: /schemas/types.yaml#/definitions/uint32 + oneOf: + - description: disable Schmitt trigger on the input + const: 0 + - description: enable Schmitt trigger on the input + const: 1 + + nvidia,pull-down-strength: + description: Controls drive strength. 0 is weakest. The range of valid + values depends on the pingroup. See "CAL_DRVDN" in the Tegra TRM. + $ref: /schemas/types.yaml#/definitions/uint32 + + nvidia,pull-up-strength: + description: Controls drive strength. 0 is weakest. The range of valid + values depends on the pingroup. See "CAL_DRVUP" in the Tegra TRM. + $ref: /schemas/types.yaml#/definitions/uint32 + + nvidia,high-speed-mode: + description: Enable high speed mode the pins. + $ref: /schemas/types.yaml#/definitions/uint32 + oneOf: + - description: normal speed mode + const: 0 + - description: high speed mode + const: 1 + + nvidia,low-power-mode: + description: Controls the drive power or current. Valid values are from 0 + through 3, where 0 specifies the least power and 3 specifies the most + power. See "Low Power Mode" or "LPMD1" and "LPMD0" in the Tegra TRM. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 2, 3 ] + + nvidia,enable-input: + description: Enable the pin's input path. + $ref: /schemas/types.yaml#/definitions/uint32 + oneOf: + - description: disable input (i.e. output only) + const: 0 + - description: enable input + const: 1 + + nvidia,open-drain: + description: Open-drain configuration for the pin. + $ref: /schemas/types.yaml#/definitions/uint32 + oneOf: + - description: disable open-drain + const: 0 + - description: enable open-drain + const: 1 + + nvidia,lock: + description: Lock the pin configuration against further changes until + reset. + $ref: /schemas/types.yaml#/definitions/uint32 + oneOf: + - description: disable pin configuration lock + const: 0 + - description: enable pin configuration lock + const: 1 + + nvidia,io-reset: + description: reset the I/O path + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1 ] + + nvidia,rcv-sel: + description: select VIL/VIH receivers + $ref: /schemas/types.yaml#/definitions/uint32 + oneOf: + - description: normal receivers + const: 0 + - description: high-voltage receivers + const: 1 + + nvidia,drive-type: + description: Drive type to configure for the pin. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 2, 3 ] + + nvidia,io-hv: + description: Select high-voltage receivers. + $ref: /schemas/types.yaml#/definitions/uint32 + oneOf: + - description: Use normal receivers. + const: 0 + - description: Use high-voltage receivers. + const: 1 + + nvidia,slew-rate-rising: + description: Controls rising signal slew rate. 0 is fastest. The range of + valid values depends on the pingroup. See "DRVDN_SLWR" in the Tegra TRM. + $ref: /schemas/types.yaml#/definitions/uint32 + + nvidia,slew-rate-falling: + description: Controls falling signal slew rate. 0 is fastest. The range of + valid values depends on the pingroup. See "DRVUP_SLWF" in the Tegra TRM. + $ref: /schemas/types.yaml#/definitions/uint32 + +additionalProperties: true +... diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt deleted file mode 100644 index fb70856c5b51..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt +++ /dev/null @@ -1,131 +0,0 @@ -NVIDIA Tegra114 pinmux controller - -The Tegra114 pinctrl binding is very similar to the Tegra20 and Tegra30 -pinctrl binding, as described in nvidia,tegra20-pinmux.txt and -nvidia,tegra30-pinmux.txt. In fact, this document assumes that binding as -a baseline, and only documents the differences between the two bindings. - -Required properties: -- compatible: "nvidia,tegra114-pinmux" -- reg: Should contain the register physical address and length for each of - the pad control and mux registers. The first bank of address must be the - driver strength pad control register address and second bank address must - be pinmux register address. - -Tegra114 adds the following optional properties for pin configuration subnodes: -- nvidia,enable-input: Integer. Enable the pin's input path. 0: no, 1: yes. -- nvidia,open-drain: Integer. Enable open drain mode. 0: no, 1: yes. -- nvidia,lock: Integer. Lock the pin configuration against further changes - until reset. 0: no, 1: yes. -- nvidia,io-reset: Integer. Reset the IO path. 0: no, 1: yes. -- nvidia,rcv-sel: Integer. Select VIL/VIH receivers. 0: normal, 1: high. -- nvidia,drive-type: Integer. Valid range 0...3. - -As with Tegra20 and Terga30, see the Tegra TRM for complete details regarding -which groups support which functionality. - -Valid values for pin and group names are: - - per-pin mux groups: - - These all support nvidia,function, nvidia,tristate, nvidia,pull, - nvidia,enable-input, nvidia,lock. Some support nvidia,open-drain, - nvidia,io-reset and nvidia,rcv-sel. - - ulpi_data0_po1, ulpi_data1_po2, ulpi_data2_po3, ulpi_data3_po4, - ulpi_data4_po5, ulpi_data5_po6, ulpi_data6_po7, ulpi_data7_po0, - ulpi_clk_py0, ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3, dap3_fs_pp0, - dap3_din_pp1, dap3_dout_pp2, dap3_sclk_pp3, pv0, pv1, sdmmc1_clk_pz0, - sdmmc1_cmd_pz1, sdmmc1_dat3_py4, sdmmc1_dat2_py5, sdmmc1_dat1_py6, - sdmmc1_dat0_py7, clk2_out_pw5, clk2_req_pcc5, hdmi_int_pn7, ddc_scl_pv4, - ddc_sda_pv5, uart2_rxd_pc3, uart2_txd_pc2, uart2_rts_n_pj6, - uart2_cts_n_pj5, uart3_txd_pw6, uart3_rxd_pw7, uart3_cts_n_pa1, - uart3_rts_n_pc0, pu0, pu1, pu2, pu3, pu4, pu5, pu6, gen1_i2c_sda_pc5, - gen1_i2c_scl_pc4, dap4_fs_pp4, dap4_din_pp5, dap4_dout_pp6, dap4_sclk_pp7, - clk3_out_pee0, clk3_req_pee1, gmi_wp_n_pc7, gmi_iordy_pi5, gmi_wait_pi7, - gmi_adv_n_pk0, gmi_clk_pk1, gmi_cs0_n_pj0, gmi_cs1_n_pj2, gmi_cs2_n_pk3, - gmi_cs3_n_pk4, gmi_cs4_n_pk2, gmi_cs6_n_pi3, gmi_cs7_n_pi6, gmi_ad0_pg0, - gmi_ad1_pg1, gmi_ad2_pg2, gmi_ad3_pg3, gmi_ad4_pg4, gmi_ad5_pg5, - gmi_ad6_pg6, gmi_ad7_pg7, gmi_ad8_ph0, gmi_ad9_ph1, gmi_ad10_ph2, - gmi_ad11_ph3, gmi_ad12_ph4, gmi_ad13_ph5, gmi_ad14_ph6, gmi_ad15_ph7, - gmi_a16_pj7, gmi_a17_pb0, gmi_a18_pb1, gmi_a19_pk7, gmi_wr_n_pi0, - gmi_oe_n_pi1, gmi_dqs_p_pj3, gmi_rst_n_pi4, gen2_i2c_scl_pt5, - gen2_i2c_sda_pt6, sdmmc4_clk_pcc4, sdmmc4_cmd_pt7, sdmmc4_dat0_paa0, - sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, sdmmc4_dat3_paa3, sdmmc4_dat4_paa4, - sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, sdmmc4_dat7_paa7, cam_mclk_pcc0, - pcc1, pbb0, cam_i2c_scl_pbb1, cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6, - pbb7, pcc2, pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, kb_row0_pr0, kb_row1_pr1, - kb_row2_pr2, kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, kb_row6_pr6, - kb_row7_pr7, kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_col0_pq0, - kb_col1_pq1, kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5, - kb_col6_pq6, kb_col7_pq7, clk_32k_out_pa0, sys_clk_req_pz5, core_pwr_req, - cpu_pwr_req, pwr_int_n, owr, dap1_fs_pn0, dap1_din_pn1, dap1_dout_pn2, - dap1_sclk_pn3, clk1_req_pee2, clk1_out_pw4, spdif_in_pk6, spdif_out_pk5, - dap2_fs_pa2, dap2_din_pa4, dap2_dout_pa5, dap2_sclk_pa3, dvfs_pwm_px0, - gpio_x1_aud_px1, gpio_x3_aud_px3, dvfs_clk_px2, gpio_x4_aud_px4, - gpio_x5_aud_px5, gpio_x6_aud_px6, gpio_x7_aud_px7, sdmmc3_clk_pa6, - sdmmc3_cmd_pa7, sdmmc3_dat0_pb7, sdmmc3_dat1_pb6, sdmmc3_dat2_pb5, - sdmmc3_dat3_pb4, hdmi_cec_pee3, sdmmc1_wp_n_pv3, sdmmc3_cd_n_pv2, - gpio_w2_aud_pw2, gpio_w3_aud_pw3, usb_vbus_en0_pn4, usb_vbus_en1_pn5, - sdmmc3_clk_lb_in_pee5, sdmmc3_clk_lb_out_pee4, reset_out_n. - - drive groups: - - These all support nvidia,pull-down-strength, nvidia,pull-up-strength, - nvidia,slew-rate-rising, nvidia,slew-rate-falling. Most but not all - support nvidia,high-speed-mode, nvidia,schmitt, nvidia,low-power-mode - and nvidia,drive-type. - - ao1, ao2, at1, at2, at3, at4, at5, cdev1, cdev2, dap1, dap2, dap3, dap4, - dbg, sdio3, spi, uaa, uab, uart2, uart3, sdio1, ddc, gma, gme, gmf, gmg, - gmh, owr, uda. - -Valid values for nvidia,functions are: - - blink, cec, cldvfs, clk12, cpu, dap, dap1, dap2, dev3, displaya, - displaya_alt, displayb, dtv, emc_dll, extperiph1, extperiph2, - extperiph3, gmi, gmi_alt, hda, hsi, i2c1, i2c2, i2c3, i2c4, i2cpwr, - i2s0, i2s1, i2s2, i2s3, i2s4, irda, kbc, nand, nand_alt, owr, pmi, - pwm0, pwm1, pwm2, pwm3, pwron, reset_out_n, rsvd1, rsvd2, rsvd3, - rsvd4, sdmmc1, sdmmc2, sdmmc3, sdmmc4, soc, spdif, spi1, spi2, spi3, - spi4, spi5, spi6, sysclk, trace, uarta, uartb, uartc, uartd, ulpi, - usb, vgp1, vgp2, vgp3, vgp4, vgp5, vgp6, vi, vi_alt1, vi_alt3 - -Example: - - pinmux: pinmux { - compatible = "nvidia,tegra114-pinmux"; - reg = <0x70000868 0x148 /* Pad control registers */ - 0x70003000 0x40c>; /* PinMux registers */ - }; - -Example board file extract: - - pinctrl { - sdmmc4_default: pinmux { - sdmmc4_clk_pcc4 { - nvidia,pins = "sdmmc4_clk_pcc4", - nvidia,function = "sdmmc4"; - nvidia,pull = <0>; - nvidia,tristate = <0>; - }; - sdmmc4_dat0_paa0 { - nvidia,pins = "sdmmc4_dat0_paa0", - "sdmmc4_dat1_paa1", - "sdmmc4_dat2_paa2", - "sdmmc4_dat3_paa3", - "sdmmc4_dat4_paa4", - "sdmmc4_dat5_paa5", - "sdmmc4_dat6_paa6", - "sdmmc4_dat7_paa7"; - nvidia,function = "sdmmc4"; - nvidia,pull = <2>; - nvidia,tristate = <0>; - }; - }; - }; - - sdhci@78000400 { - pinctrl-names = "default"; - pinctrl-0 = <&sdmmc4_default>; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.yaml new file mode 100644 index 000000000000..065dedb3573a --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.yaml @@ -0,0 +1,155 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra114-pinmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra114 pinmux Controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + const: nvidia,tegra114-pinmux + + reg: + items: + - description: pad control registers + - description: mux registers + +patternProperties: + "^pinmux(-[a-z0-9-_]+)?$": + type: object + properties: + phandle: true + + # pin groups + additionalProperties: + $ref: nvidia,tegra-pinmux-common.yaml + additionalProperties: false + properties: + nvidia,pins: + items: + enum: [ ulpi_data0_po1, ulpi_data1_po2, ulpi_data2_po3, + ulpi_data3_po4, ulpi_data4_po5, ulpi_data5_po6, + ulpi_data6_po7, ulpi_data7_po0, ulpi_clk_py0, ulpi_dir_py1, + ulpi_nxt_py2, ulpi_stp_py3, dap3_fs_pp0, dap3_din_pp1, + dap3_dout_pp2, dap3_sclk_pp3, pv0, pv1, sdmmc1_clk_pz0, + sdmmc1_cmd_pz1, sdmmc1_dat3_py4, sdmmc1_dat2_py5, + sdmmc1_dat1_py6, sdmmc1_dat0_py7, clk2_out_pw5, + clk2_req_pcc5, hdmi_int_pn7, ddc_scl_pv4, ddc_sda_pv5, + uart2_rxd_pc3, uart2_txd_pc2, uart2_rts_n_pj6, + uart2_cts_n_pj5, uart3_txd_pw6, uart3_rxd_pw7, + uart3_cts_n_pa1, uart3_rts_n_pc0, pu0, pu1, pu2, pu3, pu4, + pu5, pu6, gen1_i2c_sda_pc5, gen1_i2c_scl_pc4, dap4_fs_pp4, + dap4_din_pp5, dap4_dout_pp6, dap4_sclk_pp7, clk3_out_pee0, + clk3_req_pee1, gmi_wp_n_pc7, gmi_iordy_pi5, gmi_wait_pi7, + gmi_adv_n_pk0, gmi_clk_pk1, gmi_cs0_n_pj0, gmi_cs1_n_pj2, + gmi_cs2_n_pk3, gmi_cs3_n_pk4, gmi_cs4_n_pk2, gmi_cs6_n_pi3, + gmi_cs7_n_pi6, gmi_ad0_pg0, gmi_ad1_pg1, gmi_ad2_pg2, + gmi_ad3_pg3, gmi_ad4_pg4, gmi_ad5_pg5, gmi_ad6_pg6, + gmi_ad7_pg7, gmi_ad8_ph0, gmi_ad9_ph1, gmi_ad10_ph2, + gmi_ad11_ph3, gmi_ad12_ph4, gmi_ad13_ph5, gmi_ad14_ph6, + gmi_ad15_ph7, gmi_a16_pj7, gmi_a17_pb0, gmi_a18_pb1, + gmi_a19_pk7, gmi_wr_n_pi0, gmi_oe_n_pi1, gmi_dqs_p_pj3, + gmi_rst_n_pi4, gen2_i2c_scl_pt5, gen2_i2c_sda_pt6, + sdmmc4_clk_pcc4, sdmmc4_cmd_pt7, sdmmc4_dat0_paa0, + sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, sdmmc4_dat3_paa3, + sdmmc4_dat4_paa4, sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, + sdmmc4_dat7_paa7, cam_mclk_pcc0, pcc1, pbb0, + cam_i2c_scl_pbb1, cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6, + pbb7, pcc2, pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, kb_row0_pr0, + kb_row1_pr1, kb_row2_pr2, kb_row3_pr3, kb_row4_pr4, + kb_row5_pr5, kb_row6_pr6, kb_row7_pr7, kb_row8_ps0, + kb_row9_ps1, kb_row10_ps2, kb_col0_pq0, kb_col1_pq1, + kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5, + kb_col6_pq6, kb_col7_pq7, clk_32k_out_pa0, sys_clk_req_pz5, + core_pwr_req, cpu_pwr_req, pwr_int_n, owr, dap1_fs_pn0, + dap1_din_pn1, dap1_dout_pn2, dap1_sclk_pn3, clk1_req_pee2, + clk1_out_pw4, spdif_in_pk6, spdif_out_pk5, dap2_fs_pa2, + dap2_din_pa4, dap2_dout_pa5, dap2_sclk_pa3, dvfs_pwm_px0, + gpio_x1_aud_px1, gpio_x3_aud_px3, dvfs_clk_px2, + gpio_x4_aud_px4, gpio_x5_aud_px5, gpio_x6_aud_px6, + gpio_x7_aud_px7, sdmmc3_clk_pa6, sdmmc3_cmd_pa7, + sdmmc3_dat0_pb7, sdmmc3_dat1_pb6, sdmmc3_dat2_pb5, + sdmmc3_dat3_pb4, hdmi_cec_pee3, sdmmc1_wp_n_pv3, + sdmmc3_cd_n_pv2, gpio_w2_aud_pw2, gpio_w3_aud_pw3, + usb_vbus_en0_pn4, usb_vbus_en1_pn5, sdmmc3_clk_lb_in_pee5, + sdmmc3_clk_lb_out_pee4, reset_out_n, + # drive groups + drive_ao1, drive_ao2, drive_at1, drive_at2, drive_at3, + drive_at4, drive_at5, drive_cdev1, drive_cdev2, drive_dap1, + drive_dap2, drive_dap3, drive_dap4, drive_dbg, drive_sdio3, + drive_spi, drive_uaa, drive_uab, drive_uart2, drive_uart3, + drive_sdio1, drive_ddc, drive_gma, drive_gme, drive_gmf, + drive_gmg, drive_gmh, drive_owr, drive_uda ] + + nvidia,function: + enum: [ blink, cec, cldvfs, clk12, cpu, dap, dap1, dap2, dev3, + displaya, displaya_alt, displayb, dtv, emc_dll, extperiph1, + extperiph2, extperiph3, gmi, gmi_alt, hda, hsi, i2c1, i2c2, + i2c3, i2c4, i2cpwr, i2s0, i2s1, i2s2, i2s3, i2s4, irda, kbc, + nand, nand_alt, owr, pmi, pwm0, pwm1, pwm2, pwm3, pwron, + reset_out_n, rsvd1, rsvd2, rsvd3, rsvd4, sdmmc1, sdmmc2, + sdmmc3, sdmmc4, soc, spdif, spi1, spi2, spi3, spi4, spi5, + spi6, sysclk, trace, uarta, uartb, uartc, uartd, ulpi, usb, + vgp1, vgp2, vgp3, vgp4, vgp5, vgp6, vi, vi_alt1, vi_alt3 ] + + nvidia,pull: true + nvidia,tristate: true + nvidia,schmitt: true + nvidia,pull-down-strength: true + nvidia,pull-up-strength: true + nvidia,high-speed-mode: true + nvidia,low-power-mode: true + nvidia,enable-input: true + nvidia,open-drain: true + nvidia,lock: true + nvidia,io-reset: true + nvidia,rcv-sel: true + nvidia,drive-type: true + nvidia,slew-rate-rising: true + nvidia,slew-rate-falling: true + + required: + - nvidia,pins + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + pinmux@70000868 { + compatible = "nvidia,tegra114-pinmux"; + reg = <0x70000868 0x148>, /* Pad control registers */ + <0x70003000 0x40c>; /* PinMux registers */ + + pinmux { + sdmmc4_clk_pcc4 { + nvidia,pins = "sdmmc4_clk_pcc4"; + nvidia,function = "sdmmc4"; + nvidia,pull = <0>; + nvidia,tristate = <0>; + }; + + sdmmc4_dat0_paa0 { + nvidia,pins = "sdmmc4_dat0_paa0", + "sdmmc4_dat1_paa1", + "sdmmc4_dat2_paa2", + "sdmmc4_dat3_paa3", + "sdmmc4_dat4_paa4", + "sdmmc4_dat5_paa5", + "sdmmc4_dat6_paa6", + "sdmmc4_dat7_paa7"; + nvidia,function = "sdmmc4"; + nvidia,pull = <2>; + nvidia,tristate = <0>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt deleted file mode 100644 index f4d06bb0b55a..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt +++ /dev/null @@ -1,153 +0,0 @@ -NVIDIA Tegra124 pinmux controller - -The Tegra124 pinctrl binding is very similar to the Tegra20 and Tegra30 -pinctrl binding, as described in nvidia,tegra20-pinmux.txt and -nvidia,tegra30-pinmux.txt. In fact, this document assumes that binding as -a baseline, and only documents the differences between the two bindings. - -Required properties: -- compatible: For Tegra124, must contain "nvidia,tegra124-pinmux". For - Tegra132, must contain '"nvidia,tegra132-pinmux", "nvidia-tegra124-pinmux"'. -- reg: Should contain a list of base address and size pairs for: - -- first entry - the drive strength and pad control registers. - -- second entry - the pinmux registers - -- third entry - the MIPI_PAD_CTRL register - -Tegra124 adds the following optional properties for pin configuration subnodes. -The macros for options are defined in the - include/dt-binding/pinctrl/pinctrl-tegra.h. -- nvidia,enable-input: Integer. Enable the pin's input path. - enable :TEGRA_PIN_ENABLE and - disable or output only: TEGRA_PIN_DISABLE. -- nvidia,open-drain: Integer. - enable: TEGRA_PIN_ENABLE. - disable: TEGRA_PIN_DISABLE. -- nvidia,lock: Integer. Lock the pin configuration against further changes - until reset. - enable: TEGRA_PIN_ENABLE. - disable: TEGRA_PIN_DISABLE. -- nvidia,io-reset: Integer. Reset the IO path. - enable: TEGRA_PIN_ENABLE. - disable: TEGRA_PIN_DISABLE. -- nvidia,rcv-sel: Integer. Select VIL/VIH receivers. - normal: TEGRA_PIN_DISABLE - high: TEGRA_PIN_ENABLE - -Please refer the Tegra TRM for complete details regarding which groups -support which functionality. - -Valid values for pin and group names are: - - per-pin mux groups: - - These all support nvidia,function, nvidia,tristate, nvidia,pull, - nvidia,enable-input. Some support nvidia,lock nvidia,open-drain, - nvidia,io-reset and nvidia,rcv-sel. - - ulpi_data0_po1, ulpi_data1_po2, ulpi_data2_po3, ulpi_data3_po4, - ulpi_data4_po5, ulpi_data5_po6, ulpi_data6_po7, ulpi_data7_po0, - ulpi_clk_py0, ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3, dap3_fs_pp0, - dap3_din_pp1, dap3_dout_pp2, dap3_sclk_pp3, pv0, pv1, sdmmc1_clk_pz0, - sdmmc1_cmd_pz1, sdmmc1_dat3_py4, sdmmc1_dat2_py5, sdmmc1_dat1_py6, - sdmmc1_dat0_py7, clk2_out_pw5, clk2_req_pcc5, hdmi_int_pn7, ddc_scl_pv4, - ddc_sda_pv5, uart2_rxd_pc3, uart2_txd_pc2, uart2_rts_n_pj6, - uart2_cts_n_pj5, uart3_txd_pw6, uart3_rxd_pw7, uart3_cts_n_pa1, - uart3_rts_n_pc0, pu0, pu1, pu2, pu3, pu4, pu5, pu6, gen1_i2c_scl_pc4, - gen1_i2c_sda_pc5, dap4_fs_pp4, dap4_din_pp5, dap4_dout_pp6, - dap4_sclk_pp7, clk3_out_pee0, clk3_req_pee1, pc7, pi5, pi7, pk0, pk1, - pj0, pj2, pk3, pk4, pk2, pi3, pi6, pg0, pg1, pg2, pg3, pg4, pg5, pg6, - pg7, ph0, ph1, ph2, ph3, ph4, ph5, ph6, ph7, pj7, pb0, pb1, pk7, pi0, - pi1, pi2, pi4, gen2_i2c_scl_pt5, gen2_i2c_sda_pt6, sdmmc4_clk_pcc4, - sdmmc4_cmd_pt7, sdmmc4_dat0_paa0, sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, - sdmmc4_dat3_paa3, sdmmc4_dat4_paa4, sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, - sdmmc4_dat7_paa7, cam_mclk_pcc0, pcc1, pbb0, cam_i2c_scl_pbb1, - cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6, pbb7, pcc2, jtag_rtck, - pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, kb_row0_pr0, kb_row1_pr1, kb_row2_pr2, - kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, kb_row6_pr6, kb_row7_pr7, - kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_row11_ps3, kb_row12_ps4, - kb_row13_ps5, kb_row14_ps6, kb_row15_ps7, kb_col0_pq0, kb_col1_pq1, - kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5, kb_col6_pq6, - kb_col7_pq7, clk_32k_out_pa0, core_pwr_req, cpu_pwr_req, pwr_int_n, - clk_32k_in, owr, dap1_fs_pn0, dap1_din_pn1, dap1_dout_pn2, - dap1_sclk_pn3, dap_mclk1_req_pee2, dap_mclk1_pw4, spdif_in_pk6, - spdif_out_pk5, dap2_fs_pa2, dap2_din_pa4, dap2_dout_pa5, dap2_sclk_pa3, - dvfs_pwm_px0, gpio_x1_aud_px1, gpio_x3_aud_px3, dvfs_clk_px2, - gpio_x4_aud_px4, gpio_x5_aud_px5, gpio_x6_aud_px6, gpio_x7_aud_px7, - sdmmc3_clk_pa6, sdmmc3_cmd_pa7, sdmmc3_dat0_pb7, sdmmc3_dat1_pb6, - sdmmc3_dat2_pb5, sdmmc3_dat3_pb4, pex_l0_rst_n_pdd1, - pex_l0_clkreq_n_pdd2, pex_wake_n_pdd3, pex_l1_rst_n_pdd5, - pex_l1_clkreq_n_pdd6, hdmi_cec_pee3, sdmmc1_wp_n_pv3, - sdmmc3_cd_n_pv2, gpio_w2_aud_pw2, gpio_w3_aud_pw3, usb_vbus_en0_pn4, - usb_vbus_en1_pn5, sdmmc3_clk_lb_out_pee4, sdmmc3_clk_lb_in_pee5, - gmi_clk_lb, reset_out_n, kb_row16_pt0, kb_row17_pt1, usb_vbus_en2_pff1, - pff2, dp_hpd_pff0, - - drive groups: - - These all support nvidia,pull-down-strength, nvidia,pull-up-strength, - nvidia,slew-rate-rising, nvidia,slew-rate-falling. Most but not all - support nvidia,high-speed-mode, nvidia,schmitt, nvidia,low-power-mode - and nvidia,drive-type. - - ao1, ao2, at1, at2, at3, at4, at5, cdev1, cdev2, dap1, dap2, dap3, dap4, - dbg, sdio3, spi, uaa, uab, uart2, uart3, sdio1, ddc, gma, gme, gmf, gmg, - gmh, owr, uda, gpv, dev3, cec, usb_vbus_en, ao3, ao0, hv0, sdio4, ao4. - - MIPI pad control groups: - - These support only the nvidia,function property. - - dsi_b - -Valid values for nvidia,functions are: - - blink, cec, cldvfs, clk12, cpu, dap, dap1, dap2, dev3, displaya, - displaya_alt, displayb, dtv, extperiph1, extperiph2, extperiph3, - gmi, gmi_alt, hda, hsi, i2c1, i2c2, i2c3, i2c4, i2cpwr, i2s0, - i2s1, i2s2, i2s3, i2s4, irda, kbc, owr, pmi, pwm0, pwm1, pwm2, pwm3, - pwron, reset_out_n, rsvd1, rsvd2, rsvd3, rsvd4, sdmmc1, sdmmc2, sdmmc3, - sdmmc4, soc, spdif, spi1, spi2, spi3, spi4, spi5, spi6, trace, uarta, - uartb, uartc, uartd, ulpi, usb, vgp1, vgp2, vgp3, vgp4, vgp5, vgp6, - vi, vi_alt1, vi_alt3, vimclk2, vimclk2_alt, sata, ccla, pe0, pe, pe1, - dp, rtck, sys, clk tmds, csi, dsi_b - -Example: - - pinmux: pinmux { - compatible = "nvidia,tegra124-pinmux"; - reg = <0x0 0x70000868 0x0 0x164>, /* Pad control registers */ - <0x0 0x70003000 0x0 0x434>, /* Mux registers */ - <0x0 0x70000820 0x0 0x8>; /* MIPI pad control */ - }; - -Example pinmux entries: - - pinctrl { - sdmmc4_default: pinmux { - sdmmc4_clk_pcc4 { - nvidia,pins = "sdmmc4_clk_pcc4", - nvidia,function = "sdmmc4"; - nvidia,pull = <TEGRA_PIN_PULL_NONE>; - nvidia,tristate = <TEGRA_PIN_DISABLE>; - }; - - sdmmc4_dat0_paa0 { - nvidia,pins = "sdmmc4_dat0_paa0", - "sdmmc4_dat1_paa1", - "sdmmc4_dat2_paa2", - "sdmmc4_dat3_paa3", - "sdmmc4_dat4_paa4", - "sdmmc4_dat5_paa5", - "sdmmc4_dat6_paa6", - "sdmmc4_dat7_paa7"; - nvidia,function = "sdmmc4"; - nvidia,pull = <TEGRA_PIN_PULL_UP>; - nvidia,tristate = <TEGRA_PIN_DISABLE>; - }; - }; - }; - - sdhci@78000400 { - pinctrl-names = "default"; - pinctrl-0 = <&sdmmc4_default>; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.yaml new file mode 100644 index 000000000000..f924652bef0d --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.yaml @@ -0,0 +1,176 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra124-pinmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra124 Pinmux Controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: The Tegra124 pinctrl binding is very similar to the Tegra20 and + Tegra30 pinctrl binding, as described in nvidia,tegra20-pinmux.yaml and + nvidia,tegra30-pinmux.yaml. In fact, this document assumes that binding as a + baseline, and only documents the differences between the two bindings. + +properties: + compatible: + oneOf: + - const: nvidia,tegra124-pinmux + - items: + - const: nvidia,tegra132-pinmux + - const: nvidia,tegra124-pinmux + + reg: + items: + - description: driver strength and pad control registers + - description: pinmux registers + - description: MIPI_PAD_CTRL registers + +patternProperties: + "^pinmux(-[a-z0-9-_]+)?$": + type: object + properties: + phandle: true + + # pin groups + additionalProperties: + $ref: nvidia,tegra-pinmux-common.yaml + additionalProperties: false + properties: + nvidia,pins: + $ref: /schemas/types.yaml#/definitions/string-array + items: + enum: [ ulpi_data0_po1, ulpi_data1_po2, ulpi_data2_po3, + ulpi_data3_po4, ulpi_data4_po5, ulpi_data5_po6, + ulpi_data6_po7, ulpi_data7_po0, ulpi_clk_py0, ulpi_dir_py1, + ulpi_nxt_py2, ulpi_stp_py3, dap3_fs_pp0, dap3_din_pp1, + dap3_dout_pp2, dap3_sclk_pp3, pv0, pv1, sdmmc1_clk_pz0, + sdmmc1_cmd_pz1, sdmmc1_dat3_py4, sdmmc1_dat2_py5, + sdmmc1_dat1_py6, sdmmc1_dat0_py7, clk2_out_pw5, + clk2_req_pcc5, hdmi_int_pn7, ddc_scl_pv4, ddc_sda_pv5, + uart2_rxd_pc3, uart2_txd_pc2, uart2_rts_n_pj6, + uart2_cts_n_pj5, uart3_txd_pw6, uart3_rxd_pw7, + uart3_cts_n_pa1, uart3_rts_n_pc0, pu0, pu1, pu2, pu3, pu4, + pu5, pu6, gen1_i2c_scl_pc4, gen1_i2c_sda_pc5, dap4_fs_pp4, + dap4_din_pp5, dap4_dout_pp6, dap4_sclk_pp7, clk3_out_pee0, + clk3_req_pee1, pc7, pi5, pi7, pk0, pk1, pj0, pj2, pk3, pk4, + pk2, pi3, pi6, pg0, pg1, pg2, pg3, pg4, pg5, pg6, pg7, ph0, + ph1, ph2, ph3, ph4, ph5, ph6, ph7, pj7, pb0, pb1, pk7, pi0, + pi1, pi2, pi4, gen2_i2c_scl_pt5, gen2_i2c_sda_pt6, + sdmmc4_clk_pcc4, sdmmc4_cmd_pt7, sdmmc4_dat0_paa0, + sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, sdmmc4_dat3_paa3, + sdmmc4_dat4_paa4, sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, + sdmmc4_dat7_paa7, cam_mclk_pcc0, pcc1, pbb0, + cam_i2c_scl_pbb1, cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6, + pbb7, pcc2, jtag_rtck, pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, + kb_row0_pr0, kb_row1_pr1, kb_row2_pr2, kb_row3_pr3, + kb_row4_pr4, kb_row5_pr5, kb_row6_pr6, kb_row7_pr7, + kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_row11_ps3, + kb_row12_ps4, kb_row13_ps5, kb_row14_ps6, kb_row15_ps7, + kb_col0_pq0, kb_col1_pq1, kb_col2_pq2, kb_col3_pq3, + kb_col4_pq4, kb_col5_pq5, kb_col6_pq6, kb_col7_pq7, + clk_32k_out_pa0, core_pwr_req, cpu_pwr_req, pwr_int_n, + clk_32k_in, owr, dap1_fs_pn0, dap1_din_pn1, dap1_dout_pn2, + dap1_sclk_pn3, dap_mclk1_req_pee2, dap_mclk1_pw4, + spdif_in_pk6, spdif_out_pk5, dap2_fs_pa2, dap2_din_pa4, + dap2_dout_pa5, dap2_sclk_pa3, dvfs_pwm_px0, + gpio_x1_aud_px1, gpio_x3_aud_px3, dvfs_clk_px2, + gpio_x4_aud_px4, gpio_x5_aud_px5, gpio_x6_aud_px6, + gpio_x7_aud_px7, sdmmc3_clk_pa6, sdmmc3_cmd_pa7, + sdmmc3_dat0_pb7, sdmmc3_dat1_pb6, sdmmc3_dat2_pb5, + sdmmc3_dat3_pb4, pex_l0_rst_n_pdd1, pex_l0_clkreq_n_pdd2, + pex_wake_n_pdd3, pex_l1_rst_n_pdd5, pex_l1_clkreq_n_pdd6, + hdmi_cec_pee3, sdmmc1_wp_n_pv3, sdmmc3_cd_n_pv2, + gpio_w2_aud_pw2, gpio_w3_aud_pw3, usb_vbus_en0_pn4, + usb_vbus_en1_pn5, sdmmc3_clk_lb_out_pee4, + sdmmc3_clk_lb_in_pee5, gmi_clk_lb, reset_out_n, + kb_row16_pt0, kb_row17_pt1, usb_vbus_en2_pff1, pff2, + dp_hpd_pff0, + # drive groups + drive_ao1, drive_ao2, drive_at1, drive_at2, drive_at3, + drive_at4, drive_at5, drive_cdev1, drive_cdev2, drive_dap1, + drive_dap2, drive_dap3, drive_dap4, drive_dbg, drive_sdio3, + drive_spi, drive_uaa, drive_uab, drive_uart2, drive_uart3, + drive_sdio1, drive_ddc, drive_gma, drive_gme, drive_gmf, + drive_gmg, drive_gmh, drive_owr, drive_uda, drive_gpv, + drive_dev3, drive_cec, drive_usb_vbus_en, drive_ao3, + drive_ao0, drive_hv0, drive_sdio4, drive_ao4, + # MIPI pad control groups + mipi_pad_ctrl_dsi_b ] + + nvidia,function: + enum: [ blink, cec, cldvfs, clk12, cpu, dap, dap1, dap2, dev3, + displaya, displaya_alt, displayb, dtv, extperiph1, + extperiph2, extperiph3, gmi, gmi_alt, hda, hsi, i2c1, i2c2, + i2c3, i2c4, i2cpwr, i2s0, i2s1, i2s2, i2s3, i2s4, irda, kbc, + owr, pmi, pwm0, pwm1, pwm2, pwm3, pwron, reset_out_n, rsvd1, + rsvd2, rsvd3, rsvd4, sdmmc1, sdmmc2, sdmmc3, sdmmc4, soc, + spdif, spi1, spi2, spi3, spi4, spi5, spi6, trace, uarta, + uartb, uartc, uartd, ulpi, usb, vgp1, vgp2, vgp3, vgp4, vgp5, + vgp6, vi, vi_alt1, vi_alt3, vimclk2, vimclk2_alt, sata, ccla, + pe0, pe, pe1, dp, rtck, sys, clk, tmds, csi, dsi_b ] + + nvidia,pull: true + nvidia,tristate: true + nvidia,schmitt: true + nvidia,pull-down-strength: true + nvidia,pull-up-strength: true + nvidia,high-speed-mode: true + nvidia,low-power-mode: true + nvidia,enable-input: true + nvidia,open-drain: true + nvidia,lock: true + nvidia,io-reset: true + nvidia,rcv-sel: true + nvidia,drive-type: true + nvidia,slew-rate-rising: true + nvidia,slew-rate-falling: true + + required: + - nvidia,pins + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + #include <dt-bindings/clock/tegra124-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/pinctrl/pinctrl-tegra.h> + + pinmux@70000868 { + compatible = "nvidia,tegra124-pinmux"; + reg = <0x70000868 0x164>, /* Pad control registers */ + <0x70003000 0x434>, /* Mux registers */ + <0x70000820 0x8>; /* MIPI pad control */ + + sdmmc4_default: pinmux { + sdmmc4_clk_pcc4 { + nvidia,pins = "sdmmc4_clk_pcc4"; + nvidia,function = "sdmmc4"; + nvidia,pull = <TEGRA_PIN_PULL_NONE>; + nvidia,tristate = <TEGRA_PIN_DISABLE>; + }; + + sdmmc4_dat0_paa0 { + nvidia,pins = "sdmmc4_dat0_paa0", + "sdmmc4_dat1_paa1", + "sdmmc4_dat2_paa2", + "sdmmc4_dat3_paa3", + "sdmmc4_dat4_paa4", + "sdmmc4_dat5_paa5", + "sdmmc4_dat6_paa6", + "sdmmc4_dat7_paa7"; + nvidia,function = "sdmmc4"; + nvidia,pull = <TEGRA_PIN_PULL_UP>; + nvidia,tristate = <TEGRA_PIN_DISABLE>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.txt deleted file mode 100644 index 90d38f710635..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.txt +++ /dev/null @@ -1,107 +0,0 @@ -NVIDIA Tegra194 pinmux controller - -Required properties: -- compatible: "nvidia,tegra194-pinmux" -- reg: Should contain a list of base address and size pairs for: - - first entry: The APB_MISC_GP_*_PADCTRL registers (pad control) - - second entry: The PINMUX_AUX_* registers (pinmux) - -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". - -Tegra's 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, tristate, drive strength, etc. - -See the TRM to determine which properties and values apply to each pin/group. -Macro values for property values are defined in -include/dt-binding/pinctrl/pinctrl-tegra.h. - -Required subnode-properties: -- nvidia,pins : An array of strings. Each string contains the name of a pin or - group. Valid values for these names are listed below. - -Optional subnode-properties: -- nvidia,function: A string containing the name of the function to mux to the - pin or group. -- nvidia,pull: Integer, representing the pull-down/up to apply to the pin. - 0: none, 1: down, 2: up. -- nvidia,tristate: Integer. - 0: drive, 1: tristate. -- nvidia,enable-input: Integer. Enable the pin's input path. - enable :TEGRA_PIN_ENABLE and - disable or output only: TEGRA_PIN_DISABLE. -- nvidia,open-drain: Integer. - enable: TEGRA_PIN_ENABLE. - disable: TEGRA_PIN_DISABLE. -- nvidia,lock: Integer. Lock the pin configuration against further changes - until reset. - enable: TEGRA_PIN_ENABLE. - disable: TEGRA_PIN_DISABLE. -- nvidia,io-hv: Integer. Select high-voltage receivers. - normal: TEGRA_PIN_DISABLE - high: TEGRA_PIN_ENABLE -- nvidia,schmitt: Integer. Enables Schmitt Trigger on the input. - normal: TEGRA_PIN_DISABLE - high: TEGRA_PIN_ENABLE -- nvidia,drive-type: Integer. Valid range 0...3. -- nvidia,pull-down-strength: Integer. Controls drive strength. 0 is weakest. - The range of valid values depends on the pingroup. See "CAL_DRVDN" in the - Tegra TRM. -- nvidia,pull-up-strength: Integer. Controls drive strength. 0 is weakest. - The range of valid values depends on the pingroup. See "CAL_DRVUP" in the - Tegra TRM. - -Valid values for pin and group names (nvidia,pin) are: - - These correspond to Tegra PADCTL_* (pinmux) registers. - - Mux groups: - - These correspond to Tegra PADCTL_* (pinmux) registers. Any property - that exists in those registers may be set for the following pin names. - - pex_l5_clkreq_n_pgg0, pex_l5_rst_n_pgg1 - - Drive groups: - - These registers controls a single pin for which a mux group exists. - See the list above for the pin name to use when configuring the pinmux. - - pex_l5_clkreq_n_pgg0, pex_l5_rst_n_pgg1 - -Valid values for nvidia,functions are: - - pe5 - -Power Domain: - pex_l5_clkreq_n_pgg0 and pex_l5_rst_n_pgg1 are part of PCIE C5 power - partition. Client devices must enable this partition before accessing - these pins here. - - -Example: - - tegra_pinctrl: pinmux: pinmux@2430000 { - compatible = "nvidia,tegra194-pinmux"; - reg = <0x2430000 0x17000 - 0xc300000 0x4000>; - - pinctrl-names = "pex_rst"; - pinctrl-0 = <&pex_rst_c5_out_state>; - - pex_rst_c5_out_state: pex_rst_c5_out { - pex_rst { - nvidia,pins = "pex_l5_rst_n_pgg1"; - nvidia,schmitt = <TEGRA_PIN_DISABLE>; - nvidia,lpdr = <TEGRA_PIN_ENABLE>; - nvidia,enable-input = <TEGRA_PIN_DISABLE>; - nvidia,io-hv = <TEGRA_PIN_ENABLE>; - nvidia,tristate = <TEGRA_PIN_DISABLE>; - nvidia,pull = <TEGRA_PIN_PULL_NONE>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.yaml new file mode 100644 index 000000000000..60a4bdf01bf2 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.yaml @@ -0,0 +1,284 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra194-pinmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra194 Pinmux Controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + enum: + - nvidia,tegra194-pinmux + - nvidia,tegra194-pinmux-aon + + reg: + items: + - description: pinmux registers + +patternProperties: + "^pinmux(-[a-z0-9-_]+)?$": + type: object + properties: + phandle: true + + # pin groups + additionalProperties: + $ref: nvidia,tegra-pinmux-common.yaml + unevaluatedProperties: false + properties: + nvidia,function: + enum: [ aud, can0, can1, ccla, dca, dcb, dgpu, directdc, directdc1, + displaya, displayb, dmic1, dmic2, dmic3, dmic4, dmic5, dp, + dspk0, dspk1, eqos, extperiph1, extperiph2, extperiph3, + extperiph4, gp, gpio, hdmi, i2c1, i2c2, i2c3, i2c5, i2c8, + i2s1, i2s2, i2s3, i2s4, i2s5, i2s6, igpu, iqc1, iqc2, mipi, + nv, pe0, pe1, pe2, pe3, pe4, pe5, qspi, qspi0, qspi1, rsvd0, + rsvd1, rsvd2, rsvd3, sata, sce, sdmmc1, sdmmc3, sdmmc4, slvs, + soc, spdif, spi1, spi2, spi3, touch, uarta, uartb, uartc, + uartd, uarte, uartg, ufs0, usb, vgp1, vgp2, vgp3, vgp4, vgp5, + vgp6, wdt ] + + nvidia,pull: true + nvidia,tristate: true + nvidia,schmitt: true + nvidia,enable-input: true + nvidia,open-drain: true + nvidia,lock: true + nvidia,drive-type: true + nvidia,io-hv: true + + required: + - nvidia,pins + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + const: nvidia,tegra194-pinmux + then: + patternProperties: + "^pinmux(-[a-z0-9-_]+)?$": + type: object + additionalProperties: + properties: + nvidia,pins: + description: An array of strings. Each string contains the name + of a pin or group. Valid values for these names are listed + below. + + Note that the pex_l5_clkreq_n_pgg0 and pex_l5_rst_n_pgg1 pins + are part of PCIE C5 power partition. Client devices must + enable this partition before accessing the configuration for + these pins. + items: + enum: [ dap6_sclk_pa0, dap6_dout_pa1, dap6_din_pa2, + dap6_fs_pa3, dap4_sclk_pa4, dap4_dout_pa5, + dap4_din_pa6, dap4_fs_pa7, cpu_pwr_req_0_pb0, + cpu_pwr_req_1_pb1, qspi0_sck_pc0, qspi0_cs_n_pc1, + qspi0_io0_pc2, qspi0_io1_pc3, qspi0_io2_pc4, + qspi0_io3_pc5, qspi1_sck_pc6, qspi1_cs_n_pc7, + qspi1_io0_pd0, qspi1_io1_pd1, qspi1_io2_pd2, + qspi1_io3_pd3, eqos_txc_pe0, eqos_td0_pe1, + eqos_td1_pe2, eqos_td2_pe3, eqos_td3_pe4, + eqos_tx_ctl_pe5, eqos_rd0_pe6, eqos_rd1_pe7, + eqos_rd2_pf0, eqos_rd3_pf1, eqos_rx_ctl_pf2, + eqos_rxc_pf3, eqos_sma_mdio_pf4, eqos_sma_mdc_pf5, + soc_gpio00_pg0, soc_gpio01_pg1, soc_gpio02_pg2, + soc_gpio03_pg3, soc_gpio08_pg4, soc_gpio09_pg5, + soc_gpio10_pg6, soc_gpio11_pg7, soc_gpio12_ph0, + soc_gpio13_ph1, soc_gpio14_ph2, uart4_tx_ph3, + uart4_rx_ph4, uart4_rts_ph5, uart4_cts_ph6, + dap2_sclk_ph7, dap2_dout_pi0, dap2_din_pi1, + dap2_fs_pi2, gen1_i2c_scl_pi3, gen1_i2c_sda_pi4, + sdmmc1_clk_pj0, sdmmc1_cmd_pj1, sdmmc1_dat0_pj2, + sdmmc1_dat1_pj3, sdmmc1_dat2_pj4, sdmmc1_dat3_pj5, + pex_l0_clkreq_n_pk0, pex_l0_rst_n_pk1, + pex_l1_clkreq_n_pk2, pex_l1_rst_n_pk3, + pex_l2_clkreq_n_pk4, pex_l2_rst_n_pk5, + pex_l3_clkreq_n_pk6, pex_l3_rst_n_pk7, + pex_l4_clkreq_n_pl0, pex_l4_rst_n_pl1, + pex_wake_n_pl2, sata_dev_slp_pl3, dp_aux_ch0_hpd_pm0, + dp_aux_ch1_hpd_pm1, dp_aux_ch2_hpd_pm2, + dp_aux_ch3_hpd_pm3, hdmi_cec_pm4, soc_gpio50_pm5, + soc_gpio51_pm6, soc_gpio52_pm7, soc_gpio53_pn0, + soc_gpio54_pn1, soc_gpio55_pn2, sdmmc3_clk_po0, + sdmmc3_cmd_po1, sdmmc3_dat0_po2, sdmmc3_dat1_po3, + sdmmc3_dat2_po4, sdmmc3_dat3_po5, extperiph1_clk_pp0, + extperiph2_clk_pp1, cam_i2c_scl_pp2, cam_i2c_sda_pp3, + soc_gpio04_pp4, soc_gpio05_pp5, soc_gpio06_pp6, + soc_gpio07_pp7, soc_gpio20_pq0, soc_gpio21_pq1, + soc_gpio22_pq2, soc_gpio23_pq3, soc_gpio40_pq4, + soc_gpio41_pq5, soc_gpio42_pq6, soc_gpio43_pq7, + soc_gpio44_pr0, soc_gpio45_pr1, uart1_tx_pr2, + uart1_rx_pr3, uart1_rts_pr4, uart1_cts_pr5, + dap1_sclk_ps0, dap1_dout_ps1, dap1_din_ps2, + dap1_fs_ps3, aud_mclk_ps4, soc_gpio30_ps5, + soc_gpio31_ps6, soc_gpio32_ps7, soc_gpio33_pt0, + dap3_sclk_pt1, dap3_dout_pt2, dap3_din_pt3, + dap3_fs_pt4, dap5_sclk_pt5, dap5_dout_pt6, + dap5_din_pt7, dap5_fs_pu0, directdc1_clk_pv0, + directdc1_in_pv1, directdc1_out0_pv2, + directdc1_out1_pv3, directdc1_out2_pv4, + directdc1_out3_pv5, directdc1_out4_pv6, + directdc1_out5_pv7, directdc1_out6_pw0, + directdc1_out7_pw1, gpu_pwr_req_px0, cv_pwr_req_px1, + gp_pwm2_px2, gp_pwm3_px3, uart2_tx_px4, uart2_rx_px5, + uart2_rts_px6, uart2_cts_px7, spi3_sck_py0, + spi3_miso_py1, spi3_mosi_py2, spi3_cs0_py3, + spi3_cs1_py4, uart5_tx_py5, uart5_rx_py6, + uart5_rts_py7, uart5_cts_pz0, usb_vbus_en0_pz1, + usb_vbus_en1_pz2, spi1_sck_pz3, spi1_miso_pz4, + spi1_mosi_pz5, spi1_cs0_pz6, spi1_cs1_pz7, + ufs0_ref_clk_pff0, ufs0_rst_pff1, + pex_l5_clkreq_n_pgg0, pex_l5_rst_n_pgg1, + directdc_comp, sdmmc4_clk, sdmmc4_cmd, sdmmc4_dqs, + sdmmc4_dat7, sdmmc4_dat6, sdmmc4_dat5, sdmmc4_dat4, + sdmmc4_dat3, sdmmc4_dat2, sdmmc4_dat1, sdmmc4_dat0, + sdmmc1_comp, sdmmc1_hv_trim, sdmmc3_comp, + sdmmc3_hv_trim, eqos_comp, qspi_comp, + # drive groups + drive_soc_gpio33_pt0, drive_soc_gpio32_ps7, + drive_soc_gpio31_ps6, drive_soc_gpio30_ps5, + drive_aud_mclk_ps4, drive_dap1_fs_ps3, + drive_dap1_din_ps2, drive_dap1_dout_ps1, + drive_dap1_sclk_ps0, drive_dap3_fs_pt4, + drive_dap3_din_pt3, drive_dap3_dout_pt2, + drive_dap3_sclk_pt1, drive_dap5_fs_pu0, + drive_dap5_din_pt7, drive_dap5_dout_pt6, + drive_dap5_sclk_pt5, drive_dap6_fs_pa3, + drive_dap6_din_pa2, drive_dap6_dout_pa1, + drive_dap6_sclk_pa0, drive_dap4_fs_pa7, + drive_dap4_din_pa6, drive_dap4_dout_pa5, + drive_dap4_sclk_pa4, drive_extperiph2_clk_pp1, + drive_extperiph1_clk_pp0, drive_cam_i2c_sda_pp3, + drive_cam_i2c_scl_pp2, drive_soc_gpio40_pq4, + drive_soc_gpio41_pq5, drive_soc_gpio42_pq6, + drive_soc_gpio43_pq7, drive_soc_gpio44_pr0, + drive_soc_gpio45_pr1, drive_soc_gpio20_pq0, + drive_soc_gpio21_pq1, drive_soc_gpio22_pq2, + drive_soc_gpio23_pq3, drive_soc_gpio04_pp4, + drive_soc_gpio05_pp5, drive_soc_gpio06_pp6, + drive_soc_gpio07_pp7, drive_uart1_cts_pr5, + drive_uart1_rts_pr4, drive_uart1_rx_pr3, + drive_uart1_tx_pr2, drive_dap2_din_pi1, + drive_dap2_dout_pi0, drive_dap2_fs_pi2, + drive_dap2_sclk_ph7, drive_uart4_cts_ph6, + drive_uart4_rts_ph5, drive_uart4_rx_ph4, + drive_uart4_tx_ph3, drive_soc_gpio03_pg3, + drive_soc_gpio02_pg2, drive_soc_gpio01_pg1, + drive_soc_gpio00_pg0, drive_gen1_i2c_scl_pi3, + drive_gen1_i2c_sda_pi4, drive_soc_gpio08_pg4, + drive_soc_gpio09_pg5, drive_soc_gpio10_pg6, + drive_soc_gpio11_pg7, drive_soc_gpio12_ph0, + drive_soc_gpio13_ph1, drive_soc_gpio14_ph2, + drive_soc_gpio50_pm5, drive_soc_gpio51_pm6, + drive_soc_gpio52_pm7, drive_soc_gpio53_pn0, + drive_soc_gpio54_pn1, drive_soc_gpio55_pn2, + drive_dp_aux_ch0_hpd_pm0, drive_dp_aux_ch1_hpd_pm1, + drive_dp_aux_ch2_hpd_pm2, drive_dp_aux_ch3_hpd_pm3, + drive_hdmi_cec_pm4, drive_pex_l2_clkreq_n_pk4, + drive_pex_wake_n_pl2, drive_pex_l1_clkreq_n_pk2, + drive_pex_l1_rst_n_pk3, drive_pex_l0_clkreq_n_pk0, + drive_pex_l0_rst_n_pk1, drive_pex_l2_rst_n_pk5, + drive_pex_l3_clkreq_n_pk6, drive_pex_l3_rst_n_pk7, + drive_pex_l4_clkreq_n_pl0, drive_pex_l4_rst_n_pl1, + drive_sata_dev_slp_pl3, drive_pex_l5_clkreq_n_pgg0, + drive_pex_l5_rst_n_pgg1, drive_cpu_pwr_req_1_pb1, + drive_cpu_pwr_req_0_pb0, drive_sdmmc1_clk_pj0, + drive_sdmmc1_cmd_pj1, drive_sdmmc1_dat3_pj5, + drive_sdmmc1_dat2_pj4, drive_sdmmc1_dat1_pj3, + drive_sdmmc1_dat0_pj2, drive_sdmmc3_dat3_po5, + drive_sdmmc3_dat2_po4, drive_sdmmc3_dat1_po3, + drive_sdmmc3_dat0_po2, drive_sdmmc3_cmd_po1, + drive_sdmmc3_clk_po0, drive_gpu_pwr_req_px0, + drive_spi3_miso_py1, drive_spi1_cs0_pz6, + drive_spi3_cs0_py3, drive_spi1_miso_pz4, + drive_spi3_cs1_py4, drive_gp_pwm3_px3, + drive_gp_pwm2_px2, drive_spi1_sck_pz3, + drive_spi3_sck_py0, drive_spi1_cs1_pz7, + drive_spi1_mosi_pz5, drive_spi3_mosi_py2, + drive_cv_pwr_req_px1, drive_uart2_tx_px4, + drive_uart2_rx_px5, drive_uart2_rts_px6, + drive_uart2_cts_px7, drive_uart5_rx_py6, + drive_uart5_tx_py5, drive_uart5_rts_py7, + drive_uart5_cts_pz0, drive_usb_vbus_en0_pz1, + drive_usb_vbus_en1_pz2, drive_ufs0_rst_pff1, + drive_ufs0_ref_clk_pff0 ] + + - if: + properties: + compatible: + const: nvidia,tegra194-pinmux-aon + then: + patternProperties: + "^pinmux(-[a-z0-9-_]+)?$": + type: object + additionalProperties: + properties: + nvidia,pins: + items: + enum: [ can1_dout_paa0, can1_din_paa1, can0_dout_paa2, + can0_din_paa3, can0_stb_paa4, can0_en_paa5, + can0_wake_paa6, can0_err_paa7, can1_stb_pbb0, + can1_en_pbb1, can1_wake_pbb2, can1_err_pbb3, + spi2_sck_pcc0, spi2_miso_pcc1, spi2_mosi_pcc2, + spi2_cs0_pcc3, touch_clk_pcc4, uart3_tx_pcc5, + uart3_rx_pcc6, gen2_i2c_scl_pcc7, gen2_i2c_sda_pdd0, + gen8_i2c_scl_pdd1, gen8_i2c_sda_pdd2, + safe_state_pee0, vcomp_alert_pee1, + ao_retention_n_pee2, batt_oc_pee3, power_on_pee4, + pwr_i2c_scl_pee5, pwr_i2c_sda_pee6, sys_reset_n, + shutdown_n, pmu_int_n, soc_pwr_req, clk_32k_in, + # drive groups + drive_shutdown_n, drive_pmu_int_n, + drive_safe_state_pee0, drive_vcomp_alert_pee1, + drive_soc_pwr_req, drive_batt_oc_pee3, + drive_clk_32k_in, drive_power_on_pee4, + drive_pwr_i2c_scl_pee5, drive_pwr_i2c_sda_pee6, + drive_ao_retention_n_pee2, drive_touch_clk_pcc4, + drive_uart3_rx_pcc6, drive_uart3_tx_pcc5, + drive_gen8_i2c_sda_pdd2, drive_gen8_i2c_scl_pdd1, + drive_spi2_mosi_pcc2, drive_gen2_i2c_scl_pcc7, + drive_spi2_cs0_pcc3, drive_gen2_i2c_sda_pdd0, + drive_spi2_sck_pcc0, drive_spi2_miso_pcc1, + drive_can1_dout_paa0, drive_can1_din_paa1, + drive_can0_dout_paa2, drive_can0_din_paa3, + drive_can0_stb_paa4, drive_can0_en_paa5, + drive_can0_wake_paa6, drive_can0_err_paa7, + drive_can1_stb_pbb0, drive_can1_en_pbb1, + drive_can1_wake_pbb2, drive_can1_err_pbb3 ] + +required: + - compatible + - reg + +examples: + - | + #include <dt-bindings/pinctrl/pinctrl-tegra.h> + + pinmux@2430000 { + compatible = "nvidia,tegra194-pinmux"; + reg = <0x2430000 0x17000>; + + pinctrl-names = "pex_rst"; + pinctrl-0 = <&pex_rst_c5_out_state>; + + pex_rst_c5_out_state: pinmux-pex-rst-c5-out { + pex_rst { + nvidia,pins = "pex_l5_rst_n_pgg1"; + nvidia,schmitt = <TEGRA_PIN_DISABLE>; + nvidia,enable-input = <TEGRA_PIN_DISABLE>; + nvidia,io-hv = <TEGRA_PIN_ENABLE>; + nvidia,tristate = <TEGRA_PIN_DISABLE>; + nvidia,pull = <TEGRA_PIN_PULL_NONE>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt deleted file mode 100644 index 3c8ce28baad6..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt +++ /dev/null @@ -1,143 +0,0 @@ -NVIDIA Tegra20 pinmux controller - -Required properties: -- compatible: "nvidia,tegra20-pinmux" -- reg: Should contain the register physical address and length for each of - the tri-state, mux, pull-up/down, and pad control register sets. - -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". - -Tegra's 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, tristate, drive strength, etc. - -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 or tristate parameter. For this -reason, even seemingly boolean values are actually tristates in this binding: -unspecified, off, or on. Unspecified is represented as an absent property, -and off/on are represented as integer values 0 and 1. - -Required subnode-properties: -- nvidia,pins : An array of strings. Each string contains the name of a pin or - group. Valid values for these names are listed below. - -Optional subnode-properties: -- nvidia,function: A string containing the name of the function to mux to the - pin or group. Valid values for function names are listed below. See the Tegra - TRM to determine which are valid for each pin or group. -- nvidia,pull: Integer, representing the pull-down/up to apply to the pin. - 0: none, 1: down, 2: up. -- nvidia,tristate: Integer. - 0: drive, 1: tristate. -- nvidia,high-speed-mode: Integer. Enable high speed mode the pins. - 0: no, 1: yes. -- nvidia,schmitt: Integer. Enables Schmitt Trigger on the input. - 0: no, 1: yes. -- nvidia,low-power-mode: Integer. Valid values 0-3. 0 is least power, 3 is - most power. Controls the drive power or current. See "Low Power Mode" - or "LPMD1" and "LPMD0" in the Tegra TRM. -- nvidia,pull-down-strength: Integer. Controls drive strength. 0 is weakest. - The range of valid values depends on the pingroup. See "CAL_DRVDN" in the - Tegra TRM. -- nvidia,pull-up-strength: Integer. Controls drive strength. 0 is weakest. - The range of valid values depends on the pingroup. See "CAL_DRVUP" in the - Tegra TRM. -- nvidia,slew-rate-rising: Integer. Controls rising signal slew rate. 0 is - fastest. The range of valid values depends on the pingroup. See - "DRVDN_SLWR" in the Tegra TRM. -- nvidia,slew-rate-falling: Integer. Controls falling signal slew rate. 0 is - fastest. The range of valid values depends on the pingroup. See - "DRVUP_SLWF" in the Tegra TRM. - -Note that many of these properties are only valid for certain specific pins -or groups. See the Tegra TRM and various pinmux spreadsheets for complete -details regarding which groups support which functionality. The Linux pinctrl -driver may also be a useful reference, since it consolidates, disambiguates, -and corrects data from all those sources. - -Valid values for pin and group names are: - - mux groups: - - These all support nvidia,function, nvidia,tristate, and many support - nvidia,pull. - - ata, atb, atc, atd, ate, cdev1, cdev2, crtp, csus, dap1, dap2, dap3, dap4, - ddc, dta, dtb, dtc, dtd, dte, dtf, gma, gmb, gmc, gmd, gme, gpu, gpu7, - gpv, hdint, i2cp, irrx, irtx, kbca, kbcb, kbcc, kbcd, kbce, kbcf, lcsn, - ld0, ld1, ld2, ld3, ld4, ld5, ld6, ld7, ld8, ld9, ld10, ld11, ld12, ld13, - ld14, ld15, ld16, ld17, ldc, ldi, lhp0, lhp1, lhp2, lhs, lm0, lm1, lpp, - lpw0, lpw1, lpw2, lsc0, lsc1, lsck, lsda, lsdi, lspi, lvp0, lvp1, lvs, - owc, pmc, pta, rm, sdb, sdc, sdd, sdio1, slxa, slxc, slxd, slxk, spdi, - spdo, spia, spib, spic, spid, spie, spif, spig, spih, uaa, uab, uac, uad, - uca, ucb, uda. - - tristate groups: - - These only support nvidia,pull. - - ck32, ddrc, pmca, pmcb, pmcc, pmcd, pmce, xm2c, xm2d, ls, lc, ld17_0, - ld19_18, ld21_20, ld23_22. - - drive groups: - - With some exceptions, these support nvidia,high-speed-mode, - nvidia,schmitt, nvidia,low-power-mode, nvidia,pull-down-strength, - nvidia,pull-up-strength, nvidia,slew-rate-rising, nvidia,slew-rate-falling. - - drive_ao1, drive_ao2, drive_at1, drive_at2, drive_cdev1, drive_cdev2, - drive_csus, drive_dap1, drive_dap2, drive_dap3, drive_dap4, drive_dbg, - drive_lcd1, drive_lcd2, drive_sdmmc2, drive_sdmmc3, drive_spi, drive_uaa, - drive_uab, drive_uart2, drive_uart3, drive_vi1, drive_vi2, drive_xm2a, - drive_xm2c, drive_xm2d, drive_xm2clk, drive_sdio1, drive_crt, drive_ddc, - drive_gma, drive_gmb, drive_gmc, drive_gmd, drive_gme, drive_owr, - drive_uda. - -Valid values for nvidia,functions are: - - ahb_clk, apb_clk, audio_sync, crt, dap1, dap2, dap3, dap4, dap5, - displaya, displayb, emc_test0_dll, emc_test1_dll, gmi, gmi_int, - hdmi, i2cp, i2c1, i2c2, i2c3, ide, irda, kbc, mio, mipi_hs, nand, - osc, owr, pcie, plla_out, pllc_out1, pllm_out1, pllp_out2, pllp_out3, - pllp_out4, pwm, pwr_intr, pwr_on, rsvd1, rsvd2, rsvd3, rsvd4, rtck, - sdio1, sdio2, sdio3, sdio4, sflash, spdif, spi1, spi2, spi2_alt, - spi3, spi4, trace, twc, uarta, uartb, uartc, uartd, uarte, ulpi, - vi, vi_sensor_clk, xio - -Example: - - pinctrl@70000000 { - compatible = "nvidia,tegra20-pinmux"; - reg = < 0x70000014 0x10 /* Tri-state registers */ - 0x70000080 0x20 /* Mux registers */ - 0x700000a0 0x14 /* Pull-up/down registers */ - 0x70000868 0xa8 >; /* Pad control registers */ - }; - -Example board file extract: - - pinctrl@70000000 { - sdio4_default: sdio4_default { - atb { - nvidia,pins = "atb", "gma", "gme"; - nvidia,function = "sdio4"; - nvidia,pull = <0>; - nvidia,tristate = <0>; - }; - }; - }; - - sdhci@c8000600 { - pinctrl-names = "default"; - pinctrl-0 = <&sdio4_default>; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.yaml new file mode 100644 index 000000000000..432ea40209a8 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.yaml @@ -0,0 +1,112 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra20-pinmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra20 Pinmux Controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + const: nvidia,tegra20-pinmux + + reg: + items: + - description: tri-state registers + - description: mux register + - description: pull-up/down registers + - description: pad control registers + +patternProperties: + "^pinmux(-[a-z0-9-_]+)?$": + type: object + properties: + phandle: true + + # pin groups + additionalProperties: + $ref: nvidia,tegra-pinmux-common.yaml + additionalProperties: false + properties: + nvidia,pins: + items: + enum: [ ata, atb, atc, atd, ate, cdev1, cdev2, crtp, csus, dap1, + dap2, dap3, dap4, ddc, dta, dtb, dtc, dtd, dte, dtf, gma, + gmb, gmc, gmd, gme, gpu, gpu7, gpv, hdint, i2cp, irrx, + irtx, kbca, kbcb, kbcc, kbcd, kbce, kbcf, lcsn, ld0, ld1, + ld2, ld3, ld4, ld5, ld6, ld7, ld8, ld9, ld10, ld11, ld12, + ld13, ld14, ld15, ld16, ld17, ldc, ldi, lhp0, lhp1, lhp2, + lhs, lm0, lm1, lpp, lpw0, lpw1, lpw2, lsc0, lsc1, lsck, + lsda, lsdi, lspi, lvp0, lvp1, lvs, owc, pmc, pta, rm, sdb, + sdc, sdd, sdio1, slxa, slxc, slxd, slxk, spdi, spdo, spia, + spib, spic, spid, spie, spif, spig, spih, uaa, uab, uac, + uad, uca, ucb, uda, + # tristate groups + ck32, ddrc, pmca, pmcb, pmcc, pmcd, pmce, xm2c, xm2d, ls, + lc, ld17_0, ld19_18, ld21_20, ld23_22, + # drive groups + drive_ao1, drive_ao2, drive_at1, drive_at2, drive_cdev1, + drive_cdev2, drive_csus, drive_dap1, drive_dap2, + drive_dap3, drive_dap4, drive_dbg, drive_lcd1, drive_lcd2, + drive_sdmmc2, drive_sdmmc3, drive_spi, drive_uaa, + drive_uab, drive_uart2, drive_uart3, drive_vi1, drive_vi2, + drive_xm2a, drive_xm2c, drive_xm2d, drive_xm2clk, + drive_sdio1, drive_crt, drive_ddc, drive_gma, drive_gmb, + drive_gmc, drive_gmd, drive_gme, drive_owr, drive_uda ] + + nvidia,function: + enum: [ ahb_clk, apb_clk, audio_sync, crt, dap1, dap2, dap3, dap4, + dap5, displaya, displayb, emc_test0_dll, emc_test1_dll, gmi, + gmi_int, hdmi, i2cp, i2c1, i2c2, i2c3, ide, irda, kbc, mio, + mipi_hs, nand, osc, owr, pcie, plla_out, pllc_out1, + pllm_out1, pllp_out2, pllp_out3, pllp_out4, pwm, pwr_intr, + pwr_on, rsvd1, rsvd2, rsvd3, rsvd4, rtck, sdio1, sdio2, + sdio3, sdio4, sflash, spdif, spi1, spi2, spi2_alt, spi3, + spi4, trace, twc, uarta, uartb, uartc, uartd, uarte, ulpi, + vi, vi_sensor_clk, xio ] + + nvidia,pull: true + nvidia,tristate: true + nvidia,schmitt: true + nvidia,pull-down-strength: true + nvidia,pull-up-strength: true + nvidia,high-speed-mode: true + nvidia,low-power-mode: true + nvidia,slew-rate-rising: true + nvidia,slew-rate-falling: true + + required: + - nvidia,pins + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + pinctrl@70000000 { + compatible = "nvidia,tegra20-pinmux"; + reg = <0x70000014 0x10>, /* Tri-state registers */ + <0x70000080 0x20>, /* Mux registers */ + <0x700000a0 0x14>, /* Pull-up/down registers */ + <0x70000868 0xa8>; /* Pad control registers */ + + pinmux { + atb { + nvidia,pins = "atb", "gma", "gme"; + nvidia,function = "sdio4"; + nvidia,pull = <0>; + nvidia,tristate = <0>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.txt deleted file mode 100644 index 85f211436b8e..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.txt +++ /dev/null @@ -1,166 +0,0 @@ -NVIDIA Tegra210 pinmux controller - -Required properties: -- compatible: "nvidia,tegra210-pinmux" -- reg: Should contain a list of base address and size pairs for: - - first entry: The APB_MISC_GP_*_PADCTRL registers (pad control) - - second entry: The PINMUX_AUX_* registers (pinmux) - -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". - -Tegra's 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, tristate, drive strength, etc. - -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 or tristate parameter. For this -reason, even seemingly boolean values are actually tristates in this binding: -unspecified, off, or on. Unspecified is represented as an absent property, -and off/on are represented as integer values 0 and 1. - -See the TRM to determine which properties and values apply to each pin/group. -Macro values for property values are defined in -include/dt-binding/pinctrl/pinctrl-tegra.h. - -Required subnode-properties: -- nvidia,pins : An array of strings. Each string contains the name of a pin or - group. Valid values for these names are listed below. - -Optional subnode-properties: -- nvidia,function: A string containing the name of the function to mux to the - pin or group. -- nvidia,pull: Integer, representing the pull-down/up to apply to the pin. - 0: none, 1: down, 2: up. -- nvidia,tristate: Integer. - 0: drive, 1: tristate. -- nvidia,enable-input: Integer. Enable the pin's input path. - enable :TEGRA_PIN_ENABLE and - disable or output only: TEGRA_PIN_DISABLE. -- nvidia,open-drain: Integer. - enable: TEGRA_PIN_ENABLE. - disable: TEGRA_PIN_DISABLE. -- nvidia,lock: Integer. Lock the pin configuration against further changes - until reset. - enable: TEGRA_PIN_ENABLE. - disable: TEGRA_PIN_DISABLE. -- nvidia,io-hv: Integer. Select high-voltage receivers. - normal: TEGRA_PIN_DISABLE - high: TEGRA_PIN_ENABLE -- nvidia,high-speed-mode: Integer. Enable high speed mode the pins. - normal: TEGRA_PIN_DISABLE - high: TEGRA_PIN_ENABLE -- nvidia,schmitt: Integer. Enables Schmitt Trigger on the input. - normal: TEGRA_PIN_DISABLE - high: TEGRA_PIN_ENABLE -- nvidia,drive-type: Integer. Valid range 0...3. -- nvidia,pull-down-strength: Integer. Controls drive strength. 0 is weakest. - The range of valid values depends on the pingroup. See "CAL_DRVDN" in the - Tegra TRM. -- nvidia,pull-up-strength: Integer. Controls drive strength. 0 is weakest. - The range of valid values depends on the pingroup. See "CAL_DRVUP" in the - Tegra TRM. -- nvidia,slew-rate-rising: Integer. Controls rising signal slew rate. 0 is - fastest. The range of valid values depends on the pingroup. See - "DRVDN_SLWR" in the Tegra TRM. -- nvidia,slew-rate-falling: Integer. Controls falling signal slew rate. 0 is - fastest. The range of valid values depends on the pingroup. See - "DRVUP_SLWF" in the Tegra TRM. - -Valid values for pin and group names (nvidia,pin) are: - - Mux groups: - - These correspond to Tegra PINMUX_AUX_* (pinmux) registers. Any property - that exists in those registers may be set for the following pin names. - - In Tegra210, many pins also have a dedicated APB_MISC_GP_*_PADCTRL - register. Where that is true, and property that exists in that register - may also be set on the following pin names. - - als_prox_int_px3, ap_ready_pv5, ap_wake_bt_ph3, ap_wake_nfc_ph7, - aud_mclk_pbb0, batt_bcl, bt_rst_ph4, bt_wake_ap_ph5, button_home_py1, - button_power_on_px5, button_slide_sw_py0, button_vol_down_px7, - button_vol_up_px6, cam1_mclk_ps0, cam1_pwdn_ps7, cam1_strobe_pt1, - cam2_mclk_ps1, cam2_pwdn_pt0, cam_af_en_ps5, cam_flash_en_ps6, - cam_i2c_scl_ps2, cam_i2c_sda_ps3, cam_rst_ps4cam_rst_ps4, clk_32k_in, - clk_32k_out_py5, clk_req, core_pwr_req, cpu_pwr_req, dap1_din_pb1, - dap1_dout_pb2, dap1_fs_pb0, dap1_sclk_pb3, dap2_din_paa2, dap2_dout_paa3, - dap2_fs_paa0, dap2_sclk_paa1, dap4_din_pj5, dap4_dout_pj6, dap4_fs_pj4, - dap4_sclk_pj7, dmic1_clk_pe0, dmic1_dat_pe1, dmic2_clk_pe2, dmic2_dat_pe3, - dmic3_clk_pe4, dmic3_dat_pe5, dp_hpd0_pcc6, dvfs_clk_pbb2, dvfs_pwm_pbb1, - gen1_i2c_scl_pj1, gen1_i2c_sda_pj0, gen2_i2c_scl_pj2, gen2_i2c_sda_pj3, - gen3_i2c_scl_pf0, gen3_i2c_sda_pf1, gpio_x1_aud_pbb3, gpio_x3_aud_pbb4, - gps_en_pi2, gps_rst_pi3, hdmi_cec_pcc0, hdmi_int_dp_hpd_pcc1, jtag_rtck, - lcd_bl_en_pv1, lcd_bl_pwm_pv0, lcd_gpio1_pv3, lcd_gpio2_pv4, lcd_rst_pv2, - lcd_te_py2, modem_wake_ap_px0, motion_int_px2, nfc_en_pi0, nfc_int_pi1, - pa6, pcc7, pe6, pe7, pex_l0_clkreq_n_pa1, pex_l0_rst_n_pa0, - pex_l1_clkreq_n_pa4, pex_l1_rst_n_pa3, pex_wake_n_pa2, ph6, pk0, pk1, pk2, - pk3, pk4, pk5, pk6, pk7, pl0, pl1, pwr_i2c_scl_py3, pwr_i2c_sda_py4, - pwr_int_n, pz0, pz1, pz2, pz3, pz4, pz5, qspi_cs_n_pee1, qspi_io0_pee2, - qspi_io1_pee3, qspi_io2_pee4, qspi_io3_pee5, qspi_sck_pee0, - sata_led_active_pa5, sdmmc1_clk_pm0, sdmmc1_cmd_pm1, sdmmc1_dat0_pm5, - sdmmc1_dat1_pm4, sdmmc1_dat2_pm3, sdmmc1_dat3_pm2, sdmmc3_clk_pp0, - sdmmc3_cmd_pp1, sdmmc3_dat0_pp5, sdmmc3_dat1_pp4, sdmmc3_dat2_pp3, - sdmmc3_dat3_pp2, shutdown, spdif_in_pcc3, spdif_out_pcc2, spi1_cs0_pc3, - spi1_cs1_pc4, spi1_miso_pc1, spi1_mosi_pc0, spi1_sck_pc2, spi2_cs0_pb7, - spi2_cs1_pdd0, spi2_miso_pb5, spi2_mosi_pb4, spi2_sck_pb6, spi4_cs0_pc6, - spi4_miso_pd0, spi4_mosi_pc7, spi4_sck_pc5, temp_alert_px4, touch_clk_pv7, - touch_int_px1, touch_rst_pv6, uart1_cts_pu3, uart1_rts_pu2, uart1_rx_pu1, - uart1_tx_pu0, uart2_cts_pg3, uart2_rts_pg2, uart2_rx_pg1, uart2_tx_pg0, - uart3_cts_pd4, uart3_rts_pd3, uart3_rx_pd2, uart3_tx_pd1, uart4_cts_pi7, - uart4_rts_pi6, uart4_rx_pi5, uart4_tx_pi4, usb_vbus_en0_pcc4, - usb_vbus_en1_pcc5, wifi_en_ph0, wifi_rst_ph1, wifi_wake_ap_ph2 - - Drive groups: - - These correspond to the Tegra APB_MISC_GP_*_PADCTRL (pad control) - registers. Note that where one of these registers controls a single pin - for which a PINMUX_AUX_* exists, see the list above for the pin name to - use when configuring the pinmux. - - pa6, pcc7, pe6, pe7, ph6, pk0, pk1, pk2, pk3, pk4, pk5, pk6, pk7, pl0, pl1, - pz0, pz1, pz2, pz3, pz4, pz5, sdmmc1, sdmmc2, sdmmc3, sdmmc4 - -Valid values for nvidia,functions are: - - aud, bcl, blink, ccla, cec, cldvfs, clk, core, cpu, displaya, displayb, - dmic1, dmic2, dmic3, dp, dtv, extperiph3, i2c1, i2c2, i2c3, i2cpmu, i2cvi, - i2s1, i2s2, i2s3, i2s4a, i2s4b, i2s5a, i2s5b, iqc0, iqc1, jtag, pe, pe0, - pe1, pmi, pwm0, pwm1, pwm2, pwm3, qspi, rsvd0, rsvd1, rsvd2, rsvd3, sata, - sdmmc1, sdmmc3, shutdown, soc, sor0, sor1, spdif, spi1, spi2, spi3, spi4, - sys, touch, uart, uarta, uartb, uartc, uartd, usb, vgp1, vgp2, vgp3, vgp4, - vgp5, vgp6, vimclk, vimclk2 - -Example: - - pinmux: pinmux@70000800 { - compatible = "nvidia,tegra210-pinmux"; - reg = <0x0 0x700008d4 0x0 0x2a8>, /* Pad control registers */ - <0x0 0x70003000 0x0 0x1000>; /* Mux registers */ - - pinctrl-names = "boot"; - pinctrl-0 = <&state_boot>; - - state_boot: pinmux { - gen1_i2c_scl_pj1 { - nvidia,pins = "gen1_i2c_scl_pj1", - nvidia,function = "i2c1"; - nvidia,pull = <TEGRA_PIN_PULL_NONE>; - nvidia,tristate = <TEGRA_PIN_DISABLE>; - nvidia,enable-input = <TEGRA_PIN_ENABLE>; - nvidia,open-drain = <TEGRA_PIN_ENABLE>; - nvidia,io-hv = <TEGRA_PIN_ENABLE>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml new file mode 100644 index 000000000000..28ae2e6d0cbc --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml @@ -0,0 +1,142 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra210-pinmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra210 Pinmux Controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + const: nvidia,tegra210-pinmux + + reg: + items: + - description: APB_MISC_GP_*_PADCTRL register (pad control) + - description: PINMUX_AUX_* registers (pinmux) + +patternProperties: + "^pinmux(-[a-z0-9-_]+)?$": + type: object + properties: + phandle: true + + # pin groups + additionalProperties: + $ref: nvidia,tegra-pinmux-common.yaml + additionalProperties: false + properties: + nvidia,pins: + items: + enum: [ als_prox_int_px3, ap_ready_pv5, ap_wake_bt_ph3, + ap_wake_nfc_ph7, aud_mclk_pbb0, batt_bcl, bt_rst_ph4, + bt_wake_ap_ph5, button_home_py1, button_power_on_px5, + button_slide_sw_py0, button_vol_down_px7, + button_vol_up_px6, cam1_mclk_ps0, cam1_pwdn_ps7, + cam1_strobe_pt1, cam2_mclk_ps1, cam2_pwdn_pt0, + cam_af_en_ps5, cam_flash_en_ps6, cam_i2c_scl_ps2, + cam_i2c_sda_ps3, cam_rst_ps4, clk_32k_in, clk_32k_out_py5, + clk_req, core_pwr_req, cpu_pwr_req, dap1_din_pb1, + dap1_dout_pb2, dap1_fs_pb0, dap1_sclk_pb3, dap2_din_paa2, + dap2_dout_paa3, dap2_fs_paa0, dap2_sclk_paa1, dap4_din_pj5, + dap4_dout_pj6, dap4_fs_pj4, dap4_sclk_pj7, dmic1_clk_pe0, + dmic1_dat_pe1, dmic2_clk_pe2, dmic2_dat_pe3, dmic3_clk_pe4, + dmic3_dat_pe5, dp_hpd0_pcc6, dvfs_clk_pbb2, dvfs_pwm_pbb1, + gen1_i2c_scl_pj1, gen1_i2c_sda_pj0, gen2_i2c_scl_pj2, + gen2_i2c_sda_pj3, gen3_i2c_scl_pf0, gen3_i2c_sda_pf1, + gpio_x1_aud_pbb3, gpio_x3_aud_pbb4, gps_en_pi2, + gps_rst_pi3, hdmi_cec_pcc0, hdmi_int_dp_hpd_pcc1, + jtag_rtck, lcd_bl_en_pv1, lcd_bl_pwm_pv0, lcd_gpio1_pv3, + lcd_gpio2_pv4, lcd_rst_pv2, lcd_te_py2, modem_wake_ap_px0, + motion_int_px2, nfc_en_pi0, nfc_int_pi1, pa6, pcc7, pe6, + pe7, pex_l0_clkreq_n_pa1, pex_l0_rst_n_pa0, + pex_l1_clkreq_n_pa4, pex_l1_rst_n_pa3, pex_wake_n_pa2, ph6, + pk0, pk1, pk2, pk3, pk4, pk5, pk6, pk7, pl0, pl1, + pwr_i2c_scl_py3, pwr_i2c_sda_py4, pwr_int_n, pz0, pz1, pz2, + pz3, pz4, pz5, qspi_cs_n_pee1, qspi_io0_pee2, + qspi_io1_pee3, qspi_io2_pee4, qspi_io3_pee5, qspi_sck_pee0, + sata_led_active_pa5, sdmmc1_clk_pm0, sdmmc1_cmd_pm1, + sdmmc1_dat0_pm5, sdmmc1_dat1_pm4, sdmmc1_dat2_pm3, + sdmmc1_dat3_pm2, sdmmc3_clk_pp0, sdmmc3_cmd_pp1, + sdmmc3_dat0_pp5, sdmmc3_dat1_pp4, sdmmc3_dat2_pp3, + sdmmc3_dat3_pp2, shutdown, spdif_in_pcc3, spdif_out_pcc2, + spi1_cs0_pc3, spi1_cs1_pc4, spi1_miso_pc1, spi1_mosi_pc0, + spi1_sck_pc2, spi2_cs0_pb7, spi2_cs1_pdd0, spi2_miso_pb5, + spi2_mosi_pb4, spi2_sck_pb6, spi4_cs0_pc6, spi4_miso_pd0, + spi4_mosi_pc7, spi4_sck_pc5, temp_alert_px4, touch_clk_pv7, + touch_int_px1, touch_rst_pv6, uart1_cts_pu3, uart1_rts_pu2, + uart1_rx_pu1, uart1_tx_pu0, uart2_cts_pg3, uart2_rts_pg2, + uart2_rx_pg1, uart2_tx_pg0, uart3_cts_pd4, uart3_rts_pd3, + uart3_rx_pd2, uart3_tx_pd1, uart4_cts_pi7, uart4_rts_pi6, + uart4_rx_pi5, uart4_tx_pi4, usb_vbus_en0_pcc4, + usb_vbus_en1_pcc5, wifi_en_ph0, wifi_rst_ph1, + wifi_wake_ap_ph2, + # drive groups + drive_pa6, drive_pcc7, drive_pe6, drive_pe7, drive_ph6, + drive_pk0, drive_pk1, drive_pk2, drive_pk3, drive_pk4, + drive_pk5, drive_pk6, drive_pk7, drive_pl0, drive_pl1, + drive_pz0, drive_pz1, drive_pz2, drive_pz3, drive_pz4, + drive_pz5, drive_sdmmc1, drive_sdmmc2, drive_sdmmc3, + drive_sdmmc4 ] + + nvidia,function: + enum: [ aud, bcl, blink, ccla, cec, cldvfs, clk, core, cpu, displaya, + displayb, dmic1, dmic2, dmic3, dp, dtv, extperiph3, i2c1, + i2c2, i2c3, i2cpmu, i2cvi, i2s1, i2s2, i2s3, i2s4a, i2s4b, + i2s5a, i2s5b, iqc0, iqc1, jtag, pe, pe0, pe1, pmi, pwm0, + pwm1, pwm2, pwm3, qspi, rsvd0, rsvd1, rsvd2, rsvd3, sata, + sdmmc1, sdmmc3, shutdown, soc, sor0, sor1, spdif, spi1, spi2, + spi3, spi4, sys, touch, uart, uarta, uartb, uartc, uartd, + usb, vgp1, vgp2, vgp3, vgp4, vgp5, vgp6, vimclk, vimclk2 ] + + nvidia,pull: true + nvidia,tristate: true + nvidia,pull-down-strength: true + nvidia,pull-up-strength: true + nvidia,high-speed-mode: true + nvidia,enable-input: true + nvidia,open-drain: true + nvidia,lock: true + nvidia,drive-type: true + nvidia,io-hv: true + nvidia,slew-rate-rising: true + nvidia,slew-rate-falling: true + + required: + - nvidia,pins + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + #include <dt-bindings/pinctrl/pinctrl-tegra.h> + + pinmux: pinmux@70000800 { + compatible = "nvidia,tegra210-pinmux"; + reg = <0x700008d4 0x02a8>, /* Pad control registers */ + <0x70003000 0x1000>; /* Mux registers */ + + pinctrl-names = "boot"; + pinctrl-0 = <&state_boot>; + + state_boot: pinmux { + gen1_i2c_scl_pj1 { + nvidia,pins = "gen1_i2c_scl_pj1"; + nvidia,function = "i2c1"; + nvidia,pull = <TEGRA_PIN_PULL_NONE>; + nvidia,tristate = <TEGRA_PIN_DISABLE>; + nvidia,enable-input = <TEGRA_PIN_ENABLE>; + nvidia,open-drain = <TEGRA_PIN_ENABLE>; + nvidia,io-hv = <TEGRA_PIN_ENABLE>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt deleted file mode 100644 index 0e6354c11e6d..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt +++ /dev/null @@ -1,144 +0,0 @@ -NVIDIA Tegra30 pinmux controller - -The Tegra30 pinctrl binding is very similar to the Tegra20 pinctrl binding, -as described in nvidia,tegra20-pinmux.txt. In fact, this document assumes -that binding as a baseline, and only documents the differences between the -two bindings. - -Required properties: -- compatible: "nvidia,tegra30-pinmux" -- reg: Should contain the register physical address and length for each of - the pad control and mux registers. - -Tegra30 adds the following optional properties for pin configuration subnodes: -- nvidia,enable-input: Integer. Enable the pin's input path. 0: no, 1: yes. -- nvidia,open-drain: Integer. Enable open drain mode. 0: no, 1: yes. -- nvidia,lock: Integer. Lock the pin configuration against further changes - until reset. 0: no, 1: yes. -- nvidia,io-reset: Integer. Reset the IO path. 0: no, 1: yes. - -As with Tegra20, see the Tegra TRM for complete details regarding which groups -support which functionality. - -Valid values for pin and group names are: - - per-pin mux groups: - - These all support nvidia,function, nvidia,tristate, nvidia,pull, - nvidia,enable-input, nvidia,lock. Some support nvidia,open-drain, - nvidia,io-reset. - - clk_32k_out_pa0, uart3_cts_n_pa1, dap2_fs_pa2, dap2_sclk_pa3, - dap2_din_pa4, dap2_dout_pa5, sdmmc3_clk_pa6, sdmmc3_cmd_pa7, gmi_a17_pb0, - gmi_a18_pb1, lcd_pwr0_pb2, lcd_pclk_pb3, sdmmc3_dat3_pb4, sdmmc3_dat2_pb5, - sdmmc3_dat1_pb6, sdmmc3_dat0_pb7, uart3_rts_n_pc0, lcd_pwr1_pc1, - uart2_txd_pc2, uart2_rxd_pc3, gen1_i2c_scl_pc4, gen1_i2c_sda_pc5, - lcd_pwr2_pc6, gmi_wp_n_pc7, sdmmc3_dat5_pd0, sdmmc3_dat4_pd1, lcd_dc1_pd2, - sdmmc3_dat6_pd3, sdmmc3_dat7_pd4, vi_d1_pd5, vi_vsync_pd6, vi_hsync_pd7, - lcd_d0_pe0, lcd_d1_pe1, lcd_d2_pe2, lcd_d3_pe3, lcd_d4_pe4, lcd_d5_pe5, - lcd_d6_pe6, lcd_d7_pe7, lcd_d8_pf0, lcd_d9_pf1, lcd_d10_pf2, lcd_d11_pf3, - lcd_d12_pf4, lcd_d13_pf5, lcd_d14_pf6, lcd_d15_pf7, gmi_ad0_pg0, - gmi_ad1_pg1, gmi_ad2_pg2, gmi_ad3_pg3, gmi_ad4_pg4, gmi_ad5_pg5, - gmi_ad6_pg6, gmi_ad7_pg7, gmi_ad8_ph0, gmi_ad9_ph1, gmi_ad10_ph2, - gmi_ad11_ph3, gmi_ad12_ph4, gmi_ad13_ph5, gmi_ad14_ph6, gmi_ad15_ph7, - gmi_wr_n_pi0, gmi_oe_n_pi1, gmi_dqs_pi2, gmi_cs6_n_pi3, gmi_rst_n_pi4, - gmi_iordy_pi5, gmi_cs7_n_pi6, gmi_wait_pi7, gmi_cs0_n_pj0, lcd_de_pj1, - gmi_cs1_n_pj2, lcd_hsync_pj3, lcd_vsync_pj4, uart2_cts_n_pj5, - uart2_rts_n_pj6, gmi_a16_pj7, gmi_adv_n_pk0, gmi_clk_pk1, gmi_cs4_n_pk2, - gmi_cs2_n_pk3, gmi_cs3_n_pk4, spdif_out_pk5, spdif_in_pk6, gmi_a19_pk7, - vi_d2_pl0, vi_d3_pl1, vi_d4_pl2, vi_d5_pl3, vi_d6_pl4, vi_d7_pl5, - vi_d8_pl6, vi_d9_pl7, lcd_d16_pm0, lcd_d17_pm1, lcd_d18_pm2, lcd_d19_pm3, - lcd_d20_pm4, lcd_d21_pm5, lcd_d22_pm6, lcd_d23_pm7, dap1_fs_pn0, - dap1_din_pn1, dap1_dout_pn2, dap1_sclk_pn3, lcd_cs0_n_pn4, lcd_sdout_pn5, - lcd_dc0_pn6, hdmi_int_pn7, ulpi_data7_po0, ulpi_data0_po1, ulpi_data1_po2, - ulpi_data2_po3, ulpi_data3_po4, ulpi_data4_po5, ulpi_data5_po6, - ulpi_data6_po7, dap3_fs_pp0, dap3_din_pp1, dap3_dout_pp2, dap3_sclk_pp3, - dap4_fs_pp4, dap4_din_pp5, dap4_dout_pp6, dap4_sclk_pp7, kb_col0_pq0, - kb_col1_pq1, kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5, - kb_col6_pq6, kb_col7_pq7, kb_row0_pr0, kb_row1_pr1, kb_row2_pr2, - kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, kb_row6_pr6, kb_row7_pr7, - kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_row11_ps3, kb_row12_ps4, - kb_row13_ps5, kb_row14_ps6, kb_row15_ps7, vi_pclk_pt0, vi_mclk_pt1, - vi_d10_pt2, vi_d11_pt3, vi_d0_pt4, gen2_i2c_scl_pt5, gen2_i2c_sda_pt6, - sdmmc4_cmd_pt7, pu0, pu1, pu2, pu3, pu4, pu5, pu6, jtag_rtck_pu7, pv0, - pv1, pv2, pv3, ddc_scl_pv4, ddc_sda_pv5, crt_hsync_pv6, crt_vsync_pv7, - lcd_cs1_n_pw0, lcd_m1_pw1, spi2_cs1_n_pw2, spi2_cs2_n_pw3, clk1_out_pw4, - clk2_out_pw5, uart3_txd_pw6, uart3_rxd_pw7, spi2_mosi_px0, spi2_miso_px1, - spi2_sck_px2, spi2_cs0_n_px3, spi1_mosi_px4, spi1_sck_px5, spi1_cs0_n_px6, - spi1_miso_px7, ulpi_clk_py0, ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3, - sdmmc1_dat3_py4, sdmmc1_dat2_py5, sdmmc1_dat1_py6, sdmmc1_dat0_py7, - sdmmc1_clk_pz0, sdmmc1_cmd_pz1, lcd_sdin_pz2, lcd_wr_n_pz3, lcd_sck_pz4, - sys_clk_req_pz5, pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, sdmmc4_dat0_paa0, - sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, sdmmc4_dat3_paa3, sdmmc4_dat4_paa4, - sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, sdmmc4_dat7_paa7, pbb0, - cam_i2c_scl_pbb1, cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6, pbb7, - cam_mclk_pcc0, pcc1, pcc2, sdmmc4_rst_n_pcc3, sdmmc4_clk_pcc4, - clk2_req_pcc5, pex_l2_rst_n_pcc6, pex_l2_clkreq_n_pcc7, - pex_l0_prsnt_n_pdd0, pex_l0_rst_n_pdd1, pex_l0_clkreq_n_pdd2, - pex_wake_n_pdd3, pex_l1_prsnt_n_pdd4, pex_l1_rst_n_pdd5, - pex_l1_clkreq_n_pdd6, pex_l2_prsnt_n_pdd7, clk3_out_pee0, clk3_req_pee1, - clk1_req_pee2, hdmi_cec_pee3, clk_32k_in, core_pwr_req, cpu_pwr_req, owr, - pwr_int_n. - - drive groups: - - These all support nvidia,pull-down-strength, nvidia,pull-up-strength, - nvidia,slew-rate-rising, nvidia,slew-rate-falling. Most but not all - support nvidia,high-speed-mode, nvidia,schmitt, nvidia,low-power-mode. - - ao1, ao2, at1, at2, at3, at4, at5, cdev1, cdev2, cec, crt, csus, dap1, - dap2, dap3, dap4, dbg, ddc, dev3, gma, gmb, gmc, gmd, gme, gmf, gmg, - gmh, gpv, lcd1, lcd2, owr, sdio1, sdio2, sdio3, spi, uaa, uab, uart2, - uart3, uda, vi1. - -Valid values for nvidia,functions are: - - blink, cec, clk_12m_out, clk_32k_in, core_pwr_req, cpu_pwr_req, crt, - dap, ddr, dev3, displaya, displayb, dtv, extperiph1, extperiph2, - extperiph3, gmi, gmi_alt, hda, hdcp, hdmi, hsi, i2c1, i2c2, i2c3, - i2c4, i2cpwr, i2s0, i2s1, i2s2, i2s3, i2s4, invalid, kbc, mio, nand, - nand_alt, owr, pcie, pwm0, pwm1, pwm2, pwm3, pwr_int_n, rsvd1, rsvd2, - rsvd3, rsvd4, rtck, sata, sdmmc1, sdmmc2, sdmmc3, sdmmc4, spdif, spi1, - spi2, spi2_alt, spi3, spi4, spi5, spi6, sysclk, test, trace, uarta, - uartb, uartc, uartd, uarte, ulpi, vgp1, vgp2, vgp3, vgp4, vgp5, vgp6, - vi, vi_alt1, vi_alt2, vi_alt3 - -Example: - - pinctrl@70000000 { - compatible = "nvidia,tegra30-pinmux"; - reg = < 0x70000868 0xd0 /* Pad control registers */ - 0x70003000 0x3e0 >; /* Mux registers */ - }; - -Example board file extract: - - pinctrl@70000000 { - sdmmc4_default: pinmux { - sdmmc4_clk_pcc4 { - nvidia,pins = "sdmmc4_clk_pcc4", - "sdmmc4_rst_n_pcc3"; - nvidia,function = "sdmmc4"; - nvidia,pull = <0>; - nvidia,tristate = <0>; - }; - sdmmc4_dat0_paa0 { - nvidia,pins = "sdmmc4_dat0_paa0", - "sdmmc4_dat1_paa1", - "sdmmc4_dat2_paa2", - "sdmmc4_dat3_paa3", - "sdmmc4_dat4_paa4", - "sdmmc4_dat5_paa5", - "sdmmc4_dat6_paa6", - "sdmmc4_dat7_paa7"; - nvidia,function = "sdmmc4"; - nvidia,pull = <2>; - nvidia,tristate = <0>; - }; - }; - }; - - sdhci@78000400 { - pinctrl-names = "default"; - pinctrl-0 = <&sdmmc4_default>; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.yaml new file mode 100644 index 000000000000..c0eda7848767 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.yaml @@ -0,0 +1,176 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra30-pinmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra30 pinmux Controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + const: nvidia,tegra30-pinmux + + reg: + items: + - description: pad control registers + - description: mux registers + +patternProperties: + "^pinmux(-[a-z0-9-_]+)?$": + type: object + properties: + phandle: true + + # pin groups + additionalProperties: + $ref: nvidia,tegra-pinmux-common.yaml + additionalProperties: false + properties: + nvidia,pins: + items: + enum: [ clk_32k_out_pa0, uart3_cts_n_pa1, dap2_fs_pa2, + dap2_sclk_pa3, dap2_din_pa4, dap2_dout_pa5, sdmmc3_clk_pa6, + sdmmc3_cmd_pa7, gmi_a17_pb0, gmi_a18_pb1, lcd_pwr0_pb2, + lcd_pclk_pb3, sdmmc3_dat3_pb4, sdmmc3_dat2_pb5, + sdmmc3_dat1_pb6, sdmmc3_dat0_pb7, uart3_rts_n_pc0, + lcd_pwr1_pc1, uart2_txd_pc2, uart2_rxd_pc3, + gen1_i2c_scl_pc4, gen1_i2c_sda_pc5, lcd_pwr2_pc6, + gmi_wp_n_pc7, sdmmc3_dat5_pd0, sdmmc3_dat4_pd1, + lcd_dc1_pd2, sdmmc3_dat6_pd3, sdmmc3_dat7_pd4, vi_d1_pd5, + vi_vsync_pd6, vi_hsync_pd7, lcd_d0_pe0, lcd_d1_pe1, + lcd_d2_pe2, lcd_d3_pe3, lcd_d4_pe4, lcd_d5_pe5, lcd_d6_pe6, + lcd_d7_pe7, lcd_d8_pf0, lcd_d9_pf1, lcd_d10_pf2, + lcd_d11_pf3, lcd_d12_pf4, lcd_d13_pf5, lcd_d14_pf6, + lcd_d15_pf7, gmi_ad0_pg0, gmi_ad1_pg1, gmi_ad2_pg2, + gmi_ad3_pg3, gmi_ad4_pg4, gmi_ad5_pg5, gmi_ad6_pg6, + gmi_ad7_pg7, gmi_ad8_ph0, gmi_ad9_ph1, gmi_ad10_ph2, + gmi_ad11_ph3, gmi_ad12_ph4, gmi_ad13_ph5, gmi_ad14_ph6, + gmi_ad15_ph7, gmi_wr_n_pi0, gmi_oe_n_pi1, gmi_dqs_pi2, + gmi_cs6_n_pi3, gmi_rst_n_pi4, gmi_iordy_pi5, gmi_cs7_n_pi6, + gmi_wait_pi7, gmi_cs0_n_pj0, lcd_de_pj1, gmi_cs1_n_pj2, + lcd_hsync_pj3, lcd_vsync_pj4, uart2_cts_n_pj5, + uart2_rts_n_pj6, gmi_a16_pj7, gmi_adv_n_pk0, gmi_clk_pk1, + gmi_cs4_n_pk2, gmi_cs2_n_pk3, gmi_cs3_n_pk4, spdif_out_pk5, + spdif_in_pk6, gmi_a19_pk7, vi_d2_pl0, vi_d3_pl1, vi_d4_pl2, + vi_d5_pl3, vi_d6_pl4, vi_d7_pl5, vi_d8_pl6, vi_d9_pl7, + lcd_d16_pm0, lcd_d17_pm1, lcd_d18_pm2, lcd_d19_pm3, + lcd_d20_pm4, lcd_d21_pm5, lcd_d22_pm6, lcd_d23_pm7, + dap1_fs_pn0, dap1_din_pn1, dap1_dout_pn2, dap1_sclk_pn3, + lcd_cs0_n_pn4, lcd_sdout_pn5, lcd_dc0_pn6, hdmi_int_pn7, + ulpi_data7_po0, ulpi_data0_po1, ulpi_data1_po2, + ulpi_data2_po3, ulpi_data3_po4, ulpi_data4_po5, + ulpi_data5_po6, ulpi_data6_po7, dap3_fs_pp0, dap3_din_pp1, + dap3_dout_pp2, dap3_sclk_pp3, dap4_fs_pp4, dap4_din_pp5, + dap4_dout_pp6, dap4_sclk_pp7, kb_col0_pq0, kb_col1_pq1, + kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5, + kb_col6_pq6, kb_col7_pq7, kb_row0_pr0, kb_row1_pr1, + kb_row2_pr2, kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, + kb_row6_pr6, kb_row7_pr7, kb_row8_ps0, kb_row9_ps1, + kb_row10_ps2, kb_row11_ps3, kb_row12_ps4, kb_row13_ps5, + kb_row14_ps6, kb_row15_ps7, vi_pclk_pt0, vi_mclk_pt1, + vi_d10_pt2, vi_d11_pt3, vi_d0_pt4, gen2_i2c_scl_pt5, + gen2_i2c_sda_pt6, sdmmc4_cmd_pt7, pu0, pu1, pu2, pu3, pu4, + pu5, pu6, jtag_rtck_pu7, pv0, pv1, pv2, pv3, ddc_scl_pv4, + ddc_sda_pv5, crt_hsync_pv6, crt_vsync_pv7, lcd_cs1_n_pw0, + lcd_m1_pw1, spi2_cs1_n_pw2, spi2_cs2_n_pw3, clk1_out_pw4, + clk2_out_pw5, uart3_txd_pw6, uart3_rxd_pw7, spi2_mosi_px0, + spi2_miso_px1, spi2_sck_px2, spi2_cs0_n_px3, spi1_mosi_px4, + spi1_sck_px5, spi1_cs0_n_px6, spi1_miso_px7, ulpi_clk_py0, + ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3, sdmmc1_dat3_py4, + sdmmc1_dat2_py5, sdmmc1_dat1_py6, sdmmc1_dat0_py7, + sdmmc1_clk_pz0, sdmmc1_cmd_pz1, lcd_sdin_pz2, lcd_wr_n_pz3, + lcd_sck_pz4, sys_clk_req_pz5, pwr_i2c_scl_pz6, + pwr_i2c_sda_pz7, sdmmc4_dat0_paa0, sdmmc4_dat1_paa1, + sdmmc4_dat2_paa2, sdmmc4_dat3_paa3, sdmmc4_dat4_paa4, + sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, sdmmc4_dat7_paa7, pbb0, + cam_i2c_scl_pbb1, cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6, + pbb7, cam_mclk_pcc0, pcc1, pcc2, sdmmc4_rst_n_pcc3, + sdmmc4_clk_pcc4, clk2_req_pcc5, pex_l2_rst_n_pcc6, + pex_l2_clkreq_n_pcc7, pex_l0_prsnt_n_pdd0, + pex_l0_rst_n_pdd1, pex_l0_clkreq_n_pdd2, pex_wake_n_pdd3, + pex_l1_prsnt_n_pdd4, pex_l1_rst_n_pdd5, + pex_l1_clkreq_n_pdd6, pex_l2_prsnt_n_pdd7, clk3_out_pee0, + clk3_req_pee1, clk1_req_pee2, hdmi_cec_pee3, clk_32k_in, + core_pwr_req, cpu_pwr_req, owr, pwr_int_n, + # drive groups + drive_ao1, drive_ao2, drive_at1, drive_at2, drive_at3, + drive_at4, drive_at5, drive_cdev1, drive_cdev2, drive_cec, + drive_crt, drive_csus, drive_dap1, drive_dap2, drive_dap3, + drive_dap4, drive_dbg, drive_ddc, drive_dev3, drive_gma, + drive_gmb, drive_gmc, drive_gmd, drive_gme, drive_gmf, + drive_gmg, drive_gmh, drive_gpv, drive_lcd1, drive_lcd2, + drive_owr, drive_sdio1, drive_sdio2, drive_sdio3, + drive_spi, drive_uaa, drive_uab, drive_uart2, drive_uart3, + drive_uda, drive_vi1 ] + + nvidia,function: + enum: [ blink, cec, clk_12m_out, clk_32k_in, core_pwr_req, + cpu_pwr_req, crt, dap, ddr, dev3, displaya, displayb, dtv, + extperiph1, extperiph2, extperiph3, gmi, gmi_alt, hda, hdcp, + hdmi, hsi, i2c1, i2c2, i2c3, i2c4, i2cpwr, i2s0, i2s1, i2s2, + i2s3, i2s4, invalid, kbc, mio, nand, nand_alt, owr, pcie, + pwm0, pwm1, pwm2, pwm3, pwr_int_n, rsvd1, rsvd2, rsvd3, + rsvd4, rtck, sata, sdmmc1, sdmmc2, sdmmc3, sdmmc4, spdif, + spi1, spi2, spi2_alt, spi3, spi4, spi5, spi6, sysclk, test, + trace, uarta, uartb, uartc, uartd, uarte, ulpi, vgp1, vgp2, + vgp3, vgp4, vgp5, vgp6, vi, vi_alt1, vi_alt2, vi_alt3 ] + + nvidia,pull: true + nvidia,tristate: true + nvidia,schmitt: true + nvidia,pull-down-strength: true + nvidia,pull-up-strength: true + nvidia,high-speed-mode: true + nvidia,low-power-mode: true + nvidia,enable-input: true + nvidia,open-drain: true + nvidia,lock: true + nvidia,io-reset: true + nvidia,slew-rate-rising: true + nvidia,slew-rate-falling: true + + required: + - nvidia,pins + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + pinctrl@70000000 { + compatible = "nvidia,tegra30-pinmux"; + reg = <0x70000868 0x0d0>, /* Pad control registers */ + <0x70003000 0x3e0>; /* Mux registers */ + + pinmux { + sdmmc4_clk_pcc4 { + nvidia,pins = "sdmmc4_clk_pcc4", + "sdmmc4_rst_n_pcc3"; + nvidia,function = "sdmmc4"; + nvidia,pull = <0>; + nvidia,tristate = <0>; + }; + + sdmmc4_dat0_paa0 { + nvidia,pins = "sdmmc4_dat0_paa0", + "sdmmc4_dat1_paa1", + "sdmmc4_dat2_paa2", + "sdmmc4_dat3_paa3", + "sdmmc4_dat4_paa4", + "sdmmc4_dat5_paa5", + "sdmmc4_dat6_paa6", + "sdmmc4_dat7_paa7"; + nvidia,function = "sdmmc4"; + nvidia,pull = <2>; + nvidia,tristate = <0>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml index 1e2b9b627b12..2722dc7bb03d 100644 --- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml @@ -274,10 +274,6 @@ patternProperties: slew-rate: enum: [0, 1] - output-enable: - description: - This will internally disable the tri-state for MIO pins. - drive-strength: description: Selects the drive strength for MIO pins, in mA. diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml index 58022ae7d5dd..dfdb8dfb6b65 100644 --- a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml @@ -81,6 +81,9 @@ properties: power-supply: true + power-domains: + maxItems: 1 + resets: description: | A number of phandles to resets that need to be asserted during diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index 5b4eda919911..633d49884019 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -28,15 +28,18 @@ properties: - qcom,msm8998-rpmpd - qcom,qcm2290-rpmpd - qcom,qcs404-rpmpd + - qcom,qdu1000-rpmhpd - qcom,sa8540p-rpmhpd - qcom,sdm660-rpmpd - qcom,sc7180-rpmhpd - qcom,sc7280-rpmhpd - qcom,sc8180x-rpmhpd - qcom,sc8280xp-rpmhpd + - qcom,sdm670-rpmhpd - qcom,sdm845-rpmhpd - qcom,sdx55-rpmhpd - qcom,sdx65-rpmhpd + - qcom,sm4250-rpmpd - qcom,sm6115-rpmpd - qcom,sm6125-rpmpd - qcom,sm6350-rpmhpd @@ -45,6 +48,7 @@ properties: - qcom,sm8250-rpmhpd - qcom,sm8350-rpmhpd - qcom,sm8450-rpmhpd + - qcom,sm8550-rpmhpd '#power-domain-cells': const: 1 diff --git a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml index 4cc3cc7c50be..66e400f2a3a4 100644 --- a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml @@ -25,7 +25,9 @@ properties: - const: allwinner,sun8i-a83t-pwm - const: allwinner,sun8i-h3-pwm - items: - - const: allwinner,sun8i-v3s-pwm + - enum: + - allwinner,suniv-f1c100s-pwm + - allwinner,sun8i-v3s-pwm - const: allwinner,sun7i-a20-pwm - items: - const: allwinner,sun50i-a64-pwm diff --git a/Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml b/Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml index a7fae1772a81..cd8e9a8907f8 100644 --- a/Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml +++ b/Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml @@ -30,7 +30,9 @@ properties: maxItems: 1 "#pwm-cells": - const: 2 + enum: [2, 3] + description: + The only flag supported by the controller is PWM_POLARITY_INVERTED. microchip,sync-update-mask: description: | diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt deleted file mode 100644 index 74c41e34c3b6..000000000000 --- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt +++ /dev/null @@ -1,77 +0,0 @@ -Tegra SoC PWFM controller - -Required properties: -- compatible: Must be: - - "nvidia,tegra20-pwm": for Tegra20 - - "nvidia,tegra30-pwm", "nvidia,tegra20-pwm": for Tegra30 - - "nvidia,tegra114-pwm", "nvidia,tegra20-pwm": for Tegra114 - - "nvidia,tegra124-pwm", "nvidia,tegra20-pwm": for Tegra124 - - "nvidia,tegra132-pwm", "nvidia,tegra20-pwm": for Tegra132 - - "nvidia,tegra210-pwm", "nvidia,tegra20-pwm": for Tegra210 - - "nvidia,tegra186-pwm": for Tegra186 - - "nvidia,tegra194-pwm": for Tegra194 -- reg: physical base address and length of the controller's registers -- #pwm-cells: should be 2. See pwm.yaml in this directory for a description of - the cells format. -- clocks: Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. -- resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names: Must include the following entries: - - pwm - -Optional properties: -============================ -In some of the interface like PWM based regulator device, it is required -to configure the pins differently in different states, especially in suspend -state of the system. The configuration of pin is provided via the pinctrl -DT node as detailed in the pinctrl DT binding document - Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt - -The PWM node will have following optional properties. -pinctrl-names: Pin state names. Must be "default" and "sleep". -pinctrl-0: phandle for the default/active state of pin configurations. -pinctrl-1: phandle for the sleep state of pin configurations. - -Example: - - pwm: pwm@7000a000 { - compatible = "nvidia,tegra20-pwm"; - reg = <0x7000a000 0x100>; - #pwm-cells = <2>; - clocks = <&tegra_car 17>; - resets = <&tegra_car 17>; - reset-names = "pwm"; - }; - - -Example with the pin configuration for suspend and resume: -========================================================= -Suppose pin PE7 (On Tegra210) interfaced with the regulator device and -it requires PWM output to be tristated when system enters suspend. -Following will be DT binding to achieve this: - -#include <dt-bindings/pinctrl/pinctrl-tegra.h> - - pinmux@700008d4 { - pwm_active_state: pwm_active_state { - pe7 { - nvidia,pins = "pe7"; - nvidia,tristate = <TEGRA_PIN_DISABLE>; - }; - }; - - pwm_sleep_state: pwm_sleep_state { - pe7 { - nvidia,pins = "pe7"; - nvidia,tristate = <TEGRA_PIN_ENABLE>; - }; - }; - }; - - pwm@7000a000 { - /* Mandatory PWM properties */ - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&pwm_active_state>; - pinctrl-1 = <&pwm_sleep_state>; - }; diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml new file mode 100644 index 000000000000..739d3155dd32 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/nvidia,tegra20-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra PWFM controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + oneOf: + - enum: + - nvidia,tegra20-pwm + - nvidia,tegra186-pwm + + - items: + - enum: + - nvidia,tegra30-pwm + - nvidia,tegra114-pwm + - nvidia,tegra124-pwm + - nvidia,tegra132-pwm + - nvidia,tegra210-pwm + - enum: + - nvidia,tegra20-pwm + + - items: + - const: nvidia,tegra194-pwm + - const: nvidia,tegra186-pwm + + - items: + - const: nvidia,tegra234-pwm + - const: nvidia,tegra194-pwm + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + items: + - description: module reset + + reset-names: + items: + - const: pwm + + "#pwm-cells": + const: 2 + + pinctrl-names: + items: + - const: default + - const: sleep + + pinctrl-0: + description: configuration for the default/active state + + pinctrl-1: + description: configuration for the sleep state + + operating-points-v2: + $ref: /schemas/types.yaml#/definitions/phandle + + power-domains: + items: + - description: phandle to the core power domain + +allOf: + - $ref: pwm.yaml + +required: + - compatible + - reg + - clocks + - resets + - reset-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + + pwm: pwm@7000a000 { + compatible = "nvidia,tegra20-pwm"; + reg = <0x7000a000 0x100>; + #pwm-cells = <2>; + clocks = <&tegra_car TEGRA20_CLK_PWM>; + resets = <&tegra_car 17>; + reset-names = "pwm"; + }; diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml index 90a7cabf58fe..83ad177a9043 100644 --- a/Documentation/devicetree/bindings/riscv/cpus.yaml +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml @@ -28,17 +28,20 @@ properties: oneOf: - items: - enum: - - sifive,rocket0 + - andestech,ax45mp + - canaan,k210 - sifive,bullet0 - sifive,e5 - sifive,e7 - sifive,e71 - - sifive,u74-mc - - sifive,u54 - - sifive,u74 + - sifive,rocket0 - sifive,u5 + - sifive,u54 - sifive,u7 - - canaan,k210 + - sifive,u74 + - sifive,u74-mc + - thead,c906 + - thead,c910 - const: riscv - items: - enum: diff --git a/Documentation/devicetree/bindings/riscv/starfive.yaml b/Documentation/devicetree/bindings/riscv/starfive.yaml index 5b36243fd674..5d3fcee52d59 100644 --- a/Documentation/devicetree/bindings/riscv/starfive.yaml +++ b/Documentation/devicetree/bindings/riscv/starfive.yaml @@ -19,7 +19,9 @@ properties: compatible: oneOf: - items: - - const: beagle,beaglev-starlight-jh7100-r0 + - enum: + - beagle,beaglev-starlight-jh7100-r0 + - starfive,visionfive-v1 - const: starfive,jh7100 additionalProperties: true diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt index d24e2bc444be..12e4b4260b40 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt +++ b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt @@ -30,6 +30,7 @@ Required properties in pwrap device node. "mediatek,mt8186-pwrap" for MT8186 SoCs "mediatek,mt8188-pwrap", "mediatek,mt8195-pwrap" for MT8188 SoCs "mediatek,mt8195-pwrap" for MT8195 SoCs + "mediatek,mt8365-pwrap" for MT8365 SoCs "mediatek,mt8516-pwrap" for MT8516 SoCs - interrupts: IRQ for pwrap in SOC - reg-names: "pwrap" is required; "pwrap-bridge" is optional. @@ -39,6 +40,8 @@ Required properties in pwrap device node. - clock-names: Must include the following entries: "spi": SPI bus clock "wrap": Main module clock + "sys": Optional system module clock + "tmr": Optional timer module clock - clocks: Must contain an entry for each entry in clock-names. Optional properities: diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml index a4eeb7e158e5..98d087cf4fc0 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml @@ -28,12 +28,14 @@ properties: - qcom,sc7180-aoss-qmp - qcom,sc7280-aoss-qmp - qcom,sc8180x-aoss-qmp + - qcom,sc8280xp-aoss-qmp - qcom,sdm845-aoss-qmp - qcom,sm6350-aoss-qmp - qcom,sm8150-aoss-qmp - qcom,sm8250-aoss-qmp - qcom,sm8350-aoss-qmp - qcom,sm8450-aoss-qmp + - qcom,sm8550-aoss-qmp - const: qcom,aoss-qmp reg: diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml index f47491aab3b1..857f8b886c10 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml @@ -17,6 +17,7 @@ description: | properties: compatible: enum: + - qcom,apr - qcom,apr-v2 - qcom,gpr diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml index 4a50f1d27724..b246500d3d5d 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml @@ -99,6 +99,9 @@ properties: - const: drv-2 - const: drv-3 + power-domains: + maxItems: 1 + bcm-voter: $ref: /schemas/interconnect/qcom,bcm-voter.yaml# @@ -151,6 +154,7 @@ examples: <SLEEP_TCS 3>, <WAKE_TCS 3>, <CONTROL_TCS 1>; + power-domains = <&CLUSTER_PD>; }; - | @@ -197,6 +201,7 @@ examples: <SLEEP_TCS 3>, <WAKE_TCS 3>, <CONTROL_TCS 0>; + power-domains = <&CLUSTER_PD>; clock-controller { compatible = "qcom,sm8350-rpmh-clk"; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index 09d5bfa920f2..11c0f4dd797c 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -4,7 +4,7 @@ $id: "http://devicetree.org/schemas/soc/qcom/qcom,smd-rpm.yaml#" $schema: "http://devicetree.org/meta-schemas/core.yaml#" -title: Qualcomm Resource Power Manager (RPM) over SMD +title: Qualcomm Resource Power Manager (RPM) over SMD/GLINK description: | This driver is used to interface with the Resource Power Manager (RPM) found @@ -12,9 +12,9 @@ description: | to vote for state of the system resources, such as clocks, regulators and bus frequencies. - The SMD information for the RPM edge should be filled out. See qcom,smd.yaml - for the required edge properties. All SMD related properties will reside - within the RPM node itself. + The SMD or GLINK information for the RPM edge should be filled out. See + qcom,smd.yaml for the required edge properties. All SMD/GLINK related + properties will reside within the RPM node itself. The RPM exposes resources to its subnodes. The rpm_requests node must be present and this subnode may contain children that designate regulator @@ -45,6 +45,7 @@ properties: - qcom,rpm-sdm660 - qcom,rpm-sm6115 - qcom,rpm-sm6125 + - qcom,rpm-sm6375 - qcom,rpm-qcm2290 - qcom,rpm-qcs404 @@ -55,12 +56,23 @@ properties: power-controller: $ref: /schemas/power/qcom,rpmpd.yaml# + qcom,glink-channels: + $ref: /schemas/types.yaml#/definitions/string-array + description: Channel name used for the RPM communication + items: + - const: rpm_requests + qcom,smd-channels: $ref: /schemas/types.yaml#/definitions/string-array description: Channel name used for the RPM communication items: - const: rpm_requests +patternProperties: + "^regulators(-[01])?$": + $ref: /schemas/regulator/qcom,smd-rpm-regulator.yaml# + unevaluatedProperties: false + if: properties: compatible: @@ -69,10 +81,18 @@ if: - qcom,rpm-apq8084 - qcom,rpm-msm8916 - qcom,rpm-msm8974 + - qcom,rpm-msm8976 - qcom,rpm-msm8953 then: + properties: + qcom,glink-channels: false required: - qcom,smd-channels +else: + properties: + qcom,smd-channels: false + required: + - qcom,glink-channels required: - compatible diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml index 795bd8cd4104..58500529b90f 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml @@ -60,7 +60,7 @@ properties: Two identifiers of the inbound and outbound smem items used for this edge. patternProperties: - "^master-kernel|slave-kernel|ipa-ap-to-modem|ipa-modem-to-ap$": + "^master-kernel|slave-kernel|ipa-ap-to-modem|ipa-modem-to-ap|wlan-ap-to-wpss|wlan-wpss-to-ap$": type: object description: Each SMP2P pair contain a set of inbound and outbound entries, these are diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml index f433e6e0a19f..38818c37c3ea 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml @@ -24,8 +24,11 @@ properties: - qcom,msm8998-silver-saw2-v4.1-l2 - qcom,msm8909-saw2-v3.0-cpu - qcom,msm8916-saw2-v3.0-cpu + - qcom,msm8939-saw2-v3.0-cpu - qcom,msm8226-saw2-v2.1-cpu - qcom,msm8974-saw2-v2.1-cpu + - qcom,msm8976-gold-saw2-v2.3-l2 + - qcom,msm8976-silver-saw2-v2.3-l2 - qcom,apq8084-saw2-v2.1-cpu - qcom,apq8064-saw2-v1.1-cpu - const: qcom,saw2 diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g011-sys.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g011-sys.yaml new file mode 100644 index 000000000000..1cac3cb5226c --- /dev/null +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g011-sys.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/renesas/renesas,r9a09g011-sys.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/V2M System Configuration (SYS) + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + +description: + The RZ/V2M-alike SYS (System Configuration) controls the overall + configuration of the LSI and supports the following functions, + - Bank address settings for DMAC + - Bank address settings of the units for ICB + - ETHER AxCACHE[1] (C bit) control function + - RAMA initialization control + - MD[7:0] pin monitoring + - LSI version + - PCIe related settings + - WDT stop control + - Temperature sensor (TSU) monitor + +properties: + compatible: + const: renesas,r9a09g011-sys + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + sys: system-controller@a3f03000 { + compatible = "renesas,r9a09g011-sys"; + reg = <0xa3f03000 0x400>; + }; diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml index f51464a08aff..2789022b52eb 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: http://devicetree.org/schemas/arm/renesas.yaml# +$id: http://devicetree.org/schemas/soc/renesas/renesas.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas SH-Mobile, R-Mobile, and R-Car Platform @@ -431,11 +431,12 @@ properties: - renesas,rzn1d400-db # RZN1D-DB (RZ/N1D Demo Board for the RZ/N1D 400 pins package) - const: renesas,r9a06g032 - - description: RZ/G2UL (R9A07G043) + - description: RZ/Five and RZ/G2UL (R9A07G043) items: - enum: - renesas,smarc-evk # SMARC EVK - enum: + - renesas,r9a07g043f01 # RZ/Five - renesas,r9a07g043u11 # RZ/G2UL Type-1 - renesas,r9a07g043u12 # RZ/G2UL Type-2 - const: renesas,r9a07g043 diff --git a/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml b/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml index 67134e06765a..ab86e4a36b2a 100644 --- a/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml +++ b/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml @@ -8,7 +8,7 @@ title: Audio codec controlled by ChromeOS EC maintainers: - Cheng-Yi Chiang <cychiang@chromium.org> - - Tzung-Bi Shih <tzungbi@google.com> + - Tzung-Bi Shih <tzungbi@kernel.org> description: | Google's ChromeOS EC codec is a digital mic codec provided by the diff --git a/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml b/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml index 1d73204451b1..ea7d4900ee4a 100644 --- a/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml +++ b/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Realtek rt1015p codec devicetree bindings maintainers: - - Tzung-Bi Shih <tzungbi@google.com> + - Tzung-Bi Shih <tzungbi@kernel.org> description: | Rt1015p is a rt1015 variant which does not support I2C and diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml index 50df1a40bbe3..12cb76711000 100644 --- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml +++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml @@ -23,6 +23,9 @@ properties: - const: fsl,imx51-ecspi - const: fsl,imx53-ecspi - items: + - const: fsl,imx8mp-ecspi + - const: fsl,imx6ul-ecspi + - items: - enum: - fsl,imx50-ecspi - fsl,imx6q-ecspi @@ -34,7 +37,6 @@ properties: - fsl,imx8mq-ecspi - fsl,imx8mm-ecspi - fsl,imx8mn-ecspi - - fsl,imx8mp-ecspi - const: fsl,imx51-ecspi reg: diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml index e9199190198d..665c06e14f79 100644 --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml @@ -25,6 +25,7 @@ properties: - qcom,sdm630-imem - qcom,sdm845-imem - qcom,sdx55-imem + - qcom,sdx65-imem - const: syscon - const: simple-mfd diff --git a/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml b/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml index feb390d50696..d20569b9b763 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml @@ -222,8 +222,8 @@ examples: qcom,hw-settle-time = <200>; }; - conn-therm@47 { - reg = <PM8350_ADC7_AMUX_THM4_100K_PU>; + conn-therm@147 { + reg = <PM8350_ADC7_AMUX_THM4_100K_PU(1)>; qcom,ratiometric; qcom,hw-settle-time = <200>; }; @@ -247,7 +247,7 @@ examples: conn-therm@1 { reg = <1>; - io-channels = <&pmk8350_vadc PM8350_ADC7_AMUX_THM4_100K_PU>; + io-channels = <&pmk8350_vadc PM8350_ADC7_AMUX_THM4_100K_PU(1)>; qcom,avg-samples = <2>; qcom,ratiometric; qcom,hw-settle-time-us = <200>; diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml index c5f629c5bc61..994818cb6044 100644 --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml @@ -30,6 +30,7 @@ properties: - allwinner,sun4i-a10-ehci - allwinner,sun50i-a64-ehci - allwinner,sun50i-h6-ehci + - allwinner,sun50i-h616-ehci - allwinner,sun5i-a13-ehci - allwinner,sun6i-a31-ehci - allwinner,sun7i-a20-ehci diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml index f838f78d6164..4fcbd0add49d 100644 --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml @@ -20,6 +20,7 @@ properties: - allwinner,sun4i-a10-ohci - allwinner,sun50i-a64-ohci - allwinner,sun50i-h6-ohci + - allwinner,sun50i-h616-ohci - allwinner,sun5i-a13-ohci - allwinner,sun6i-a31-ohci - allwinner,sun7i-a20-ohci diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt deleted file mode 100644 index 5bfcc0b4d6b9..000000000000 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt +++ /dev/null @@ -1,132 +0,0 @@ -NVIDIA Tegra xHCI controller -============================ - -The Tegra xHCI controller supports both USB2 and USB3 interfaces exposed by -the Tegra XUSB pad controller. - -Required properties: --------------------- -- compatible: Must be: - - Tegra124: "nvidia,tegra124-xusb" - - Tegra132: "nvidia,tegra132-xusb", "nvidia,tegra124-xusb" - - Tegra210: "nvidia,tegra210-xusb" - - Tegra186: "nvidia,tegra186-xusb" -- reg: Must contain the base and length of the xHCI host registers, XUSB FPCI - registers and XUSB IPFS registers. -- reg-names: Must contain the following entries: - - "hcd" - - "fpci" - - "ipfs" -- interrupts: Must contain the xHCI host interrupt and the mailbox interrupt. -- clocks: Must contain an entry for each entry in clock-names. - See ../clock/clock-bindings.txt for details. -- clock-names: Must include the following entries: - - xusb_host - - xusb_host_src - - xusb_falcon_src - - xusb_ss - - xusb_ss_src - - xusb_ss_div2 - - xusb_hs_src - - xusb_fs_src - - pll_u_480m - - clk_m - - pll_e -- resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names: Must include the following entries: - - xusb_host - - xusb_ss - - xusb_src - Note that xusb_src is the shared reset for xusb_{ss,hs,fs,falcon,host}_src. -- nvidia,xusb-padctl: phandle to the XUSB pad controller that is used to - configure the USB pads used by the XHCI controller - -For Tegra124 and Tegra132: -- avddio-pex-supply: PCIe/USB3 analog logic power supply. Must supply 1.05 V. -- dvddio-pex-supply: PCIe/USB3 digital logic power supply. Must supply 1.05 V. -- avdd-usb-supply: USB controller power supply. Must supply 3.3 V. -- avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8 V. -- avdd-pll-erefe-supply: PLLE reference PLL power supply. Must supply 1.05 V. -- avdd-usb-ss-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05 V. -- hvdd-usb-ss-supply: High-voltage PCIe/USB3 power supply. Must supply 3.3 V. -- hvdd-usb-ss-pll-e-supply: High-voltage PLLE power supply. Must supply 3.3 V. - -For Tegra210: -- dvddio-pex-supply: PCIe/USB3 analog logic power supply. Must supply 1.05 V. -- hvddio-pex-supply: High-voltage PCIe/USB3 power supply. Must supply 1.8 V. -- avdd-usb-supply: USB controller power supply. Must supply 3.3 V. -- avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8 V. -- avdd-pll-uerefe-supply: PLLE reference PLL power supply. Must supply 1.05 V. -- dvdd-pex-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05 V. -- hvdd-pex-pll-e-supply: High-voltage PLLE power supply. Must supply 1.8 V. - -For Tegra210 and Tegra186: -- power-domains: A list of PM domain specifiers that reference each power-domain - used by the xHCI controller. This list must comprise of a specifier for the - XUSBA and XUSBC power-domains. See ../power/power_domain.txt and - ../arm/tegra/nvidia,tegra20-pmc.txt for details. -- power-domain-names: A list of names that represent each of the specifiers in - the 'power-domains' property. Must include 'xusb_ss' and 'xusb_host' which - represent the power-domains XUSBA and XUSBC, respectively. See - ../power/power_domain.txt for details. - -Optional properties: --------------------- -- phys: Must contain an entry for each entry in phy-names. - See ../phy/phy-bindings.txt for details. -- phy-names: Should include an entry for each PHY used by the controller. The - following PHYs are available: - - Tegra124: usb2-0, usb2-1, usb2-2, hsic-0, hsic-1, usb3-0, usb3-1 - - Tegra132: usb2-0, usb2-1, usb2-2, hsic-0, hsic-1, usb3-0, usb3-1 - - Tegra210: usb2-0, usb2-1, usb2-2, usb2-3, hsic-0, usb3-0, usb3-1, usb3-2, - usb3-3 - - Tegra186: usb2-0, usb2-1, usb2-2, hsic-0, usb3-0, usb3-1, usb3-2 - -Example: --------- - - usb@0,70090000 { - compatible = "nvidia,tegra124-xusb"; - reg = <0x0 0x70090000 0x0 0x8000>, - <0x0 0x70098000 0x0 0x1000>, - <0x0 0x70099000 0x0 0x1000>; - reg-names = "hcd", "fpci", "ipfs"; - - interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>; - - clocks = <&tegra_car TEGRA124_CLK_XUSB_HOST>, - <&tegra_car TEGRA124_CLK_XUSB_HOST_SRC>, - <&tegra_car TEGRA124_CLK_XUSB_FALCON_SRC>, - <&tegra_car TEGRA124_CLK_XUSB_SS>, - <&tegra_car TEGRA124_CLK_XUSB_SS_DIV2>, - <&tegra_car TEGRA124_CLK_XUSB_SS_SRC>, - <&tegra_car TEGRA124_CLK_XUSB_HS_SRC>, - <&tegra_car TEGRA124_CLK_XUSB_FS_SRC>, - <&tegra_car TEGRA124_CLK_PLL_U_480M>, - <&tegra_car TEGRA124_CLK_CLK_M>, - <&tegra_car TEGRA124_CLK_PLL_E>; - clock-names = "xusb_host", "xusb_host_src", "xusb_falcon_src", - "xusb_ss", "xusb_ss_div2", "xusb_ss_src", - "xusb_hs_src", "xusb_fs_src", "pll_u_480m", - "clk_m", "pll_e"; - resets = <&tegra_car 89>, <&tegra_car 156>, <&tegra_car 143>; - reset-names = "xusb_host", "xusb_ss", "xusb_src"; - - nvidia,xusb-padctl = <&padctl>; - - phys = <&{/padctl@0,7009f000/pads/usb2/lanes/usb2-1}>, /* mini-PCIe USB */ - <&{/padctl@0,7009f000/pads/usb2/lanes/usb2-2}>, /* USB A */ - <&{/padctl@0,7009f000/pads/pcie/lanes/pcie-0}>; /* USB A */ - phy-names = "usb2-1", "usb2-2", "usb3-0"; - - avddio-pex-supply = <&vdd_1v05_run>; - dvddio-pex-supply = <&vdd_1v05_run>; - avdd-usb-supply = <&vdd_3v3_lp0>; - avdd-pll-utmip-supply = <&vddio_1v8>; - avdd-pll-erefe-supply = <&avdd_1v05_run>; - avdd-usb-ss-pll-supply = <&vdd_1v05_run>; - hvdd-usb-ss-supply = <&vdd_3v3_lp0>; - hvdd-usb-ss-pll-e-supply = <&vdd_3v3_lp0>; - }; diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.yaml new file mode 100644 index 000000000000..4a6616bf9bab --- /dev/null +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.yaml @@ -0,0 +1,202 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/nvidia,tegra124-xusb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra124 xHCI controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: The Tegra xHCI controller supports both USB2 and USB3 interfaces + exposed by the Tegra XUSB pad controller. + +properties: + # required + compatible: + oneOf: + - description: NVIDIA Tegra124 + const: nvidia,tegra124-xusb + + - description: NVIDIA Tegra132 + items: + - const: nvidia,tegra132-xusb + - const: nvidia,tegra124-xusb + + reg: + items: + - description: base and length of the xHCI host registers + - description: base and length of the XUSB FPCI registers + - description: base and length of the XUSB IPFS registers + + reg-names: + items: + - const: hcd + - const: fpci + - const: ipfs + + interrupts: + items: + - description: xHCI host interrupt + - description: mailbox interrupt + + clocks: + items: + - description: XUSB host clock + - description: XUSB host source clock + - description: XUSB Falcon source clock + - description: XUSB SuperSpeed clock + - description: XUSB SuperSpeed clock divider + - description: XUSB SuperSpeed source clock + - description: XUSB HighSpeed clock source + - description: XUSB FullSpeed clock source + - description: USB PLL + - description: reference clock + - description: I/O PLL + + clock-names: + items: + - const: xusb_host + - const: xusb_host_src + - const: xusb_falcon_src + - const: xusb_ss + - const: xusb_ss_div2 + - const: xusb_ss_src + - const: xusb_hs_src + - const: xusb_fs_src + - const: pll_u_480m + - const: clk_m + - const: pll_e + + resets: + items: + - description: reset for the XUSB host controller + - description: reset for the SuperSpeed logic + - description: shared reset for xusb_{ss,hs,fs,falcon,host}_src. + + reset-names: + items: + - const: xusb_host + - const: xusb_ss + - const: xusb_src + + nvidia,xusb-padctl: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the XUSB pad controller that is used to configure + the USB pads used by the XHCI controller + + # optional + phys: + minItems: 1 + maxItems: 7 + + phy-names: + minItems: 1 + maxItems: 7 + items: + enum: + - usb2-0 + - usb2-1 + - usb2-2 + - hsic-0 + - hsic-1 + - usb3-0 + - usb3-1 + + avddio-pex-supply: + description: PCIe/USB3 analog logic power supply. Must supply 1.05 V. + + dvddio-pex-supply: + description: PCIe/USB3 digital logic power supply. Must supply 1.05 V. + + avdd-usb-supply: + description: USB controller power supply. Must supply 3.3 V. + + avdd-pll-utmip-supply: + description: UTMI PLL power supply. Must supply 1.8 V. + + avdd-pll-erefe-supply: + description: PLLE reference PLL power supply. Must supply 1.05 V. + + avdd-usb-ss-pll-supply: + description: PCIe/USB3 PLL power supply. Must supply 1.05 V. + + hvdd-usb-ss-supply: + description: High-voltage PCIe/USB3 power supply. Must supply 3.3 V. + + hvdd-usb-ss-pll-e-supply: + description: High-voltage PLLE power supply. Must supply 3.3 V. + +allOf: + - $ref: usb-xhci.yaml + +unevaluatedProperties: false + +required: + - compatible + - reg + - reg-names + - interrupts + - clocks + - clock-names + - resets + - reset-names + - nvidia,xusb-padctl + - phys + - phy-names + - avddio-pex-supply + - dvddio-pex-supply + - avdd-usb-supply + - hvdd-usb-ss-supply + +examples: + - | + #include <dt-bindings/clock/tegra124-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + usb@70090000 { + compatible = "nvidia,tegra124-xusb"; + reg = <0x70090000 0x8000>, + <0x70098000 0x1000>, + <0x70099000 0x1000>; + reg-names = "hcd", "fpci", "ipfs"; + + interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&tegra_car TEGRA124_CLK_XUSB_HOST>, + <&tegra_car TEGRA124_CLK_XUSB_HOST_SRC>, + <&tegra_car TEGRA124_CLK_XUSB_FALCON_SRC>, + <&tegra_car TEGRA124_CLK_XUSB_SS>, + <&tegra_car TEGRA124_CLK_XUSB_SS_DIV2>, + <&tegra_car TEGRA124_CLK_XUSB_SS_SRC>, + <&tegra_car TEGRA124_CLK_XUSB_HS_SRC>, + <&tegra_car TEGRA124_CLK_XUSB_FS_SRC>, + <&tegra_car TEGRA124_CLK_PLL_U_480M>, + <&tegra_car TEGRA124_CLK_CLK_M>, + <&tegra_car TEGRA124_CLK_PLL_E>; + clock-names = "xusb_host", "xusb_host_src", "xusb_falcon_src", + "xusb_ss", "xusb_ss_div2", "xusb_ss_src", + "xusb_hs_src", "xusb_fs_src", "pll_u_480m", + "clk_m", "pll_e"; + resets = <&tegra_car 89>, <&tegra_car 156>, <&tegra_car 143>; + reset-names = "xusb_host", "xusb_ss", "xusb_src"; + + nvidia,xusb-padctl = <&padctl>; + + phys = <&{/padctl@0,7009f000/pads/usb2/lanes/usb2-1}>, /* mini-PCIe USB */ + <&{/padctl@0,7009f000/pads/usb2/lanes/usb2-2}>, /* USB A */ + <&{/padctl@0,7009f000/pads/pcie/lanes/pcie-0}>; /* USB A */ + phy-names = "usb2-1", "usb2-2", "usb3-0"; + + avddio-pex-supply = <&vdd_1v05_run>; + dvddio-pex-supply = <&vdd_1v05_run>; + avdd-usb-supply = <&vdd_3v3_lp0>; + avdd-pll-utmip-supply = <&vddio_1v8>; + avdd-pll-erefe-supply = <&avdd_1v05_run>; + avdd-usb-ss-pll-supply = <&vdd_1v05_run>; + hvdd-usb-ss-supply = <&vdd_3v3_lp0>; + hvdd-usb-ss-pll-e-supply = <&vdd_3v3_lp0>; + }; diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra186-xusb.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra186-xusb.yaml new file mode 100644 index 000000000000..6f62944fc597 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra186-xusb.yaml @@ -0,0 +1,173 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/nvidia,tegra186-xusb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra186 xHCI controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: The Tegra xHCI controller supports both USB2 and USB3 interfaces + exposed by the Tegra XUSB pad controller. + +properties: + compatible: + const: nvidia,tegra186-xusb + + reg: + items: + - description: base and length of the xHCI host registers + - description: base and length of the XUSB FPCI registers + + reg-names: + items: + - const: hcd + - const: fpci + + interrupts: + items: + - description: xHCI host interrupt + - description: mailbox interrupt + + clocks: + items: + - description: XUSB host clock + - description: XUSB Falcon source clock + - description: XUSB SuperSpeed clock + - description: XUSB SuperSpeed source clock + - description: XUSB HighSpeed clock source + - description: XUSB FullSpeed clock source + - description: USB PLL + - description: reference clock + - description: I/O PLL + + clock-names: + items: + - const: xusb_host + - const: xusb_falcon_src + - const: xusb_ss + - const: xusb_ss_src + - const: xusb_hs_src + - const: xusb_fs_src + - const: pll_u_480m + - const: clk_m + - const: pll_e + + interconnects: + items: + - description: read client + - description: write client + + interconnect-names: + items: + - const: dma-mem # read + - const: write + + iommus: + maxItems: 1 + + nvidia,xusb-padctl: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the XUSB pad controller that is used to configure + the USB pads used by the XHCI controller + + phys: + minItems: 1 + maxItems: 7 + + phy-names: + minItems: 1 + maxItems: 7 + items: + enum: + - usb2-0 + - usb2-1 + - usb2-2 + - hsic-0 + - usb3-0 + - usb3-1 + - usb3-2 + + power-domains: + items: + - description: XUSBC power domain (for Host and USB 2.0) + - description: XUSBA power domain (for SuperSpeed) + + power-domain-names: + items: + - const: xusb_host + - const: xusb_ss + + dvddio-pex-supply: + description: PCIe/USB3 analog logic power supply. Must supply 1.05 V. + + hvddio-pex-supply: + description: High-voltage PCIe/USB3 power supply. Must supply 1.8 V. + + avdd-usb-supply: + description: USB controller power supply. Must supply 3.3 V. + + avdd-pll-utmip-supply: + description: UTMI PLL power supply. Must supply 1.8 V. + + avdd-pll-uerefe-supply: + description: PLLE reference PLL power supply. Must supply 1.05 V. + + dvdd-usb-ss-pll-supply: + description: PCIe/USB3 PLL power supply. Must supply 1.05 V. + + hvdd-usb-ss-pll-e-supply: + description: High-voltage PLLE power supply. Must supply 1.8 V. + +allOf: + - $ref: usb-xhci.yaml + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra186-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/memory/tegra186-mc.h> + #include <dt-bindings/power/tegra186-powergate.h> + #include <dt-bindings/reset/tegra186-reset.h> + + usb@3530000 { + compatible = "nvidia,tegra186-xusb"; + reg = <0x03530000 0x8000>, + <0x03538000 0x1000>; + reg-names = "hcd", "fpci"; + interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bpmp TEGRA186_CLK_XUSB_HOST>, + <&bpmp TEGRA186_CLK_XUSB_FALCON>, + <&bpmp TEGRA186_CLK_XUSB_SS>, + <&bpmp TEGRA186_CLK_XUSB_CORE_SS>, + <&bpmp TEGRA186_CLK_CLK_M>, + <&bpmp TEGRA186_CLK_XUSB_FS>, + <&bpmp TEGRA186_CLK_PLLU>, + <&bpmp TEGRA186_CLK_CLK_M>, + <&bpmp TEGRA186_CLK_PLLE>; + clock-names = "xusb_host", "xusb_falcon_src", "xusb_ss", + "xusb_ss_src", "xusb_hs_src", "xusb_fs_src", + "pll_u_480m", "clk_m", "pll_e"; + power-domains = <&bpmp TEGRA186_POWER_DOMAIN_XUSBC>, + <&bpmp TEGRA186_POWER_DOMAIN_XUSBA>; + power-domain-names = "xusb_host", "xusb_ss"; + interconnects = <&mc TEGRA186_MEMORY_CLIENT_XUSB_HOSTR &emc>, + <&mc TEGRA186_MEMORY_CLIENT_XUSB_HOSTW &emc>; + interconnect-names = "dma-mem", "write"; + iommus = <&smmu TEGRA186_SID_XUSB_HOST>; + nvidia,xusb-padctl = <&padctl>; + + #address-cells = <1>; + #size-cells = <0>; + + phys = <&{/padctl@3520000/pads/usb2/lanes/usb2-0}>, + <&{/padctl@3520000/pads/usb2/lanes/usb2-1}>, + <&{/padctl@3520000/pads/usb3/lanes/usb3-0}>; + phy-names = "usb2-0", "usb2-1", "usb3-0"; + }; diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra194-xusb.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra194-xusb.yaml new file mode 100644 index 000000000000..65ae9ae9b0b7 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra194-xusb.yaml @@ -0,0 +1,179 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/nvidia,tegra194-xusb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra194 xHCI controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: The Tegra xHCI controller supports both USB2 and USB3 interfaces + exposed by the Tegra XUSB pad controller. + +properties: + compatible: + const: nvidia,tegra194-xusb + + reg: + items: + - description: base and length of the xHCI host registers + - description: base and length of the XUSB FPCI registers + + reg-names: + items: + - const: hcd + - const: fpci + + interrupts: + items: + - description: xHCI host interrupt + - description: mailbox interrupt + + clocks: + items: + - description: XUSB host clock + - description: XUSB Falcon source clock + - description: XUSB SuperSpeed clock + - description: XUSB SuperSpeed source clock + - description: XUSB HighSpeed clock source + - description: XUSB FullSpeed clock source + - description: USB PLL + - description: reference clock + - description: I/O PLL + + clock-names: + items: + - const: xusb_host + - const: xusb_falcon_src + - const: xusb_ss + - const: xusb_ss_src + - const: xusb_hs_src + - const: xusb_fs_src + - const: pll_u_480m + - const: clk_m + - const: pll_e + + interconnects: + items: + - description: read client + - description: write client + + interconnect-names: + items: + - const: dma-mem # read + - const: write + + iommus: + maxItems: 1 + + nvidia,xusb-padctl: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the XUSB pad controller that is used to configure + the USB pads used by the XHCI controller + + phys: + minItems: 1 + maxItems: 8 + + phy-names: + minItems: 1 + maxItems: 8 + items: + enum: + - usb2-0 + - usb2-1 + - usb2-2 + - usb2-3 + - usb3-0 + - usb3-1 + - usb3-2 + - usb3-3 + + power-domains: + items: + - description: XUSBC power domain (for Host and USB 2.0) + - description: XUSBA power domain (for SuperSpeed) + + power-domain-names: + items: + - const: xusb_host + - const: xusb_ss + + dvddio-pex-supply: + description: PCIe/USB3 analog logic power supply. Must supply 1.05 V. + + hvddio-pex-supply: + description: High-voltage PCIe/USB3 power supply. Must supply 1.8 V. + + avdd-usb-supply: + description: USB controller power supply. Must supply 3.3 V. + + avdd-pll-utmip-supply: + description: UTMI PLL power supply. Must supply 1.8 V. + + avdd-pll-uerefe-supply: + description: PLLE reference PLL power supply. Must supply 1.05 V. + + dvdd-usb-ss-pll-supply: + description: PCIe/USB3 PLL power supply. Must supply 1.05 V. + + hvdd-usb-ss-pll-e-supply: + description: High-voltage PLLE power supply. Must supply 1.8 V. + +allOf: + - $ref: usb-xhci.yaml + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra194-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/memory/tegra194-mc.h> + #include <dt-bindings/power/tegra194-powergate.h> + #include <dt-bindings/reset/tegra194-reset.h> + + usb@3610000 { + compatible = "nvidia,tegra194-xusb"; + reg = <0x03610000 0x40000>, + <0x03600000 0x10000>; + reg-names = "hcd", "fpci"; + + interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&bpmp TEGRA194_CLK_XUSB_CORE_HOST>, + <&bpmp TEGRA194_CLK_XUSB_FALCON>, + <&bpmp TEGRA194_CLK_XUSB_CORE_SS>, + <&bpmp TEGRA194_CLK_XUSB_SS>, + <&bpmp TEGRA194_CLK_CLK_M>, + <&bpmp TEGRA194_CLK_XUSB_FS>, + <&bpmp TEGRA194_CLK_UTMIPLL>, + <&bpmp TEGRA194_CLK_CLK_M>, + <&bpmp TEGRA194_CLK_PLLE>; + clock-names = "xusb_host", "xusb_falcon_src", + "xusb_ss", "xusb_ss_src", "xusb_hs_src", + "xusb_fs_src", "pll_u_480m", "clk_m", + "pll_e"; + interconnects = <&mc TEGRA194_MEMORY_CLIENT_XUSB_HOSTR &emc>, + <&mc TEGRA194_MEMORY_CLIENT_XUSB_HOSTW &emc>; + interconnect-names = "dma-mem", "write"; + iommus = <&smmu TEGRA194_SID_XUSB_HOST>; + + power-domains = <&bpmp TEGRA194_POWER_DOMAIN_XUSBC>, + <&bpmp TEGRA194_POWER_DOMAIN_XUSBA>; + power-domain-names = "xusb_host", "xusb_ss"; + + nvidia,xusb-padctl = <&xusb_padctl>; + + phys = <&{/bus@0/padctl@3520000/pads/usb2/lanes/usb2-0}>, + <&{/bus@0/padctl@3520000/pads/usb2/lanes/usb2-1}>, + <&{/bus@0/padctl@3520000/pads/usb2/lanes/usb2-3}>, + <&{/bus@0/padctl@3520000/pads/usb3/lanes/usb3-0}>, + <&{/bus@0/padctl@3520000/pads/usb3/lanes/usb3-2}>, + <&{/bus@0/padctl@3520000/pads/usb3/lanes/usb3-3}>; + phy-names = "usb2-0", "usb2-1", "usb2-3", "usb3-0", "usb3-2", "usb3-3"; + }; diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra210-xusb.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra210-xusb.yaml new file mode 100644 index 000000000000..da1e1ec0e7c8 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra210-xusb.yaml @@ -0,0 +1,199 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/nvidia,tegra210-xusb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra210 xHCI controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: The Tegra xHCI controller supports both USB2 and USB3 interfaces + exposed by the Tegra XUSB pad controller. + +properties: + compatible: + const: nvidia,tegra210-xusb + + reg: + items: + - description: base and length of the xHCI host registers + - description: base and length of the XUSB FPCI registers + - description: base and length of the XUSB IPFS registers + + reg-names: + items: + - const: hcd + - const: fpci + - const: ipfs + + interrupts: + items: + - description: xHCI host interrupt + - description: mailbox interrupt + + clocks: + items: + - description: XUSB host clock + - description: XUSB host source clock + - description: XUSB Falcon source clock + - description: XUSB SuperSpeed clock + - description: XUSB SuperSpeed clock divider + - description: XUSB SuperSpeed source clock + - description: XUSB HighSpeed clock source + - description: XUSB FullSpeed clock source + - description: USB PLL + - description: reference clock + - description: I/O PLL + + clock-names: + items: + - const: xusb_host + - const: xusb_host_src + - const: xusb_falcon_src + - const: xusb_ss + - const: xusb_ss_div2 + - const: xusb_ss_src + - const: xusb_hs_src + - const: xusb_fs_src + - const: pll_u_480m + - const: clk_m + - const: pll_e + + resets: + items: + - description: reset for the XUSB host controller + - description: reset for the SuperSpeed logic + - description: shared reset for xusb_{ss,hs,fs,falcon,host}_src. + + reset-names: + items: + - const: xusb_host + - const: xusb_ss + - const: xusb_src + + nvidia,xusb-padctl: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the XUSB pad controller that is used to configure + the USB pads used by the XHCI controller + + phys: + minItems: 1 + maxItems: 9 + + phy-names: + minItems: 1 + maxItems: 9 + items: + enum: + - usb2-0 + - usb2-1 + - usb2-2 + - usb2-3 + - hsic-0 + - usb3-0 + - usb3-1 + - usb3-2 + - usb3-3 + + power-domains: + items: + - description: XUSBC power domain (for Host and USB 2.0) + - description: XUSBA power domain (for SuperSpeed) + + power-domain-names: + items: + - const: xusb_host + - const: xusb_ss + + dvddio-pex-supply: + description: PCIe/USB3 analog logic power supply. Must supply 1.05 V. + + hvddio-pex-supply: + description: High-voltage PCIe/USB3 power supply. Must supply 1.8 V. + + avdd-usb-supply: + description: USB controller power supply. Must supply 3.3 V. + + avdd-pll-utmip-supply: + description: UTMI PLL power supply. Must supply 1.8 V. + + avdd-pll-uerefe-supply: + description: PLLE reference PLL power supply. Must supply 1.05 V. + + dvdd-usb-ss-pll-supply: + description: PCIe/USB3 PLL power supply. Must supply 1.05 V. + + hvdd-usb-ss-pll-e-supply: + description: High-voltage PLLE power supply. Must supply 1.8 V. + +allOf: + - $ref: usb-xhci.yaml + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra210-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + usb@70090000 { + compatible = "nvidia,tegra210-xusb"; + reg = <0x70090000 0x8000>, + <0x70098000 0x1000>, + <0x70099000 0x1000>; + reg-names = "hcd", "fpci", "ipfs"; + + interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&tegra_car TEGRA210_CLK_XUSB_HOST>, + <&tegra_car TEGRA210_CLK_XUSB_HOST_SRC>, + <&tegra_car TEGRA210_CLK_XUSB_FALCON_SRC>, + <&tegra_car TEGRA210_CLK_XUSB_SS>, + <&tegra_car TEGRA210_CLK_XUSB_SS_DIV2>, + <&tegra_car TEGRA210_CLK_XUSB_SS_SRC>, + <&tegra_car TEGRA210_CLK_XUSB_HS_SRC>, + <&tegra_car TEGRA210_CLK_XUSB_FS_SRC>, + <&tegra_car TEGRA210_CLK_PLL_U_480M>, + <&tegra_car TEGRA210_CLK_CLK_M>, + <&tegra_car TEGRA210_CLK_PLL_E>; + clock-names = "xusb_host", "xusb_host_src", + "xusb_falcon_src", "xusb_ss", + "xusb_ss_div2", "xusb_ss_src", + "xusb_hs_src", "xusb_fs_src", + "pll_u_480m", "clk_m", "pll_e"; + resets = <&tegra_car 89>, <&tegra_car 156>, + <&tegra_car 143>; + reset-names = "xusb_host", "xusb_ss", "xusb_src"; + power-domains = <&pd_xusbhost>, <&pd_xusbss>; + power-domain-names = "xusb_host", "xusb_ss"; + + nvidia,xusb-padctl = <&padctl>; + + phys = <&{/padctl@7009f000/pads/usb2/lanes/usb2-0}>, + <&{/padctl@7009f000/pads/usb2/lanes/usb2-1}>, + <&{/padctl@7009f000/pads/usb2/lanes/usb2-2}>, + <&{/padctl@7009f000/pads/usb2/lanes/usb2-3}>, + <&{/padctl@7009f000/pads/pcie/lanes/pcie-6}>, + <&{/padctl@7009f000/pads/pcie/lanes/pcie-5}>; + phy-names = "usb2-0", "usb2-1", "usb2-2", "usb2-3", "usb3-0", + "usb3-1"; + dvddio-pex-supply = <&vdd_pex_1v05>; + hvddio-pex-supply = <&vdd_1v8>; + avdd-usb-supply = <&vdd_3v3_sys>; + avdd-pll-utmip-supply = <&vdd_1v8>; + avdd-pll-uerefe-supply = <&vdd_pex_1v05>; + dvdd-usb-ss-pll-supply = <&vdd_pex_1v05>; + hvdd-usb-ss-pll-e-supply = <&vdd_1v8>; + + #address-cells = <1>; + #size-cells = <0>; + + ethernet@1 { + compatible = "usb955,9ff"; + reg = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 6e323a380294..cbe12da61b06 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -69,6 +69,8 @@ patternProperties: description: Annapurna Labs "^alcatel,.*": description: Alcatel + "^alfa-network,.*": + description: ALFA Network Inc. "^allegro,.*": description: Allegro DVT "^allo,.*": @@ -260,6 +262,8 @@ patternProperties: description: Cirrus Logic, Inc. "^cisco,.*": description: Cisco Systems, Inc. + "^cloos,.*": + description: Carl Cloos Schweisstechnik GmbH. "^cloudengines,.*": description: Cloud Engines, Inc. "^cnm,.*": @@ -605,6 +609,8 @@ patternProperties: description: Ingenic Semiconductor "^injoinic,.*": description: Injoinic Technology Corp. + "^innocomm,.*": + description: InnoComm Mobile Technology Corp. "^innolux,.*": description: Innolux Corporation "^inside-secure,.*": diff --git a/Documentation/driver-api/basics.rst b/Documentation/driver-api/basics.rst index 3e2dae954898..4b4d8e28d3be 100644 --- a/Documentation/driver-api/basics.rst +++ b/Documentation/driver-api/basics.rst @@ -107,9 +107,6 @@ Kernel utility functions .. kernel-doc:: kernel/panic.c :export: -.. kernel-doc:: include/linux/overflow.h - :internal: - Device Resource Management -------------------------- diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index 687adb58048e..56082265e8e5 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -279,6 +279,7 @@ GPIO devm_gpio_request_one() I2C + devm_i2c_add_adapter() devm_i2c_new_dummy_device() IIO diff --git a/Documentation/driver-api/media/mc-core.rst b/Documentation/driver-api/media/mc-core.rst index 84aa7cdb5341..400b8ca29367 100644 --- a/Documentation/driver-api/media/mc-core.rst +++ b/Documentation/driver-api/media/mc-core.rst @@ -214,18 +214,29 @@ Link properties can be modified at runtime by calling Pipelines and media streams ^^^^^^^^^^^^^^^^^^^^^^^^^^^ +A media stream is a stream of pixels or metadata originating from one or more +source devices (such as a sensors) and flowing through media entity pads +towards the final sinks. The stream can be modified on the route by the +devices (e.g. scaling or pixel format conversions), or it can be split into +multiple branches, or multiple branches can be merged. + +A media pipeline is a set of media streams which are interdependent. This +interdependency can be caused by the hardware (e.g. configuration of a second +stream cannot be changed if the first stream has been enabled) or by the driver +due to the software design. Most commonly a media pipeline consists of a single +stream which does not branch. + When starting streaming, drivers must notify all entities in the pipeline to prevent link states from being modified during streaming by calling :c:func:`media_pipeline_start()`. -The function will mark all entities connected to the given entity through -enabled links, either directly or indirectly, as streaming. +The function will mark all the pads which are part of the pipeline as streaming. The struct media_pipeline instance pointed to by -the pipe argument will be stored in every entity in the pipeline. +the pipe argument will be stored in every pad in the pipeline. Drivers should embed the struct media_pipeline in higher-level pipeline structures and can then access the -pipeline through the struct media_entity +pipeline through the struct media_pad pipe field. Calls to :c:func:`media_pipeline_start()` can be nested. diff --git a/Documentation/driver-api/miscellaneous.rst b/Documentation/driver-api/miscellaneous.rst index 304ffb146cf9..4a5104a368ac 100644 --- a/Documentation/driver-api/miscellaneous.rst +++ b/Documentation/driver-api/miscellaneous.rst @@ -16,12 +16,11 @@ Parallel Port Devices 16x50 UART Driver ================= -.. kernel-doc:: drivers/tty/serial/serial_core.c - :export: - .. kernel-doc:: drivers/tty/serial/8250/8250_core.c :export: +See serial/driver.rst for related APIs. + Pulse-Width Modulation (PWM) ============================ diff --git a/Documentation/hwmon/corsair-psu.rst b/Documentation/hwmon/corsair-psu.rst index 3c1b164eb3c0..6a03edb551a8 100644 --- a/Documentation/hwmon/corsair-psu.rst +++ b/Documentation/hwmon/corsair-psu.rst @@ -19,6 +19,8 @@ Supported devices: Corsair HX1200i + Corsair HX1500i + Corsair RM550i Corsair RM650i diff --git a/Documentation/kbuild/reproducible-builds.rst b/Documentation/kbuild/reproducible-builds.rst index 071f0151a7a4..f2dcc39044e6 100644 --- a/Documentation/kbuild/reproducible-builds.rst +++ b/Documentation/kbuild/reproducible-builds.rst @@ -119,6 +119,16 @@ To avoid this, you can make the vDSO different for different kernel versions by including an arbitrary string of "salt" in it. This is specified by the Kconfig symbol ``CONFIG_BUILD_SALT``. +Git +--- + +Uncommitted changes or different commit ids in git can also lead +to different compilation results. For example, after executing +``git reset HEAD^``, even if the code is the same, the +``include/config/kernel.release`` generated during compilation +will be different, which will eventually lead to binary differences. +See ``scripts/setlocalversion`` for details. + .. _KBUILD_BUILD_TIMESTAMP: kbuild.html#kbuild-build-timestamp .. _KBUILD_BUILD_USER and KBUILD_BUILD_HOST: kbuild.html#kbuild-build-user-kbuild-build-host .. _KCFLAGS: kbuild.html#kcflags diff --git a/Documentation/kernel-hacking/hacking.rst b/Documentation/kernel-hacking/hacking.rst index 9a1f020c8449..1717348a4404 100644 --- a/Documentation/kernel-hacking/hacking.rst +++ b/Documentation/kernel-hacking/hacking.rst @@ -120,7 +120,7 @@ You can tell you are in a softirq (or tasklet) using the .. warning:: Beware that this will return a false positive if a - :ref:`botton half lock <local_bh_disable>` is held. + :ref:`bottom half lock <local_bh_disable>` is held. Some Basic Rules ================ diff --git a/Documentation/loongarch/booting.rst b/Documentation/loongarch/booting.rst new file mode 100644 index 000000000000..91eccd410478 --- /dev/null +++ b/Documentation/loongarch/booting.rst @@ -0,0 +1,42 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================= +Booting Linux/LoongArch +======================= + +:Author: Yanteng Si <siyanteng@loongson.cn> +:Date: 18 Nov 2022 + +Information passed from BootLoader to kernel +============================================ + +LoongArch supports ACPI and FDT. The information that needs to be passed +to the kernel includes the memmap, the initrd, the command line, optionally +the ACPI/FDT tables, and so on. + +The kernel is passed the following arguments on `kernel_entry` : + + - a0 = efi_boot: `efi_boot` is a flag indicating whether + this boot environment is fully UEFI-compliant. + + - a1 = cmdline: `cmdline` is a pointer to the kernel command line. + + - a2 = systemtable: `systemtable` points to the EFI system table. + All pointers involved at this stage are in physical addresses. + +Header of Linux/LoongArch kernel images +======================================= + +Linux/LoongArch kernel images are EFI images. Being PE files, they have +a 64-byte header structured like:: + + u32 MZ_MAGIC /* "MZ", MS-DOS header */ + u32 res0 = 0 /* Reserved */ + u64 kernel_entry /* Kernel entry point */ + u64 _end - _text /* Kernel image effective size */ + u64 load_offset /* Kernel image load offset from start of RAM */ + u64 res1 = 0 /* Reserved */ + u64 res2 = 0 /* Reserved */ + u64 res3 = 0 /* Reserved */ + u32 LINUX_PE_MAGIC /* Magic number */ + u32 pe_header - _head /* Offset to the PE header */ diff --git a/Documentation/loongarch/index.rst b/Documentation/loongarch/index.rst index aaba648db907..c779bfa00c05 100644 --- a/Documentation/loongarch/index.rst +++ b/Documentation/loongarch/index.rst @@ -9,6 +9,7 @@ LoongArch Architecture :numbered: introduction + booting irq-chip-model features diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 06f80e3785c5..cc621decd943 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1966,7 +1966,7 @@ There are some more advanced barrier functions: (*) io_stop_wc(); For memory accesses with write-combining attributes (e.g. those returned - by ioremap_wc(), the CPU may wait for prior accesses to be merged with + by ioremap_wc()), the CPU may wait for prior accesses to be merged with subsequent ones. io_stop_wc() can be used to prevent the merging of write-combining memory accesses before this macro with those after it when such wait has performance implications. diff --git a/Documentation/mm/slub.rst b/Documentation/mm/slub.rst index 4e1578186b4f..7f652216dabe 100644 --- a/Documentation/mm/slub.rst +++ b/Documentation/mm/slub.rst @@ -116,6 +116,8 @@ options from the ``slub_debug`` parameter translate to the following files:: T trace A failslab +failslab file is writable, so writing 1 or 0 will enable or disable +the option at runtime. Write returns -EINVAL if cache is an alias. Careful with tracing: It may spew out lots of information and never stop if used on the wrong slab. diff --git a/Documentation/networking/generic_netlink.rst b/Documentation/networking/generic_netlink.rst index 59e04ccf80c1..d960dbd7e80e 100644 --- a/Documentation/networking/generic_netlink.rst +++ b/Documentation/networking/generic_netlink.rst @@ -6,4 +6,4 @@ Generic Netlink A wiki document on how to use Generic Netlink can be found here: - * http://www.linuxfoundation.org/collaborate/workgroups/networking/generic_netlink_howto + * https://wiki.linuxfoundation.org/networking/generic_netlink_howto diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst index e05fb1b8f8b6..6a919cffcbfd 100644 --- a/Documentation/process/2.Process.rst +++ b/Documentation/process/2.Process.rst @@ -126,17 +126,10 @@ than one development cycle past their initial release. So, for example, the 5.2.21 was the final stable update of the 5.2 release. Some kernels are designated "long term" kernels; they will receive support -for a longer period. As of this writing, the current long term kernels -and their maintainers are: - - ====== ================================ ======================= - 3.16 Ben Hutchings (very long-term kernel) - 4.4 Greg Kroah-Hartman & Sasha Levin (very long-term kernel) - 4.9 Greg Kroah-Hartman & Sasha Levin - 4.14 Greg Kroah-Hartman & Sasha Levin - 4.19 Greg Kroah-Hartman & Sasha Levin - 5.4 Greg Kroah-Hartman & Sasha Levin - ====== ================================ ======================= +for a longer period. Please refer to the following link for the list of active +long term kernel versions and their maintainers: + + https://www.kernel.org/category/releases.html The selection of a kernel for long-term support is purely a matter of a maintainer having the need and the time to maintain that release. There diff --git a/Documentation/process/code-of-conduct-interpretation.rst b/Documentation/process/code-of-conduct-interpretation.rst index 922e0b547bc3..66b07f14714c 100644 --- a/Documentation/process/code-of-conduct-interpretation.rst +++ b/Documentation/process/code-of-conduct-interpretation.rst @@ -51,7 +51,7 @@ the Technical Advisory Board (TAB) or other maintainers if you're uncertain how to handle situations that come up. It will not be considered a violation report unless you want it to be. If you are uncertain about approaching the TAB or any other maintainers, please -reach out to our conflict mediator, Joanna Lee <joanna.lee@gesmer.com>. +reach out to our conflict mediator, Joanna Lee <jlee@linuxfoundation.org>. In the end, "be kind to each other" is really what the end goal is for everybody. We know everyone is human and we all fail at times, but the diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst index bd15c393ba3c..cb6abcb2b6d0 100644 --- a/Documentation/process/howto.rst +++ b/Documentation/process/howto.rst @@ -36,7 +36,7 @@ experience, the following books are good for, if anything, reference: - "C: A Reference Manual" by Harbison and Steele [Prentice Hall] The kernel is written using GNU C and the GNU toolchain. While it -adheres to the ISO C89 standard, it uses a number of extensions that are +adheres to the ISO C11 standard, it uses a number of extensions that are not featured in the standard. The kernel is a freestanding C environment, with no reliance on the standard C library, so some portions of the C standard are not supported. Arbitrary long long diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst index d14007081595..1fa5ab8754d3 100644 --- a/Documentation/process/maintainer-netdev.rst +++ b/Documentation/process/maintainer-netdev.rst @@ -319,3 +319,13 @@ unpatched tree to confirm infrastructure didn't mangle it. Finally, go back and read :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` to be sure you are not repeating some common mistake documented there. + +My company uses peer feedback in employee performance reviews. Can I ask netdev maintainers for feedback? +--------------------------------------------------------------------------------------------------------- + +Yes, especially if you spend significant amount of time reviewing code +and go out of your way to improve shared infrastructure. + +The feedback must be requested by you, the contributor, and will always +be shared with you (even if you request for it to be submitted to your +manager). diff --git a/Documentation/trace/histogram.rst b/Documentation/trace/histogram.rst index c1b685a38f6b..87bd772836c0 100644 --- a/Documentation/trace/histogram.rst +++ b/Documentation/trace/histogram.rst @@ -39,7 +39,7 @@ Documentation written by Tom Zanussi will use the event's kernel stacktrace as the key. The keywords 'keys' or 'key' can be used to specify keys, and the keywords 'values', 'vals', or 'val' can be used to specify values. Compound - keys consisting of up to two fields can be specified by the 'keys' + keys consisting of up to three fields can be specified by the 'keys' keyword. Hashing a compound key produces a unique entry in the table for each unique combination of component keys, and can be useful for providing more fine-grained summaries of event data. diff --git a/Documentation/translations/it_IT/process/howto.rst b/Documentation/translations/it_IT/process/howto.rst index 15c08aea1dfe..052f1b3610cb 100644 --- a/Documentation/translations/it_IT/process/howto.rst +++ b/Documentation/translations/it_IT/process/howto.rst @@ -44,7 +44,7 @@ altro, utili riferimenti: - "C: A Reference Manual" di Harbison and Steele [Prentice Hall] Il kernel è stato scritto usando GNU C e la toolchain GNU. -Sebbene si attenga allo standard ISO C89, esso utilizza una serie di +Sebbene si attenga allo standard ISO C11, esso utilizza una serie di estensioni che non sono previste in questo standard. Il kernel è un ambiente C indipendente, che non ha alcuna dipendenza dalle librerie C standard, così alcune parti del C standard non sono supportate. diff --git a/Documentation/translations/ja_JP/howto.rst b/Documentation/translations/ja_JP/howto.rst index b47a682d8ded..b8eeb45a02d4 100644 --- a/Documentation/translations/ja_JP/howto.rst +++ b/Documentation/translations/ja_JP/howto.rst @@ -65,7 +65,7 @@ Linux カーネル開発のやり方 - 『新・詳説 C 言語 H&S リファレンス』 (サミュエル P ハービソン/ガイ L スティール共著 斉藤 信男監訳)[ソフトバンク] カーネルは GNU C と GNU ツールチェインを使って書かれています。カーネル -は ISO C89 仕様に準拠して書く一方で、標準には無い言語拡張を多く使って +は ISO C11 仕様に準拠して書く一方で、標準には無い言語拡張を多く使って います。カーネルは標準 C ライブラリに依存しない、C 言語非依存環境です。 そのため、C の標準の中で使えないものもあります。特に任意の long long の除算や浮動小数点は使えません。カーネルがツールチェインや C 言語拡張 diff --git a/Documentation/translations/ko_KR/howto.rst b/Documentation/translations/ko_KR/howto.rst index df53fafd1b10..969e91a95bb0 100644 --- a/Documentation/translations/ko_KR/howto.rst +++ b/Documentation/translations/ko_KR/howto.rst @@ -62,7 +62,7 @@ Documentation/process/howto.rst - "Practical C Programming" by Steve Oualline [O'Reilly] - "C: A Reference Manual" by Harbison and Steele [Prentice Hall] -커널은 GNU C와 GNU 툴체인을 사용하여 작성되었다. 이 툴들은 ISO C89 표준을 +커널은 GNU C와 GNU 툴체인을 사용하여 작성되었다. 이 툴들은 ISO C11 표준을 따르는 반면 표준에 있지 않은 많은 확장기능도 가지고 있다. 커널은 표준 C 라이브러리와는 관계없이 freestanding C 환경이어서 C 표준의 일부는 지원되지 않는다. 임의의 long long 나누기나 floating point는 지원되지 않는다. diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt index 75aa5531cc7d..7165927a708e 100644 --- a/Documentation/translations/ko_KR/memory-barriers.txt +++ b/Documentation/translations/ko_KR/memory-barriers.txt @@ -80,7 +80,7 @@ Documentation/memory-barriers.txt - 메모리 배리어의 종류. - 메모리 배리어에 대해 가정해선 안될 것. - - 데이터 의존성 배리어 (역사적). + - 주소 데이터 의존성 배리어 (역사적). - 컨트롤 의존성. - SMP 배리어 짝맞추기. - 메모리 배리어 시퀀스의 예. @@ -217,7 +217,7 @@ Documentation/memory-barriers.txt P = &B D = *Q; D 로 읽혀지는 값은 CPU 2 에서 P 로부터 읽혀진 주소값에 의존적이기 때문에 여기엔 -분명한 데이터 의존성이 있습니다. 하지만 이 이벤트들의 실행 결과로는 아래의 +분명한 주소 의존성이 있습니다. 하지만 이 이벤트들의 실행 결과로는 아래의 결과들이 모두 나타날 수 있습니다: (Q == &A) and (D == 1) @@ -416,19 +416,19 @@ CPU 에게 기대할 수 있는 최소한의 보장사항 몇가지가 있습니 하나씩 요청해 집어넣습니다. 쓰기 배리어 앞의 모든 스토어 오퍼레이션들은 쓰기 배리어 뒤의 모든 스토어 오퍼레이션들보다 _앞서_ 수행될 겁니다. - [!] 쓰기 배리어들은 읽기 또는 데이터 의존성 배리어와 함께 짝을 맞춰 + [!] 쓰기 배리어들은 읽기 또는 주소 의존성 배리어와 함께 짝을 맞춰 사용되어야만 함을 알아두세요; "SMP 배리어 짝맞추기" 서브섹션을 참고하세요. - (2) 데이터 의존성 배리어. + (2) 주소 의존성 배리어 (역사적). - 데이터 의존성 배리어는 읽기 배리어의 보다 완화된 형태입니다. 두개의 로드 + 주소 의존성 배리어는 읽기 배리어의 보다 완화된 형태입니다. 두개의 로드 오퍼레이션이 있고 두번째 것이 첫번째 것의 결과에 의존하고 있을 때(예: 두번째 로드가 참조할 주소를 첫번째 로드가 읽는 경우), 두번째 로드가 읽어올 데이터는 첫번째 로드에 의해 그 주소가 얻어진 뒤에 업데이트 됨을 보장하기 - 위해서 데이터 의존성 배리어가 필요할 수 있습니다. + 위해서 주소 의존성 배리어가 필요할 수 있습니다. - 데이터 의존성 배리어는 상호 의존적인 로드 오퍼레이션들 사이의 부분적 순서 + 주소 의존성 배리어는 상호 의존적인 로드 오퍼레이션들 사이의 부분적 순서 세우기입니다; 스토어 오퍼레이션들이나 독립적인 로드들, 또는 중복되는 로드들에 대해서는 어떤 영향도 끼치지 않습니다. @@ -436,37 +436,41 @@ CPU 에게 기대할 수 있는 최소한의 보장사항 몇가지가 있습니 오퍼레이션들을 던져 넣고 있으며, 거기에 관심이 있는 다른 CPU 는 그 오퍼레이션들을 메모리 시스템이 실행한 결과를 인지할 수 있습니다. 이처럼 다른 CPU 의 스토어 오퍼레이션의 결과에 관심을 두고 있는 CPU 가 수행 요청한 - 데이터 의존성 배리어는, 배리어 앞의 어떤 로드 오퍼레이션이 다른 CPU 에서 + 주소 의존성 배리어는, 배리어 앞의 어떤 로드 오퍼레이션이 다른 CPU 에서 던져 넣은 스토어 오퍼레이션과 같은 영역을 향했다면, 그런 스토어 - 오퍼레이션들이 만들어내는 결과가 데이터 의존성 배리어 뒤의 로드 + 오퍼레이션들이 만들어내는 결과가 주소 의존성 배리어 뒤의 로드 오퍼레이션들에게는 보일 것을 보장합니다. 이 순서 세우기 제약에 대한 그림을 보기 위해선 "메모리 배리어 시퀀스의 예" 서브섹션을 참고하시기 바랍니다. - [!] 첫번째 로드는 반드시 _데이터_ 의존성을 가져야지 컨트롤 의존성을 가져야 + [!] 첫번째 로드는 반드시 _주소_ 의존성을 가져야지 컨트롤 의존성을 가져야 하는게 아님을 알아두십시오. 만약 두번째 로드를 위한 주소가 첫번째 로드에 의존적이지만 그 의존성은 조건적이지 그 주소 자체를 가져오는게 아니라면, 그것은 _컨트롤_ 의존성이고, 이 경우에는 읽기 배리어나 그보다 강력한 무언가가 필요합니다. 더 자세한 내용을 위해서는 "컨트롤 의존성" 서브섹션을 참고하시기 바랍니다. - [!] 데이터 의존성 배리어는 보통 쓰기 배리어들과 함께 짝을 맞춰 사용되어야 + [!] 주소 의존성 배리어는 보통 쓰기 배리어들과 함께 짝을 맞춰 사용되어야 합니다; "SMP 배리어 짝맞추기" 서브섹션을 참고하세요. + [!] 커널 v5.9 릴리즈에서 명시적 주소 의존성 배리어를 위한 커널 API 들이 + 삭제되었습니다. 오늘날에는 공유된 변수들의 로드를 표시하는 READ_ONCE() 나 + rcu_dereference() 와 같은 API 들은 묵시적으로 주소 의존성 배리어를 제공합니다. + (3) 읽기 (또는 로드) 메모리 배리어. - 읽기 배리어는 데이터 의존성 배리어 기능의 보장사항에 더해서 배리어보다 - 앞서 명시된 모든 LOAD 오퍼레이션들이 배리어 뒤에 명시되는 모든 LOAD + 읽기 배리어는 주소 의존성 배리어 기능의 보장사항에 더해서 배리어보다 앞서 + 명시된 모든 LOAD 오퍼레이션들이 배리어 뒤에 명시되는 모든 LOAD 오퍼레이션들보다 먼저 행해진 것으로 시스템의 다른 컴포넌트들에 보여질 것을 보장합니다. 읽기 배리어는 로드 오퍼레이션에 행해지는 부분적 순서 세우기입니다; 스토어 오퍼레이션에 대해서는 어떤 영향도 끼치지 않습니다. - 읽기 메모리 배리어는 데이터 의존성 배리어를 내장하므로 데이터 의존성 - 배리어를 대신할 수 있습니다. + 읽기 메모리 배리어는 주소 의존성 배리어를 내장하므로 주소 의존성 배리어를 + 대신할 수 있습니다. [!] 읽기 배리어는 일반적으로 쓰기 배리어들과 함께 짝을 맞춰 사용되어야 합니다; "SMP 배리어 짝맞추기" 서브섹션을 참고하세요. @@ -571,16 +575,20 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE Documentation/core-api/dma-api.rst -데이터 의존성 배리어 (역사적) ------------------------------ +주소 의존성 배리어 (역사적) +--------------------------- 리눅스 커널 v4.15 기준으로, smp_mb() 가 DEC Alpha 용 READ_ONCE() 코드에 추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐 전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다. -그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성 +그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 주소 의존성 배리어에 대한 이야기를 적습니다. -데이터 의존성 배리어의 사용에 있어 지켜야 하는 사항들은 약간 미묘하고, 데이터 +[!] 주소 의존성은 로드에서 로드로와 로드에서 스토어로의 관계들 모두에서 +나타나지만, 주소 의존성 배리어는 로드에서 스토어로의 상황에서는 필요하지 +않습니다. + +주소 의존성 배리어의 사용에 있어 지켜야 하는 사항들은 약간 미묘하고, 데이터 의존성 배리어가 사용되어야 하는 상황도 항상 명백하지는 않습니다. 설명을 위해 다음의 이벤트 시퀀스를 생각해 봅시다: @@ -590,10 +598,13 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE B = 4; <쓰기 배리어> WRITE_ONCE(P, &B) - Q = READ_ONCE(P); + Q = READ_ONCE_OLD(P); D = *Q; -여기엔 분명한 데이터 의존성이 존재하므로, 이 시퀀스가 끝났을 때 Q 는 &A 또는 &B +[!] READ_ONCE_OLD() 는 4.15 커널 전의 버전에서의, 주소 의존성 배리어를 내포하지 +않는 READ_ONCE() 에 해당합니다. + +여기엔 분명한 주소 의존성이 존재하므로, 이 시퀀스가 끝났을 때 Q 는 &A 또는 &B 일 것이고, 따라서: (Q == &A) 는 (D == 1) 를, @@ -608,8 +619,8 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE 그렇지 않습니다, 그리고 이 현상은 (DEC Alpha 와 같은) 여러 CPU 에서 실제로 발견될 수 있습니다. -이 문제 상황을 제대로 해결하기 위해, 데이터 의존성 배리어나 그보다 강화된 -무언가가 주소를 읽어올 때와 데이터를 읽어올 때 사이에 추가되어야만 합니다: +이 문제 상황을 제대로 해결하기 위해, READ_ONCE() 는 커널 v4.15 릴리즈 부터 +묵시적 주소 의존성 배리어를 제공합니다: CPU 1 CPU 2 =============== =============== @@ -618,7 +629,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE <쓰기 배리어> WRITE_ONCE(P, &B); Q = READ_ONCE(P); - <데이터 의존성 배리어> + <묵시적 주소 의존성 배리어> D = *Q; 이 변경은 앞의 처음 두가지 결과 중 하나만이 발생할 수 있고, 세번째의 결과는 @@ -634,7 +645,7 @@ P 는 짝수 번호 캐시 라인에 저장되어 있고, 변수 B 는 홀수 중이라면 포인터 P (&B) 의 새로운 값과 변수 B 의 기존 값 (2) 를 볼 수 있습니다. -의존적 쓰기들의 순서를 맞추는데에는 데이터 의존성 배리어가 필요치 않은데, 이는 +의존적 쓰기들의 순서를 맞추는데에는 주소 의존성 배리어가 필요치 않은데, 이는 리눅스 커널이 지원하는 CPU 들은 (1) 쓰기가 정말로 일어날지, (2) 쓰기가 어디에 이루어질지, 그리고 (3) 쓰여질 값을 확실히 알기 전까지는 쓰기를 수행하지 않기 때문입니다. 하지만 "컨트롤 의존성" 섹션과 @@ -647,12 +658,12 @@ Documentation/RCU/rcu_dereference.rst 파일을 주의 깊게 읽어 주시기 B = 4; <쓰기 배리어> WRITE_ONCE(P, &B); - Q = READ_ONCE(P); + Q = READ_ONCE_OLD(P); WRITE_ONCE(*Q, 5); -따라서, Q 로의 읽기와 *Q 로의 쓰기 사이에는 데이터 종속성 배리어가 필요치 -않습니다. 달리 말하면, 데이터 종속성 배리어가 없더라도 다음 결과는 생기지 -않습니다: +따라서, Q 로의 읽기와 *Q 로의 쓰기 사이에는 주소 의존성 배리어가 필요치 +않습니다. 달리 말하면, 오늘날의 READ_ONCE() 의 묵시적 주소 의존성 배리어가 +없더라도 다음 결과는 생기지 않습니다: (Q == &B) && (B == 4) @@ -663,16 +674,16 @@ Documentation/RCU/rcu_dereference.rst 파일을 주의 깊게 읽어 주시기 해줍니다. -데이터 의존성에 의해 제공되는 이 순서규칙은 이를 포함하고 있는 CPU 에 +주소 의존성에 의해 제공되는 이 순서규칙은 이를 포함하고 있는 CPU 에 지역적임을 알아두시기 바랍니다. 더 많은 정보를 위해선 "Multicopy 원자성" 섹션을 참고하세요. -데이터 의존성 배리어는 매우 중요한데, 예를 들어 RCU 시스템에서 그렇습니다. +주소 의존성 배리어는 매우 중요한데, 예를 들어 RCU 시스템에서 그렇습니다. include/linux/rcupdate.h 의 rcu_assign_pointer() 와 rcu_dereference() 를 -참고하세요. 여기서 데이터 의존성 배리어는 RCU 로 관리되는 포인터의 타겟을 현재 -타겟에서 수정된 새로운 타겟으로 바꾸는 작업에서 새로 수정된 타겟이 초기화가 -완료되지 않은 채로 보여지는 일이 일어나지 않게 해줍니다. +참고하세요. 이것들은 RCU 로 관리되는 포인터의 타겟을 현재 타겟에서 수정된 +새로운 타겟으로 바꾸는 작업에서 새로 수정된 타겟이 초기화가 완료되지 않은 채로 +보여지는 일이 일어나지 않게 해줍니다. 더 많은 예를 위해선 "캐시 일관성" 서브섹션을 참고하세요. @@ -684,16 +695,17 @@ include/linux/rcupdate.h 의 rcu_assign_pointer() 와 rcu_dereference() 를 약간 다루기 어려울 수 있습니다. 이 섹션의 목적은 여러분이 컴파일러의 무시로 인해 여러분의 코드가 망가지는 걸 막을 수 있도록 돕는겁니다. -로드-로드 컨트롤 의존성은 데이터 의존성 배리어만으로는 정확히 동작할 수가 -없어서 읽기 메모리 배리어를 필요로 합니다. 아래의 코드를 봅시다: +로드-로드 컨트롤 의존성은 (묵시적인) 주소 의존성 배리어만으로는 정확히 동작할 +수가 없어서 읽기 메모리 배리어를 필요로 합니다. 아래의 코드를 봅시다: q = READ_ONCE(a); + <묵시적 주소 의존성 배리어> if (q) { - <데이터 의존성 배리어> /* BUG: No data dependency!!! */ + /* BUG: No address dependency!!! */ p = READ_ONCE(b); } -이 코드는 원하는 대로의 효과를 내지 못할 수 있는데, 이 코드에는 데이터 의존성이 +이 코드는 원하는 대로의 효과를 내지 못할 수 있는데, 이 코드에는 주소 의존성이 아니라 컨트롤 의존성이 존재하기 때문으로, 이런 상황에서 CPU 는 실행 속도를 더 빠르게 하기 위해 분기 조건의 결과를 예측하고 코드를 재배치 할 수 있어서 다른 CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레이션보다 먼저 발생한 @@ -930,9 +942,9 @@ CPU 간 상호작용을 다룰 때에 일부 타입의 메모리 배리어는 범용 배리어들은 범용 배리어끼리도 짝을 맞추지만 multicopy 원자성이 없는 대부분의 다른 타입의 배리어들과도 짝을 맞춥니다. ACQUIRE 배리어는 RELEASE 배리어와 짝을 맞춥니다만, 둘 다 범용 배리어를 포함해 다른 배리어들과도 짝을 -맞출 수 있습니다. 쓰기 배리어는 데이터 의존성 배리어나 컨트롤 의존성, ACQUIRE +맞출 수 있습니다. 쓰기 배리어는 주소 의존성 배리어나 컨트롤 의존성, ACQUIRE 배리어, RELEASE 배리어, 읽기 배리어, 또는 범용 배리어와 짝을 맞춥니다. -비슷하게 읽기 배리어나 컨트롤 의존성, 또는 데이터 의존성 배리어는 쓰기 배리어나 +비슷하게 읽기 배리어나 컨트롤 의존성, 또는 주소 의존성 배리어는 쓰기 배리어나 ACQUIRE 배리어, RELEASE 배리어, 또는 범용 배리어와 짝을 맞추는데, 다음과 같습니다: @@ -951,7 +963,7 @@ ACQUIRE 배리어, RELEASE 배리어, 또는 범용 배리어와 짝을 맞추 a = 1; <쓰기 배리어> WRITE_ONCE(b, &a); x = READ_ONCE(b); - <데이터 의존성 배리어> + <묵시적 주소 의존성 배리어> y = *x; 또는: @@ -970,8 +982,8 @@ ACQUIRE 배리어, RELEASE 배리어, 또는 범용 배리어와 짝을 맞추 기본적으로, 여기서의 읽기 배리어는 "더 완화된" 타입일 순 있어도 항상 존재해야 합니다. -[!] 쓰기 배리어 앞의 스토어 오퍼레이션은 일반적으로 읽기 배리어나 데이터 -의존성 배리어 뒤의 로드 오퍼레이션과 매치될 것이고, 반대도 마찬가지입니다: +[!] 쓰기 배리어 앞의 스토어 오퍼레이션은 일반적으로 읽기 배리어나 주소 의존성 +배리어 뒤의 로드 오퍼레이션과 매치될 것이고, 반대도 마찬가지입니다: CPU 1 CPU 2 =================== =================== @@ -1023,7 +1035,7 @@ ACQUIRE 배리어, RELEASE 배리어, 또는 범용 배리어와 짝을 맞추 V -둘째, 데이터 의존성 배리어는 데이터 의존적 로드 오퍼레이션들의 부분적 순서 +둘째, 주소 의존성 배리어는 데이터 의존적 로드 오퍼레이션들의 부분적 순서 세우기로 동작합니다. 다음 일련의 이벤트들을 보세요: CPU 1 CPU 2 @@ -1069,7 +1081,7 @@ ACQUIRE 배리어, RELEASE 배리어, 또는 범용 배리어와 짝을 맞추 앞의 예에서, CPU 2 는 (B 의 값이 될) *C 의 값 읽기가 C 의 LOAD 뒤에 이어짐에도 B 가 7 이라는 결과를 얻습니다. -하지만, 만약 데이터 의존성 배리어가 C 의 로드와 *C (즉, B) 의 로드 사이에 +하지만, 만약 주소 의존성 배리어가 C 의 로드와 *C (즉, B) 의 로드 사이에 있었다면: CPU 1 CPU 2 @@ -1080,7 +1092,7 @@ B 가 7 이라는 결과를 얻습니다. <쓰기 배리어> STORE C = &B LOAD X STORE D = 4 LOAD C (gets &B) - <데이터 의존성 배리어> + <주소 의존성 배리어> LOAD *C (reads B) 다음과 같이 됩니다: @@ -1103,7 +1115,7 @@ B 가 7 이라는 결과를 얻습니다. | +-------+ | | | | X->9 |------>| | | +-------+ | | - C 로의 스토어 앞의 ---> \ ddddddddddddddddd | | + C 로의 스토어 앞의 ---> \ aaaaaaaaaaaaaaaaa | | 모든 이벤트 결과가 \ +-------+ | | 뒤의 로드에게 ----->| B->2 |------>| | 보이게 강제한다 +-------+ | | @@ -1291,7 +1303,7 @@ A 의 로드 두개가 모두 B 의 로드 뒤에 있지만, 서로 다른 값 즉각 완료한다 : : +-------+ -읽기 배리어나 데이터 의존성 배리어를 두번째 로드 직전에 놓는다면: +읽기 배리어나 주소 의존성 배리어를 두번째 로드 직전에 놓는다면: CPU 1 CPU 2 ======================= ======================= @@ -1785,21 +1797,20 @@ READ_ONCE(jiffies) 라고 할 필요가 없습니다. READ_ONCE() 와 WRITE_ONC CPU 메모리 배리어 ----------------- -리눅스 커널은 다음의 여덟개 기본 CPU 메모리 배리어를 가지고 있습니다: +리눅스 커널은 다음의 일곱개 기본 CPU 메모리 배리어를 가지고 있습니다: TYPE MANDATORY SMP CONDITIONAL - =============== ======================= =========================== + =============== ======================= =============== 범용 mb() smp_mb() 쓰기 wmb() smp_wmb() 읽기 rmb() smp_rmb() - 데이터 의존성 READ_ONCE() + 주소 의존성 READ_ONCE() -데이터 의존성 배리어를 제외한 모든 메모리 배리어는 컴파일러 배리어를 -포함합니다. 데이터 의존성은 컴파일러에의 추가적인 순서 보장을 포함하지 -않습니다. +주소 의존성 배리어를 제외한 모든 메모리 배리어는 컴파일러 배리어를 포함합니다. +주소 의존성은 컴파일러에의 추가적인 순서 보장을 포함하지 않습니다. -방백: 데이터 의존성이 있는 경우, 컴파일러는 해당 로드를 올바른 순서로 일으킬 +방백: 주소 의존성이 있는 경우, 컴파일러는 해당 로드를 올바른 순서로 일으킬 것으로 (예: `a[b]` 는 a[b] 를 로드 하기 전에 b 의 값을 먼저 로드한다) 기대되지만, C 언어 사양에는 컴파일러가 b 의 값을 추측 (예: 1 과 같음) 해서 b 로드 전에 a 로드를 하는 코드 (예: tmp = a[1]; if (b != 1) tmp = a[b]; ) 를 @@ -1863,6 +1874,7 @@ Mandatory 배리어들은 SMP 시스템에서도 UP 시스템에서도 SMP 효 (*) dma_wmb(); (*) dma_rmb(); + (*) dma_mb(); 이것들은 CPU 와 DMA 가능한 디바이스에서 모두 액세스 가능한 공유 메모리의 읽기, 쓰기 작업들의 순서를 보장하기 위해 consistent memory 에서 사용하기 @@ -1893,12 +1905,13 @@ Mandatory 배리어들은 SMP 시스템에서도 UP 시스템에서도 SMP 효 dma_rmb() 는 디스크립터로부터 데이터를 읽어오기 전에 디바이스가 소유권을 내려놓았을 것을 보장하고, dma_wmb() 는 디바이스가 자신이 소유권을 다시 - 가졌음을 보기 전에 디스크립터에 데이터가 쓰였을 것을 보장합니다. 참고로, - writel() 을 사용하면 캐시 일관성이 있는 메모리 (cache coherent memory) - 쓰기가 MMIO 영역에의 쓰기 전에 완료되었을 것을 보장하므로 writel() 앞에 - wmb() 를 실행할 필요가 없음을 알아두시기 바랍니다. writel() 보다 비용이 - 저렴한 writel_relaxed() 는 이런 보장을 제공하지 않으므로 여기선 사용되지 - 않아야 합니다. + 가졌음을 보기 전에 디스크립터에 데이터가 쓰였을 것을 보장합니다. dma_mb() + 는 dma_rmb() 와 dma_wmb() 를 모두 내포합니다. 참고로, writel() 을 + 사용하면 캐시 일관성이 있는 메모리 (cache coherent memory) 쓰기가 MMIO + 영역에의 쓰기 전에 완료되었을 것을 보장하므로 writel() 앞에 wmb() 를 + 실행할 필요가 없음을 알아두시기 바랍니다. writel() 보다 비용이 저렴한 + writel_relaxed() 는 이런 보장을 제공하지 않으므로 여기선 사용되지 않아야 + 합니다. writel_relaxed() 와 같은 완화된 I/O 접근자들에 대한 자세한 내용을 위해서는 "커널 I/O 배리어의 효과" 섹션을, consistent memory 에 대한 자세한 내용을 @@ -1918,6 +1931,14 @@ Mandatory 배리어들은 SMP 시스템에서도 UP 시스템에서도 SMP 효 Persistent memory 에서의 로드를 위해선 현재의 읽기 메모리 배리어로도 읽기 순서를 보장하는데 충분합니다. + (*) io_stop_wc(); + + 쓰기와 결합된 특성을 갖는 메모리 액세스의 경우 (예: ioremap_wc() 에 의해 + 리턴되는 것들), CPU 는 앞의 액세스들이 뒤따르는 것들과 병합되게끔 기다릴 + 수 있습니다. io_stop_wc() 는 그런 기다림이 성능에 영향을 끼칠 수 있을 때, + 이 매크로 앞의 쓰기-결합된 메모리 액세스들이 매크로 뒤의 것들과 병합되는 + 것을 방지하기 위해 사용될 수 있습니다. + ========================= 암묵적 커널 메모리 배리어 ========================= @@ -2827,9 +2848,9 @@ ld.acq 와 stl.rel 인스트럭션을 각각 만들어 내도록 합니다. DEC Alpha CPU 는 가장 완화된 메모리 순서의 CPU 중 하나입니다. 뿐만 아니라, Alpha CPU 의 일부 버전은 분할된 데이터 캐시를 가지고 있어서, 의미적으로 관계되어 있는 두개의 캐시 라인이 서로 다른 시간에 업데이트 되는게 가능합니다. -이게 데이터 의존성 배리어가 정말 필요해지는 부분인데, 데이터 의존성 배리어는 -메모리 일관성 시스템과 함께 두개의 캐시를 동기화 시켜서, 포인터 변경과 새로운 -데이터의 발견을 올바른 순서로 일어나게 하기 때문입니다. +이게 주소 의존성 배리어가 정말 필요해지는 부분인데, 주소 의존성 배리어는 메모리 +일관성 시스템과 함께 두개의 캐시를 동기화 시켜서, 포인터 변경과 새로운 데이터의 +발견을 올바른 순서로 일어나게 하기 때문입니다. 리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다만, v4.15 부터는 Alpha 용 READ_ONCE() 코드 내에 smp_mb() 가 추가되어서 메모리 모델로의 diff --git a/Documentation/translations/zh_CN/loongarch/booting.rst b/Documentation/translations/zh_CN/loongarch/booting.rst new file mode 100644 index 000000000000..fb6440c438f0 --- /dev/null +++ b/Documentation/translations/zh_CN/loongarch/booting.rst @@ -0,0 +1,48 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/loongarch/booting.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +==================== +启动 Linux/LoongArch +==================== + +:作者: 司延腾 <siyanteng@loongson.cn> +:日期: 2022年11月18日 + +BootLoader传递给内核的信息 +========================== + +LoongArch支持ACPI和FDT启动，需要传递给内核的信息包括memmap、initrd、cmdline、可 +选的ACPI/FDT表等。 + +内核在 `kernel_entry` 入口处被传递以下参数: + + - a0 = efi_boot: `efi_boot` 是一个标志，表示这个启动环境是否完全符合UEFI + 的要求。 + + - a1 = cmdline: `cmdline` 是一个指向内核命令行的指针。 + + - a2 = systemtable: `systemtable` 指向EFI的系统表，在这个阶段涉及的所有 + 指针都是物理地址。 + +Linux/LoongArch内核镜像文件头 +============================= + +内核镜像是EFI镜像。作为PE文件，它们有一个64字节的头部结构体，如下所示:: + + u32 MZ_MAGIC /* "MZ", MS-DOS 头 */ + u32 res0 = 0 /* 保留 */ + u64 kernel_entry /* 内核入口点 */ + u64 _end - _text /* 内核镜像有效大小 */ + u64 load_offset /* 加载内核镜像相对内存起始地址的偏移量 */ + u64 res1 = 0 /* 保留 */ + u64 res2 = 0 /* 保留 */ + u64 res3 = 0 /* 保留 */ + u32 LINUX_PE_MAGIC /* 魔术数 */ + u32 pe_header - _head /* 到PE头的偏移量 */ diff --git a/Documentation/translations/zh_CN/loongarch/index.rst b/Documentation/translations/zh_CN/loongarch/index.rst index 7d23eb78379d..0273a08342f7 100644 --- a/Documentation/translations/zh_CN/loongarch/index.rst +++ b/Documentation/translations/zh_CN/loongarch/index.rst @@ -14,6 +14,7 @@ LoongArch体系结构 :numbered: introduction + booting irq-chip-model features diff --git a/Documentation/translations/zh_CN/loongarch/introduction.rst b/Documentation/translations/zh_CN/loongarch/introduction.rst index 128878f5bb70..f3ec25b163d7 100644 --- a/Documentation/translations/zh_CN/loongarch/introduction.rst +++ b/Documentation/translations/zh_CN/loongarch/introduction.rst @@ -70,8 +70,8 @@ LA64中每个寄存器为64位宽。 ``$r0`` 的内容总是固定为0，而其 ================= ================== =================== ========== .. note:: - 注意：在一些遗留代码中有时可能见到 ``$v0`` 和 ``$v1`` ，它们是 - ``$a0`` 和 ``$a1`` 的别名，属于已经废弃的用法。 + 注意：在一些遗留代码中有时可能见到 ``$fv0`` 和 ``$fv1`` ，它们是 + ``$fa0`` 和 ``$fa1`` 的别名，属于已经废弃的用法。 向量寄存器 diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst index 5bf953146929..888978a62db3 100644 --- a/Documentation/translations/zh_CN/process/howto.rst +++ b/Documentation/translations/zh_CN/process/howto.rst @@ -45,7 +45,7 @@ Linux内核大部分是由C语言写成的，一些体系结构相关的代码 - "C: A Reference Manual" by Harbison and Steele [Prentice Hall] 《C语言参考手册（原书第5版）》（邱仲潘 等译）[机械工业出版社] -Linux内核使用GNU C和GNU工具链开发。虽然它遵循ISO C89标准，但也用到了一些 +Linux内核使用GNU C和GNU工具链开发。虽然它遵循ISO C11标准，但也用到了一些 标准中没有定义的扩展。内核是自给自足的C环境，不依赖于标准C库的支持，所以 并不支持C标准中的部分定义。比如long long类型的大数除法和浮点运算就不允许 使用。有时候确实很难弄清楚内核对工具链的要求和它所使用的扩展，不幸的是目 diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst index 86b0d4c6d6f9..8fb8edcaee66 100644 --- a/Documentation/translations/zh_TW/process/howto.rst +++ b/Documentation/translations/zh_TW/process/howto.rst @@ -48,7 +48,7 @@ Linux內核大部分是由C語言寫成的，一些體系結構相關的代碼 - "C: A Reference Manual" by Harbison and Steele [Prentice Hall] 《C語言參考手冊（原書第5版）》（邱仲潘 等譯）[機械工業出版社] -Linux內核使用GNU C和GNU工具鏈開發。雖然它遵循ISO C89標準，但也用到了一些 +Linux內核使用GNU C和GNU工具鏈開發。雖然它遵循ISO C11標準，但也用到了一些 標準中沒有定義的擴展。內核是自給自足的C環境，不依賴於標準C庫的支持，所以 並不支持C標準中的部分定義。比如long long類型的大數除法和浮點運算就不允許 使用。有時候確實很難弄清楚內核對工具鏈的要求和它所使用的擴展，不幸的是目 diff --git a/Documentation/userspace-api/media/cec.h.rst.exceptions b/Documentation/userspace-api/media/cec.h.rst.exceptions index 13de01d9555e..15fa1752d4ef 100644 --- a/Documentation/userspace-api/media/cec.h.rst.exceptions +++ b/Documentation/userspace-api/media/cec.h.rst.exceptions @@ -239,6 +239,7 @@ ignore define CEC_OP_FEAT_DEV_HAS_DECK_CONTROL ignore define CEC_OP_FEAT_DEV_HAS_SET_AUDIO_RATE ignore define CEC_OP_FEAT_DEV_SINK_HAS_ARC_TX ignore define CEC_OP_FEAT_DEV_SOURCE_HAS_ARC_RX +ignore define CEC_OP_FEAT_DEV_HAS_SET_AUDIO_VOLUME_LEVEL ignore define CEC_MSG_GIVE_FEATURES @@ -487,6 +488,7 @@ ignore define CEC_OP_SYS_AUD_STATUS_ON ignore define CEC_MSG_SYSTEM_AUDIO_MODE_REQUEST ignore define CEC_MSG_SYSTEM_AUDIO_MODE_STATUS +ignore define CEC_MSG_SET_AUDIO_VOLUME_LEVEL ignore define CEC_OP_AUD_FMT_ID_CEA861 ignore define CEC_OP_AUD_FMT_ID_CEA861_CXT diff --git a/Documentation/userspace-api/media/v4l/libv4l-introduction.rst b/Documentation/userspace-api/media/v4l/libv4l-introduction.rst index 90215313b965..7c8bf160e1c6 100644 --- a/Documentation/userspace-api/media/v4l/libv4l-introduction.rst +++ b/Documentation/userspace-api/media/v4l/libv4l-introduction.rst @@ -136,9 +136,9 @@ V4L2 functions operates like the :c:func:`read()` function. -.. c:function:: void v4l2_mmap(void *start, size_t length, int prot, int flags, int fd, int64_t offset); +.. c:function:: void *v4l2_mmap(void *start, size_t length, int prot, int flags, int fd, int64_t offset); - operates like the :c:func:`munmap()` function. + operates like the :c:func:`mmap()` function. .. c:function:: int v4l2_munmap(void *_start, size_t length); diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index eee9f857a986..896914e3a847 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -7213,14 +7213,13 @@ veto the transition. :Parameters: args[0] is the maximum poll time in nanoseconds :Returns: 0 on success; -1 on error -This capability overrides the kvm module parameter halt_poll_ns for the -target VM. - -VCPU polling allows a VCPU to poll for wakeup events instead of immediately -scheduling during guest halts. The maximum time a VCPU can spend polling is -controlled by the kvm module parameter halt_poll_ns. This capability allows -the maximum halt time to specified on a per-VM basis, effectively overriding -the module parameter for the target VM. +KVM_CAP_HALT_POLL overrides the kvm.halt_poll_ns module parameter to set the +maximum halt-polling time for all vCPUs in the target VM. This capability can +be invoked at any time and any number of times to dynamically change the +maximum halt-polling time. + +See Documentation/virt/kvm/halt-polling.rst for more information on halt +polling. 7.21 KVM_CAP_X86_USER_SPACE_MSR ------------------------------- diff --git a/Documentation/virt/kvm/devices/vm.rst b/Documentation/virt/kvm/devices/vm.rst index 0aa5b1cfd700..60acc39e0e93 100644 --- a/Documentation/virt/kvm/devices/vm.rst +++ b/Documentation/virt/kvm/devices/vm.rst @@ -215,6 +215,7 @@ KVM_S390_VM_TOD_EXT). :Parameters: address of a buffer in user space to store the data (u8) to :Returns: -EFAULT if the given address is not accessible from kernel space; -EINVAL if setting the TOD clock extension to != 0 is not supported + -EOPNOTSUPP for a PV guest (TOD managed by the ultravisor) 3.2. ATTRIBUTE: KVM_S390_VM_TOD_LOW ----------------------------------- @@ -224,6 +225,7 @@ the POP (u64). :Parameters: address of a buffer in user space to store the data (u64) to :Returns: -EFAULT if the given address is not accessible from kernel space + -EOPNOTSUPP for a PV guest (TOD managed by the ultravisor) 3.3. ATTRIBUTE: KVM_S390_VM_TOD_EXT ----------------------------------- @@ -237,6 +239,7 @@ it, it is stored as 0 and not allowed to be set to a value != 0. (kvm_s390_vm_tod_clock) to :Returns: -EFAULT if the given address is not accessible from kernel space; -EINVAL if setting the TOD clock extension to != 0 is not supported + -EOPNOTSUPP for a PV guest (TOD managed by the ultravisor) 4. GROUP: KVM_S390_VM_CRYPTO ============================ diff --git a/Documentation/virt/kvm/x86/halt-polling.rst b/Documentation/virt/kvm/halt-polling.rst index 4922e4a15f18..3fae39b1a5ba 100644 --- a/Documentation/virt/kvm/x86/halt-polling.rst +++ b/Documentation/virt/kvm/halt-polling.rst @@ -119,6 +119,19 @@ These module parameters can be set from the debugfs files in: Note: that these module parameters are system wide values and are not able to be tuned on a per vm basis. +Any changes to these parameters will be picked up by new and existing vCPUs the +next time they halt, with the notable exception of VMs using KVM_CAP_HALT_POLL +(see next section). + +KVM_CAP_HALT_POLL +================= + +KVM_CAP_HALT_POLL is a VM capability that allows userspace to override halt_poll_ns +on a per-VM basis. VMs using KVM_CAP_HALT_POLL ignore halt_poll_ns completely (but +still obey halt_poll_ns_grow, halt_poll_ns_grow_start, and halt_poll_ns_shrink). + +See Documentation/virt/kvm/api.rst for more information on this capability. + Further Notes ============= diff --git a/Documentation/virt/kvm/index.rst b/Documentation/virt/kvm/index.rst index e0a2c74e1043..ad13ec55ddfe 100644 --- a/Documentation/virt/kvm/index.rst +++ b/Documentation/virt/kvm/index.rst @@ -17,4 +17,5 @@ KVM locking vcpu-requests + halt-polling review-checklist diff --git a/Documentation/virt/kvm/x86/index.rst b/Documentation/virt/kvm/x86/index.rst index 7ff588826b9f..9ece6b8dc817 100644 --- a/Documentation/virt/kvm/x86/index.rst +++ b/Documentation/virt/kvm/x86/index.rst @@ -10,7 +10,6 @@ KVM for x86 systems amd-memory-encryption cpuid errata - halt-polling hypercalls mmu msr |