| /linux-6.1.9/Documentation/driver-api/thermal/ |
| D | cpu-idle-cooling.rst | 25 because of the OPP density, we can only choose an OPP with a power
35 If we can remove the static and the dynamic leakage for a specific
38 injection period, we can mitigate the temperature by modulating the
47 At a specific OPP, we can assume that injecting idle cycle on all CPUs
49 idle state target residency, we lead to dropping the static and the
132 - It is less than or equal to the latency we tolerate when the
134 user experience, reactivity vs performance trade off we want. This
137 - It is greater than the idle state’s target residency we want to go
138 for thermal mitigation, otherwise we end up consuming more energy.
143 When we reach the thermal trip point, we have to sustain a specified
[all …]
|
| /linux-6.1.9/Documentation/devicetree/bindings/pinctrl/ |
| D | sprd,pinctrl.txt | 12 to choose one function (like: UART0) for which system, since we
15 There are too much various configuration that we can not list all
16 of them, so we can not make every Spreadtrum-special configuration
18 global configuration in future. Then we add one "sprd,control" to
19 set these various global control configuration, and we need use
22 Moreover we recognise every fields comprising one bit or several
23 bits in one global control register as one pin, thus we should
32 Now we have 4 systems for sleep mode on SC9860 SoC: AP system,
42 In some situation we need set the pin sleep mode and pin sleep related
45 sleep mode. For example, if we set the pin sleep mode as PUBCP_SLEEP
[all …]
|
| /linux-6.1.9/Documentation/x86/ |
| D | entry_64.rst | 58 so. If we mess that up even slightly, we crash.
60 So when we have a secondary entry, already in kernel mode, we *must
61 not* use SWAPGS blindly - nor must we forget doing a SWAPGS when it's
87 If we are at an interrupt or user-trap/gate-alike boundary then we can
89 whether SWAPGS was already done: if we see that we are a secondary
90 entry interrupting kernel mode execution, then we know that the GS
91 base has already been switched. If it says that we interrupted
92 user-space execution then we must do the SWAPGS.
94 But if we are in an NMI/MCE/DEBUG/whatever super-atomic entry context,
96 stack but before we executed SWAPGS, then the only safe way to check
[all …]
|
| /linux-6.1.9/Documentation/dev-tools/kunit/ |
| D | run_wrapper.rst | 10 As long as we can build the kernel, we can run KUnit.
44 kunit_tool. This is useful if we have several different groups of
45 tests we want to run independently, or if we want to use pre-defined
64 If we want to run a specific set of tests (rather than those listed
65 in the KUnit ``defconfig``), we can provide Kconfig options in the
90 set in the kernel ``.config`` before running the tests. It warns if we
96 This means that we can use other tools
104 If we want to make manual changes to the KUnit build process, we
106 When running kunit_tool, from a ``.kunitconfig``, we can generate a
113 To build a KUnit kernel from the current ``.config``, we can use the
[all …]
|
| /linux-6.1.9/Documentation/filesystems/ext4/ |
| D | orphan.rst | 9 would leak. Similarly if we truncate or extend the file, we need not be able
10 to perform the operation in a single journalling transaction. In such case we
17 inode (we overload i_dtime inode field for this). However this filesystem
36 When a filesystem with orphan file feature is writeably mounted, we set
38 be valid orphan entries. In case we see this feature when mounting the
39 filesystem, we read the whole orphan file and process all orphan inodes found
40 there as usual. When cleanly unmounting the filesystem we remove the
|
| /linux-6.1.9/tools/lib/perf/Documentation/ |
| D | libperf-counting.txt | 73 Once the setup is complete we start by defining specific events using the `struct perf_event_attr`.
97 In this case we will monitor current process, so we create threads map with single pid (0):
110 Now we create libperf's event list, which will serve as holder for the events we want:
121 We create libperf's events for the attributes we defined earlier and add them to the list:
156 so we need to enable the whole list explicitly (both events).
158 From this moment events are counting and we can do our workload.
160 When we are done we disable the events list.
171 Now we need to get the counts from events, following code iterates through the
|
| /linux-6.1.9/Documentation/scheduler/ |
| D | schedutil.rst | 8 we know this is flawed, but it is the best workable approximation.
14 With PELT we track some metrics across the various scheduler entities, from
16 we use an Exponentially Weighted Moving Average (EWMA), each period (1024us)
35 Using this we track 2 key metrics: 'running' and 'runnable'. 'Running'
50 a big CPU, we allow architectures to scale the time delta with two ratios, one
53 For simple DVFS architectures (where software is in full control) we trivially
60 For more dynamic systems where the hardware is in control of DVFS we use
62 For Intel specifically, we use::
84 of DVFS and CPU type. IOW. we can transfer and compare them between CPUs.
125 migration, time progression) we call out to schedutil to update the hardware
[all …]
|
| /linux-6.1.9/Documentation/filesystems/ |
| D | xfs-delayed-logging-design.rst | 16 transaction reservations are structured and accounted, and then move into how we
18 reservations bounds. At this point we need to explain how relogging works. With
113 individual modification is atomic, the chain is *not atomic*. If we crash half
140 complete, we can explicitly tag a transaction as synchronous. This will trigger
145 throughput to the IO latency limitations of the underlying storage. Instead, we
161 available to write the modification into the journal before we start making
164 log in the worst case. This means that if we are modifying a btree in the
165 transaction, we have to reserve enough space to record a full leaf-to-root split
166 of the btree. As such, the reservations are quite complex because we have to
173 again. Then we might have to update reverse mappings, which modifies yet
[all …]
|
| D | directory-locking.rst | 10 When taking the i_rwsem on multiple non-directory objects, we
16 1) read access. Locking rules: caller locks directory we are accessing.
29 lock it. If we need to lock both, lock them in inode pointer order.
31 NB: we might get away with locking the source (and target in exchange
55 lock it. If we need to lock both, do so in inode pointer order.
58 All ->i_rwsem are taken exclusive. Again, we might get away with locking
69 First of all, at any moment we have a partial ordering of the
75 attempts to acquire lock on B, A will remain the parent of B until we
81 renames will be blocked on filesystem lock and we don't start changing
82 the order until we had acquired all locks).
[all …]
|
| D | path-lookup.txt | 49 the path given by the name's starting point (which we know in advance -- eg.
55 A parent, of course, must be a directory, and we must have appropriate
79 In order to lookup a dcache (parent, name) tuple, we take a hash on the tuple
81 in that bucket is then walked, and we do a full comparison of each entry
148 However, when inserting object 2 onto a new list, we end up with this:
161 Because we didn't wait for a grace period, there may be a concurrent lookup
182 As explained above, we would like to do path walking without taking locks or
188 than reloading from the dentry later on (otherwise we'd have interesting things
192 no non-atomic stores to shared data), and to recheck the seqcount when we are
194 Avoiding destructive or changing operations means we can easily unwind from
[all …]
|
| D | idmappings.rst | 23 on, we will always prefix ids with ``u`` or ``k`` to make it clear whether
24 we're talking about an id in the upper or lower idmapset.
42 that make it easier to understand how we can translate between idmappings. For
43 example, we know that the inverse idmapping is an order isomorphism as well::
49 Given that we are dealing with order isomorphisms plus the fact that we're
50 dealing with subsets we can embedd idmappings into each other, i.e. we can
51 sensibly translate between different idmappings. For example, assume we've been
61 Because we're dealing with order isomorphic subsets it is meaningful to ask
64 mapping ``k11000`` up to ``u1000``. Afterwards, we can map ``u1000`` down using
69 If we were given the same task for the following three idmappings::
[all …]
|
| /linux-6.1.9/drivers/block/paride/ |
| D | Transition-notes | 9 ps_spinlock. C is always preceded by B, since we can't reach it
10 other than through B and we don't drop ps_spinlock between them.
14 A and each B is preceded by either A or C. Moments when we enter
37 * in ps_tq_int(): from the moment when we get ps_spinlock() to the
73 we would have to be called for the PIA that got ->claimed_cont
83 it is holding pd_lock. The only place within the area where we
87 we were acquiring the lock, (1) would be already false, since
89 If it was 0 before we tried to acquire pd_lock, (2) would be
96 (4) is done the same way - all places where we release pi_spinlock within
100 in the area, under pi_spinlock and we do not release it until after leaving
[all …]
|
| /linux-6.1.9/Documentation/gpu/amdgpu/display/ |
| D | dcn-overview.rst | 6 (DCN) works, we need to start with an overview of the hardware pipeline. Below
8 generic diagram, and we have variations per ASIC.
12 Based on this diagram, we can pass through each block and briefly describe
58 setup or ignored accordingly with userspace demands. For example, if we
77 From DCHUB to MPC, we have a representation called dc_plane; from MPC to OPTC,
78 we have dc_stream, and the output (DIO) is handled by dc_link. Keep in mind
100 a one-to-one mapping of the link encoder to PHY, but we can configure the DCN
123 depth format), bit-depth reduction/dithering would kick in. In OPP, we would
125 Eventually, we output data in integer format at DIO.
131 overloaded with multiple meanings, so it is important to define what we mean
[all …]
|
| /linux-6.1.9/drivers/scsi/aic7xxx/ |
| D | aic79xx.seq | 85 * If we have completions stalled waiting for the qfreeze
109 * ENSELO is cleared by a SELDO, so we must test for SELDO
169 * Since this status did not consume a FIFO, we have to
170 * be a bit more dilligent in how we check for FIFOs pertaining
178 * count in the SCB. In this case, we allow the routine servicing
183 * we detect case 1, we will properly defer the post of the SCB
222 * bad SCSI status (currently only for underruns), we
223 * queue the SCB for normal completion. Otherwise, we
258 * If we have relatively few commands outstanding, don't
303 * one byte of lun information we support.
[all …]
|
| D | aic7xxx.seq | 52 * After starting the selection hardware, we check for reconnecting targets
54 * bus arbitration. The problem with this is that we must keep track of the
55 * SCB that we've already pulled from the QINFIFO and started the selection
56 * on just in case the reselection wins so that we can retry the selection at
104 * We have at least one queued SCB now and we don't have any
124 * before we completed the DMA operation. If it was,
211 /* The Target ID we were selected at */
239 * Watch ATN closely now as we pull in messages from the
285 * we've got a failed selection and must transition to bus
333 * Reselection has been initiated by a target. Make a note that we've been
[all …]
|
| /linux-6.1.9/Documentation/RCU/ |
| D | rculist_nulls.rst | 36 * reuse these object before the RCU grace period, we
39 if (obj->key != key) { // not the object we expected
104 * we need to make sure obj->key is updated before obj->next
115 Nothing special here, we can use a standard RCU hlist deletion.
135 With hlist_nulls we can avoid extra smp_rmb() in lockless_lookup()
138 For example, if we choose to store the slot number as the 'nulls'
139 end-of-list marker for each slot of the hash table, we can detect
143 is not the slot number, then we must restart the lookup at
161 if (obj->key != key) { // not the object we expected
168 * if the nulls value we got at the end of this lookup is
[all …]
|
| /linux-6.1.9/Documentation/sound/designs/ |
| D | jack-injection.rst | 10 validate ALSA userspace changes. For example, we change the audio
11 profile switching code in the pulseaudio, and we want to verify if the
13 in this case, we could inject plugin or plugout events to an audio
14 jack or to some audio jacks, we don't need to physically access the
26 To inject events to audio jacks, we need to enable the jack injection
28 change the state by hardware events anymore, we could inject plugin or
30 ``status``, after we finish our test, we need to disable the jack
|
| /linux-6.1.9/drivers/gpu/drm/i915/ |
| D | Kconfig.profile | 19 When listening to a foreign fence, we install a supplementary timer
20 to ensure that we are always signaled and our userspace is able to
31 On runtime suspend, as we suspend the device, we have to revoke
34 the GGTT mmap can be very slow and so we impose a small hysteris
79 we may spend some time polling for its completion. As the IRQ may
80 take a non-negligible time to setup, we do a short spin first to
87 May be 0 to disable the initial spin. In practice, we estimate
96 the GPU, we allow the innocent contexts also on the system to quiesce.
109 When two user batches of equal priority are executing, we will
|
| /linux-6.1.9/Documentation/driver-api/firmware/ |
| D | lookup-order.rst | 9 * The ''Built-in firmware'' is checked first, if the firmware is present we
11 * The ''Firmware cache'' is looked at next. If the firmware is found we
13 * The ''Direct filesystem lookup'' is performed next, if found we
16 firmware_request_platform() is used, if found we return it immediately
|
| /linux-6.1.9/Documentation/block/ |
| D | deadline-iosched.rst | 20 service time for a request. As we focus mainly on read latencies, this is
49 When we have to move requests from the io scheduler queue to the block
50 device dispatch queue, we always give a preference to reads. However, we
52 how many times we give preference to reads over writes. When that has been
53 done writes_starved number of times, we dispatch some writes based on the
68 that comes at basically 0 cost we leave that on. We simply disable the
|
| /linux-6.1.9/Documentation/powerpc/ |
| D | kasan.txt | 39 checks can be delayed until after the MMU is set is up, and we can just not
44 linear mapping, using the same high-bits trick we use for the rest of the linear
47 - We'd like to place it near the start of physical memory. In theory we can do
48 this at run-time based on how much physical memory we have, but this requires
51 is hopefully something we can revisit once we get KASLR for Book3S.
53 - Alternatively, we can place the shadow at the _end_ of memory, but this
|
| D | pci_iov_resource_on_powernv.rst | 40 The following section provides a rough description of what we have on P8
52 For DMA, MSIs and inbound PCIe error messages, we have a table (in
57 - For DMA we then provide an entire address space for each PE that can
63 - For MSIs, we have two windows in the address space (one at the top of
91 reserved for MSIs but this is not a problem at this point; we just
93 ignores that however and will forward in that space if we try).
100 Now, this is the "main" window we use in Linux today (excluding
105 Ideally we would like to be able to have individual functions in PEs
116 bits which are not conveyed by PowerBus but we don't use this.
118 * Can be configured to be segmented. When not segmented, we can
[all …]
|
| /linux-6.1.9/Documentation/power/ |
| D | freezing-of-tasks.rst | 22 we only consider hibernation, but the description also applies to suspend).
33 it loop until PF_FROZEN is cleared for it. Then, we say that the task is
80 - freezes all tasks (including kernel threads) because we can't freeze
84 - thaws only kernel threads; this is particularly useful if we need to do
86 userspace tasks, or if we want to postpone the thawing of userspace tasks
89 - thaws all tasks (including kernel threads) because we can't thaw userspace
101 IV. Why do we do that?
107 hibernation. At the moment we have no simple means of checkpointing
109 metadata on disks, we cannot bring them back to the state from before the
121 2. Next, to create the hibernation image we need to free a sufficient amount of
[all …]
|
| /linux-6.1.9/arch/mips/vdso/ |
| D | Kconfig | 5 # of which we are forced to disable the VDSO symbols when building
6 # with < 2.25 binutils on pre-R6 kernels. For more references on why we
11 # of the GOT when targeting microMIPS, which we can't use in the VDSO due to
12 # the lack of relocations. As such, we disable the VDSO for microMIPS builds.
|
| /linux-6.1.9/rust/alloc/ |
| D | README.md | 18 (e.g. receiver types if we ended up using them), which is reasonable.
24 We agreed on a middle-ground: we would keep a subset of `alloc`
26 Then, upstream can start adding the functions that we add to `alloc`
27 etc., until we reach a point where the kernel already knows exactly
29 upstream, so that we can drop `alloc` from the kernel tree and go back
|