Home
last modified time | relevance | path

Searched full:quite (Results 1 – 25 of 1023) sorted by relevance

12345678910>>...41

/openbmc/linux/Documentation/locking/
H A Dpi-futex.rst34 can see it in the kernel [which is a quite complex program in itself],
67 [this is a quite common scenario for most non-trivial RT applications],
79 mutexes involves no kernel work at all - they behave quite similarly to
114 there is no prior 'registration' of a PI-futex. [which is not quite
/openbmc/linux/Documentation/admin-guide/
H A Dcpu-load.rst21 In most cases the ``/proc/stat`` information reflects the reality quite
44 (only to be awaken quite soon)
52 will lead to quite erratic information inside ``/proc/stat``::
/openbmc/linux/tools/memory-model/Documentation/
H A Dsimple.txt6 (LKMM) is quite complex, with subtle differences in code often having
9 The options near the beginning of this list are quite simple. The idea
79 In the kernel, what is the "library"? Quite a bit. It includes the
194 Reading code using these primitives is often also quite helpful.
240 It can be quite tempting to use plain C-language accesses for lockless
242 possible and quite common in the Linux kernel, it does require a
/openbmc/linux/Documentation/filesystems/
H A Dromfs.rst7 This is a quite dumb, read only filesystem, mainly for initial RAM
42 filesystems, like the quite large ext2fs module, which can then be
55 bytes. This is quite rare however, since most file names are longer
87 the source. This algorithm was chosen because although it's not quite
184 - Compression might be an useful feature, but memory is quite a
H A Dubifs.rst38 It should be quite obvious why UBIFS is very different to traditional
63 it possible to fit quite a lot of data to the flash.
/openbmc/linux/arch/arm/mach-omap2/
H A Dcm2xxx.h9 * The CM hardware modules on the OMAP2/3 are quite similar to each
10 * other. The CM modules/instances on OMAP4 are quite different, so
H A Dcm3xxx.h9 * The CM hardware modules on the OMAP2/3 are quite similar to each
10 * other. The CM modules/instances on OMAP4 are quite different, so
H A Dcm2xxx_3xxx.h9 * The CM hardware modules on the OMAP2/3 are quite similar to each
10 * other. The CM modules/instances on OMAP4 are quite different, so
/openbmc/linux/tools/objtool/arch/x86/
H A Dspecial.c68 * for the function, but that would require redesigning the code quite a
79 * As of GCC 7 there are quite a few more of these and the 'in between' code
131 * Use of RIP-relative switch jumps is quite rare, and in arch_find_switch_table()
/openbmc/u-boot/doc/
H A DREADME.i2c5 The implementation on the master side in software is quite complex.
58 to the bus quite rarely (maybe every 10s or 30s to check the battery). This
/openbmc/linux/drivers/leds/
H A DTODO28 i/o port is really quite different from camera flash LED, which is
50 RGB LEDs are quite common, and it would be good to be able to turn LED
/openbmc/linux/arch/sh/drivers/pci/
H A Dfixups-dreamcast.c77 * The interrupt routing semantics here are quite trivial. in pcibios_map_platform_irq()
81 * interrupt. Keeps routing quite simple, doesn't it? in pcibios_map_platform_irq()
/openbmc/linux/fs/reiserfs/
H A DREADME65 quite cryptic if your forget to do so.
91 was quite remarkable. I don't think that money can ever motivate someone
98 Vladimir throughout the project's development. He wrote a quite
/openbmc/qemu/contrib/gitdm/
H A Dgroup-map-academics2 # QEMU is quite often used for academic research purposes and we like
/openbmc/linux/Documentation/devicetree/bindings/net/
H A Dvia-velocity.txt10 devices quite often set this data in uboot and do not provide an eeprom.
/openbmc/linux/Documentation/networking/
H A Darcnet.rst51 individual chipset drivers, and the source files aren't quite so packed with
269 quite the way Linux does (actually, it doesn't multitask AT ALL) but
302 interface quite nicely with TCP/IP-based WfWg or Lan Manager
366 smaller than the Internet "requirement," so it's quite
494 It's quite fortunate that I set things up like this the first time (cough
551 which is obviously quite big.
/openbmc/linux/drivers/media/i2c/
H A Dtea6415c.h5 /* the tea6415c's design is quite brain-dead. although there are
/openbmc/linux/fs/netfs/
H A DKconfig20 execution as there are a quite a few stats gathered, and on a
/openbmc/linux/arch/arm64/boot/dts/qcom/
H A Dapq8094-sony-xperia-kitakami-karin_windy.dts8 /* As the names may imply, there is quite a bunch of duplication there. */
/openbmc/u-boot/arch/arm/include/asm/arch-tegra124/
H A Dclock.h34 * Return the PLLD frequenc (which may not quite what was requested), or 0
/openbmc/linux/Documentation/userspace-api/media/v4l/
H A Dext-ctrls-dv.rst85 standard correctly (unfortunately quite common for HDMI and DVI-D).
144 standard correctly (unfortunately quite common for HDMI and DVI-D).
/openbmc/linux/tools/include/nolibc/
H A Dstd.h10 /* Declare a few quite common macros and types that usually are in stdlib.h,
/openbmc/linux/include/linux/
H A Dsecretmem.h14 * Using folio_mapping() is quite slow because of the actual call in folio_is_secretmem()
/openbmc/phosphor-dbus-interfaces/yaml/com/ibm/ipzvpd/
H A DREADME.md8 The [OpenPower VPD][1] format is quite similar to the IPZ format and describes
/openbmc/openbmc/meta-openembedded/meta-perl/recipes-perl/libsub/
H A Dlibsub-uplevel-perl_0.2800.bb2 DESCRIPTION = " Like Tcl's uplevel() function, but not quite so dangerous. \

12345678910>>...41