Home
last modified time | relevance | path

Searched full:typical (Results 1 – 25 of 473) sorted by relevance

12345678910>>...19

/linux/drivers/iio/test/
H A Diio-test-rescale.c34 * Typical use cases
37 .name = "typical IIO_VAL_INT, positive",
45 .name = "typical IIO_VAL_INT, negative",
53 .name = "typical IIO_VAL_FRACTIONAL, positive",
62 .name = "typical IIO_VAL_FRACTIONAL, negative",
71 .name = "typical IIO_VAL_FRACTIONAL_LOG2, positive",
80 .name = "typical IIO_VAL_FRACTIONAL_LOG2, negative",
89 .name = "typical IIO_VAL_INT_PLUS_NANO, positive",
98 .name = "typical IIO_VAL_INT_PLUS_NANO, negative",
107 .name = "typical IIO_VAL_INT_PLUS_MICRO, positive",
[all …]
/linux/Documentation/devicetree/bindings/display/panel/
H A Dpanel-timing.yaml56 Timing can be specified either as a typical value or as a tuple
78 description: typical number of pixels
90 description: typical number of pixels
102 description: typical number of pixels
114 description: typical number of lines
126 description: typical number of lines
138 description: typical number of lines
/linux/Documentation/devicetree/bindings/pinctrl/
H A Dspacemit,k1-pinctrl.yaml69 typical value for selecting bias pull up or strong pull up.
76 typical current when output high level.
82 typical threshold for schmitt trigger.
H A Dsophgo,cv1800-pinctrl.yaml71 description: typical current when output high level.
74 description: typical threshold for schmitt trigger.
/linux/Documentation/i2c/
H A Dfunctionality.rst69 function callback ``functionality``. Typical implementations are given
72 A typical SMBus-only adapter would list all the SMBus transactions it
82 A typical full-I2C adapter would use the following (from the i2c-pxa
104 check whether the needed functionality is present. The typical way to do
/linux/Documentation/userspace-api/media/
H A Dintro.rst12 A typical media device hardware is shown at :ref:`typical_media_device`.
20 Typical Media Device
/linux/Documentation/mm/
H A Dovercommit-accounting.rst9 space are refused. Used for a typical system. It ensures a
45 largest size you think you will need. For typical stack usage this does
/linux/Documentation/devicetree/bindings/hwmon/
H A Dadi,ltc4282.yaml58 10% and 15% settings with the actual min, typical and max tolerances.
70 10% and 15% settings with the actual min, typical and max tolerances.
/linux/virt/kvm/
H A Dbinary_stats.c38 * as in the limit) from any position, the typical usage would follow below
116 * The descriptors copy would be skipped in the typical case that in kvm_stats_read()
/linux/Documentation/
H A Datomic_t.txt131 the typical solution is to then implement atomic_set{}() with atomic_xchg().
225 is a 'typical' RELEASE pattern, the barrier is strictly stronger than
233 is an ACQUIRE pattern (though very much not typical), but again the barrier is
/linux/tools/virtio/ringtest/
H A DREADME4 Typical use:
/linux/Documentation/driver-api/media/
H A Ddtv-frontend.rst24 A typical example of such struct in a driver ``foo`` is::
64 A typical example of such struct in a driver ``bar`` meant to be used on
277 A typical example of the logic that handle status and statistics is::
391 On such drivers, a typical routine to get statistics would be like
/linux/Documentation/ABI/testing/
H A Ddebugfs-iio-backend11 Directly access the registers of backend Y. Typical usage is:
H A Dsysfs-driver-w1_therm7 (typical -55 degC to 125 degC), if not values will be trimmed
24 limited EEPROM writing cycles (typical 50k)
H A Dsysfs-bus-iio-mpu60508 is a 3x3 unitary matrix. A typical mounting matrix would look like
H A Dsysfs-class-power-wilco11 typical battery usage pattern.
/linux/drivers/cpufreq/
H A Dgx-suspmod.c88 #define PCI_IRQTC 0x8c /* irq speedup timer counter register:typical 2 to 4ms */
89 #define PCI_VIDTC 0x8d /* video speedup timer counter register: typical 50 to 100ms */
273 /* typical 2 to 4ms */ in gx_set_cpuspeed()
275 /* typical 50 to 100ms */ in gx_set_cpuspeed()
/linux/net/ieee802154/
H A DKconfig8 devices. Maximum allowed data rate is 250 kb/s and typical personal
/linux/Documentation/devicetree/bindings/iio/light/
H A Drohm,bu27034anuc.yaml14 capable of detecting a very wide range of illuminance. Typical application
/linux/Documentation/driver-api/
H A Dntb.rst35 NTB Typical client driver implementation
55 So typical scenario of the first type memory window initialization looks:
73 Typical scenario of the second type interface initialization would be:
/linux/arch/sh/mm/
H A Dsram.c17 * added either by the CPU or the platform code. Typical SRAM sizes
/linux/Documentation/admin-guide/mm/
H A Dmultigen_lru.rst133 A typical use case is that a job scheduler runs this command at a
158 A typical use case is that a job scheduler runs this command before it
/linux/drivers/cxl/
H A DKconfig82 In addition to typical memory resources a platform may also advertise
97 memory were attached to the typical CPU memory controller. This is
/linux/Documentation/devicetree/bindings/power/reset/
H A Drestart-handler.yaml23 128:: Typical, default restart handler; use if no other restart handler
/linux/Documentation/litmus-tests/rcu/
H A DRCU+sync+free.litmus10 * This is a typical pattern of RCU usage, where the write before the grace

12345678910>>...19