Home
last modified time | relevance | path

Searched full:much (Results 1 – 25 of 2416) sorted by relevance

12345678910>>...97

/linux-6.8/drivers/media/pci/bt8xx/
Dbttv-audio-hook.c60 /* Not much to do here */ in gvbctv3pci_audio()
162 /* Not much to do here */ in avermedia_tvphone_audio()
193 /* Not much to do here */ in avermedia_tv_stereo_audio()
231 /* Not much to do here */ in lt9415_audio()
264 /* Not much to do here */ in terratv_audio()
336 /* Not much to do here */ in pvbt878p9b_audio()
377 /* Not much to do here */ in fv2000s_audio()
413 /* Not much to do here */ in windvr_audio()
450 /* Not much to do here */ in adtvk503_audio()
/linux-6.8/Documentation/arch/x86/
Dorc-unwinder.rst12 format of the ORC data is much simpler than DWARF, which in turn allows
13 the ORC unwinder to be much simpler and faster.
63 ORC debuginfo's advantage over DWARF itself is that it's much simpler.
66 much simpler, meaning fewer bugs, which is especially important for
69 The simpler debuginfo format also enables the unwinder to be much faster
114 annotations are needed than what DWARF would need, so they're much more
/linux-6.8/include/linux/
Dtimex.h90 * SHIFT_PLL is used as a dampening factor to define how much we
93 * much of the current value in time_offset we correct for each
100 * However this seems to increase convergence time much too long.
114 * SHIFT_FLL is used as a dampening factor to define how much we
Dzstd.h296 * @output: Destination buffer. `output->pos` is updated to indicate how much
298 * @input: Source buffer. `input->pos` is updated to indicate how much data
316 * @output: Destination buffer. `output->pos` is updated to indicate how much
331 * @output: Destination buffer. `output->pos` is updated to indicate how much
383 * @output: Destination buffer. `output.pos` is updated to indicate how much
385 * @input: Source buffer. `input.pos` is updated to indicate how much data was
Dstringhash.h18 * malicious inputs; much slower hash functions are required for that.
62 * this computes a different hash function much faster.
Dnfs_iostat.h48 * traffic. NORMAL + DIRECT shows how much data is going through
50 * without much NORMAL or DIRECT traffic shows that applications
/linux-6.8/arch/arm64/kernel/
Dwatchdog_hld.c10 * Arm CPUs in the market which are clocked much less than 5 GHz. On the other
11 * hand, we can't make it much higher as it would lead to a large hard-lockup
/linux-6.8/Documentation/process/
Dbotching-up-ioctls.rst14 actually only used once interfaces. But the clear downside is that there's much
110 paths pretty much for free for graphics drivers. Also, be consistent with
160 an asynchronous event on a pollable file descriptor. It fits much better
208 it's much quicker to push a driver-private interface than engaging in
214 * Consider other interfaces than ioctls. A sysfs attribute is much better for
/linux-6.8/arch/mips/include/asm/
Dfloppy.h42 * driver otherwise. It doesn't matter much for performance anyway, as most
47 * Actually this needs to be a bit more complicated since the so much different
/linux-6.8/rust/alloc/collections/
Dmod.rs73 reason = "Uncertain how much info should be exposed",
85 reason = "Uncertain how much info should be exposed",
113 reason = "Uncertain how much info should be exposed",
/linux-6.8/Documentation/scheduler/
Dsched-nice-design.rst9 pestered us to make nice +19 tasks use up much less CPU time.
17 much stronger than they were before in 2.4 (and people were happy about
39 So that if someone wanted to really renice tasks, +19 would give a much
Dsched-design-CFS.rst65 side of the tree as much as possible.
108 The CFS scheduler has a much stronger handling of nice levels and SCHED_BATCH
109 than the previous vanilla scheduler: both types of workloads are isolated much
150 without the core code assuming too much about them.
/linux-6.8/Documentation/
Dsubsystem-apis.rst8 from the point of view of a kernel developer. Much of the information here
64 **Fixme**: much more organizational work is needed here.
/linux-6.8/Documentation/arch/powerpc/
Dkasan.txt48 this at run-time based on how much physical memory we have, but this requires
54 requires knowing how much contiguous physical memory a system has _at compile
/linux-6.8/lib/zstd/common/
Derror_private.c29 … case PREFIX(frameParameter_windowTooLarge): return "Frame requires too much memory for decoding"; in ERR_getErrorString()
38 case PREFIX(tableLog_tooLarge): return "tableLog requires too much memory : unsupported"; in ERR_getErrorString()
/linux-6.8/net/batman-adv/
Dbitarray.c60 /* sequence number is much newer, probably missed a lot of packets */ in batadv_bit_get_packet()
72 /* received a much older packet. The other host either restarted in batadv_bit_get_packet()
/linux-6.8/include/uapi/linux/
Dresource.h76 * The first two don't need much. The latter will take as
77 * much as it can get. 8MB is a reasonably sane default.
/linux-6.8/Documentation/driver-api/driver-model/
Ddevres.rst15 5. Overhead : How much do we have to pay for this?
35 For one reason or another, low level drivers don't receive as much
38 Init failure path is worse because it's much less travelled while
102 driver can have much simpler init and exit code. Init path basically
/linux-6.8/drivers/tty/
Dehv_bytechan.c358 /* Find out how much data needs to be read, and then ask the TTY layer in ehv_bc_tty_rx_isr()
359 * if it can handle that much. We want to ensure that every byte we in ehv_bc_tty_rx_isr()
407 * This function, which can be called in interrupt context, dequeues as much
463 * the data first in a circular buffer, and then dequeue as much of that data
468 * layer how much data it can safely send to us. We guarantee that
470 * too much data.
538 * how much write room the driver can guarantee will be sent OR BUFFERED. This
601 * If we could ask the hypervisor how much data is still in the TX buffer, or
/linux-6.8/Documentation/misc-devices/
Dapds990x.rst26 might vary quite much depending the spectrum of the light source.
68 to saturate much before that. Real max value varies depending
/linux-6.8/arch/arm/include/asm/
Dkgdb.h34 * make our lives much much simpler. :)
/linux-6.8/fs/jffs2/
Dcompr_rtime.c69 /* Tell the caller how much we managed to compress, and how much space it took */ in jffs2_rtime_compress()
/linux-6.8/Documentation/admin-guide/pm/
Dstrategies.rst42 then it takes much less time and effort to start executing user space code than
45 typically the system can spend much more time in a sleep state than it can be
/linux-6.8/drivers/block/drbd/
Ddrbd_vli.h20 * the bitmap transfer time can take much too long,
37 * integers would be much worse than plaintext.
48 * We don't care too much about "excellent" compression ratio for large
50 * or 1000 is not that much of an issue.
51 * We do not want to waste too much on short runlengths in the "noisy"
/linux-6.8/fs/reiserfs/
DREADME117 that he was shown much generosity just makes it more painful.
135 Igor Zagorovsky is writing much of the new item handler and extent code
159 than the ones just named. SuSE has helped in much more than just

12345678910>>...97