Searched full:time (Results 1 – 25 of 1602) sorted by relevance
12345678910>>...65
| /Documentation/devicetree/bindings/rtc/ |
| D | trivial-rtc.yaml | 23 # AB-RTCMC-32.768kHz-B5ZE-S3: Real Time Clock/Calendar Module with I2C Interface
25 # AB-RTCMC-32.768kHz-EOZ9: Real Time Clock/Calendar Module with I2C Interface
27 # ASPEED BMC ast2400 Real-time Clock
29 # ASPEED BMC ast2500 Real-time Clock
31 # ASPEED BMC ast2600 Real-time Clock
33 # Conexant Digicolor Real Time Clock Controller
37 # Dallas DS1672 Real-time Clock
41 # SD2405AL Real-Time Clock
45 # I2C-BUS INTERFACE REAL TIME CLOCK MODULE
47 # I2C-BUS INTERFACE REAL TIME CLOCK MODULE
[all …]
|
| /Documentation/sound/designs/ |
| D | timestamping.rst | 7 - Trigger_tstamp is the system time snapshot taken when the .trigger
19 The difference (tstamp - trigger_tstamp) defines the elapsed time.
26 The use of these different pointers and time information depends on
30 - ``delay`` reports the time it will take to hear a new sample after all
34 along with a snapshot of system time. Applications can select from
42 of time as measured by different components of audio hardware. In
47 --------------------------------------------------------------> time
51 time time time time time
58 The analog time is taken at the last stage of the playback, as close
61 The link time is taken at the output of the SoC/chipset as the samples
[all …]
|
| /Documentation/scheduler/ |
| D | sched-rt-group.rst | 2 Real-Time group scheduling
28 resolution, or the time it takes to handle the budget refresh itself.
33 are real-time processes).
42 Real-time scheduling is all about determinism, a group has to be able to rely on
43 the amount of bandwidth (eg. CPU time) being constant. In order to schedule
44 multiple groups of real-time tasks, each group must be assigned a fixed portion
45 of the CPU time available. Without a minimum guarantee a real-time group can
52 CPU time is divided by means of specifying how much time can be spent running
53 in a given period. We allocate this "run time" for each real-time group which
54 the other real-time groups will not be permitted to use.
[all …]
|
| D | sched-deadline.rst | 12 3. Scheduling Real-Time Tasks
54 "runtime" microseconds of execution time every "period" microseconds, and
57 every time the task wakes up, the scheduler computes a "scheduling deadline"
61 task actually receives "runtime" time units within "deadline" if a proper
70 with the "traditional" real-time task model (see Section 3) can effectively
87 scheduling deadline - current time period
89 then, if the scheduling deadline is smaller than the current time, or
93 scheduling deadline = current time + deadline
99 - When a SCHED_DEADLINE task executes for an amount of time t, its
108 said to be "throttled" (also known as "depleted" in real-time literature)
[all …]
|
| D | sched-eevdf.rst | 13 Similarly to CFS, EEVDF aims to distribute CPU time equally among all
15 time to each task, creating a "lag" value that can be used to determine
16 whether a task has received its fair share of CPU time. In this way, a task
17 with a positive lag is owed CPU time, while a negative lag means the task
21 allows latency-sensitive tasks with shorter time slices to be prioritized,
25 tasks; but at the time of writing EEVDF uses a "decaying" mechanism based
26 on virtual run time (VRT). This prevents tasks from exploiting the system
31 can request specific time slices using the new sched_setattr() system call,
|
| /Documentation/devicetree/bindings/ptp/ |
| D | timestamper.txt | 1 Time stamps from MII bus snooping devices
4 provide time stamps. In contrast to PHY time stamping drivers (which
6 alone MII time stamping drivers use this binding to specify the
9 Non-PHY MII time stamping drivers typically talk to the control
12 time stamping channels, each of which snoops on a MII bus.
14 The "timestamper" property lives in a phy node and links a time
40 In this example, time stamps from the MII bus attached to phy@1 will
41 appear on time stamp channel 0 (zero), and those from phy@2 appear on
|
| /Documentation/devicetree/bindings/memory-controllers/ |
| D | ti,gpmc-child.yaml | 30 description: Assertion time
34 description: Read deassertion time
38 description: Write deassertion time
43 description: Assertion time
47 description: Read deassertion time
51 description: Write deassertion time
55 description: Assertion time for AAD
59 description: Read deassertion time for AAD
63 description: Write deassertion time for AAD
68 description: Assertion time
[all …]
|
| D | ingenic,nemc-peripherals.yaml | 24 description: Address setup time in nanoseconds.
28 description: Address hold time in nanoseconds.
32 description: Burst pitch time in nanoseconds.
36 description: Address wait time in nanoseconds.
40 description: Static memory recovery time in nanoseconds.
|
| /Documentation/admin-guide/device-mapper/ |
| D | dm-service-time.rst | 2 dm-service-time
5 dm-service-time is a path selector module for device-mapper targets,
6 which selects a path with the shortest estimated service time for
9 The service time for each path is estimated by dividing the total size
14 The path selector name is 'service-time'.
49 dm-service-time adds the I/O size to 'in-flight-size' when the I/O is
51 Basically, dm-service-time selects a path having minimum service time
69 If such optimizations can't be applied, calculate service time, and
70 compare service time.
71 If calculated service time is equal, the path having maximum
[all …]
|
| /Documentation/fb/ |
| D | viafb.modes | 21 # Active Time 25.422 us 15.253 ms
23 # Blank Time 6.356 us 1.430 ms
46 # Active Time 20.317 us 12.800 ms
48 # Blank Time 6.349 us 0.533 ms
67 # Active Time 17.778 us 11.093 ms
69 # Blank Time 5.333 us 0.670 ms
88 # Active Time 14.827 us 9.430 ms
90 # Blank Time 4.819 us 0.570 ms
109 # Active Time 12.212 us 7.767 ms
111 # Blank Time 3.969 us 0.566 ms
[all …]
|
| /Documentation/accounting/ |
| D | taskstats-struct.rst | 36 5) Time accounting for SMT machines
51 * Each time the struct is changed, the value should be incremented.
78 /* The time when a task begins, in [secs] since 1970. */
79 __u32 ac_btime; /* Begin time [sec since 1970] */
81 /* The elapsed time of a task, in [usec]. */
82 __u64 ac_etime; /* Elapsed time [usec] */
84 /* The user CPU time of a task, in [usec]. */
85 __u64 ac_utime; /* User CPU time [usec] */
87 /* The system CPU time of a task, in [usec]. */
88 __u64 ac_stime; /* System CPU time [usec] */
[all …]
|
| D | psi.rst | 19 such resource crunches and the time impact it has on complex workloads
45 The "some" line indicates the share of time in which at least some
48 The "full" line indicates the share of time in which all non-idle
51 extended time in this state is considered to be thrashing. This has
54 still doing productive work. As such, time spent in this subset of the
62 as well as medium and long term trends. The total absolute stall time
64 spikes which wouldn't necessarily make a dent in the time averages,
65 or to average trends over custom time frames.
73 A trigger describes the maximum cumulative stall time over a specific
74 time window, e.g. 100ms of total stall time within any 500ms window to
[all …]
|
| /Documentation/devicetree/bindings/i2c/ |
| D | hisilicon,ascend910-i2c.yaml | 35 i2c-sda-falling-time-ns:
38 i2c-scl-falling-time-ns:
41 i2c-sda-hold-time-ns:
44 i2c-scl-rising-time-ns:
65 i2c-sda-falling-time-ns = <56>;
66 i2c-scl-falling-time-ns = <56>;
67 i2c-sda-hold-time-ns = <56>;
68 i2c-scl-rising-time-ns = <56>;
|
| D | snps,designware-i2c.yaml | 46 ICPU_CFG:TWI_DELAY registers to setup the SDA hold time.
72 i2c-sda-hold-time-ns:
74 The property should contain the SDA hold time in nanoseconds. This option
78 i2c-scl-falling-time-ns:
80 The property should contain the SCL falling time in nanoseconds.
84 i2c-sda-falling-time-ns:
86 The property should contain the SDA falling time in nanoseconds.
121 i2c-sda-hold-time-ns = <300>;
122 i2c-sda-falling-time-ns = <300>;
123 i2c-scl-falling-time-ns = <300>;
|
| /Documentation/driver-api/ |
| D | ptp.rst | 18 - Set time
19 - Get time
24 - Time stamp external events
27 - Synchronization of the Linux system time via the PPS subsystem
36 driver of asynchronous events (alarms and external time stamps) via
55 ancillary clock features. User space can receive time stamped
69 reentrant. Since most hardware implementations treat the time value
88 **NOTE:** '.adjphase' is not a simple time adjustment functionality
89 that 'jumps' the PHC clock time based on the provided offset. It
97 - 2 Time stamp external triggers, programmable polarity (opt. interrupt)
[all …]
|
| /Documentation/virt/kvm/x86/ |
| D | msr.rst | 41 time information and check that they are both equal and even.
45 number of seconds for wallclock at time of boot.
48 number of nanoseconds for wallclock at time of boot.
50 In order to get the current wallclock time, the system_time from
81 The hypervisor may update this structure at any time it sees fit until
88 time information and check that they are both equal and even.
92 the tsc value at the current VCPU at the time
94 from current tsc to derive a notion of elapsed time since the
98 a host notion of monotonic time, including sleep
99 time at the time this structure was last updated. Unit is
[all …]
|
| /Documentation/core-api/ |
| D | timekeeping.rst | 4 Device drivers can read the current time using ktime_get() and the many
13 that return time for different clock references:
20 Useful for reliable timestamps and measuring short time intervals
21 accurately. Starts at system boot time but stops during suspend.
35 Returns the time in relative to the UNIX epoch starting in 1970
36 using the Coordinated Universal Time (UTC), same as gettimeofday()
47 Like ktime_get_real(), but uses the International Atomic Time (TAI)
62 For all of the above, there are variants that return the time in a
72 of nanoseconds in the respective time reference, which may be
81 Same above, but returns the time in a 'struct timespec64', split
[all …]
|
| /Documentation/admin-guide/pm/ |
| D | cpuidle.rst | 8 CPU Idle Time Management
27 CPU idle time management is an energy-efficiency feature concerned about using
33 CPU idle time management operates on CPUs as seen by the *CPU scheduler* (that
43 program) at a time, it is a CPU. In that case, if the hardware is asked to
47 least one program at a time. The cores need not be entirely independent of each
48 other (for example, they may share caches), but still most of the time they
51 time. The entire cores are CPUs in that case and if the hardware is asked to
62 program in the same time frame (that is, each core may be able to fetch
63 instructions from multiple locations in memory and execute them in the same time
69 time management perspective and if the processor is asked to enter an idle state
[all …]
|
| /Documentation/admin-guide/cgroup-v1/ |
| D | blkio-controller.rst | 138 blkio.time
139 Disk time allocated to cgroup per device in milliseconds. First
141 third field specifies the disk time allocated to group in
165 Total amount of time between request dispatch and request completion
168 this time represents the actual service time. When queue_depth > 1,
170 may cause the service time for a given IO to include the service time
172 io_service_time > actual time elapsed. This time is further divided by
179 Total amount of time the IOs for this cgroup spent waiting in the
180 scheduler queues for service. This can be greater than the total time
182 measure of total time the cgroup spent waiting but rather a measure of
[all …]
|
| /Documentation/leds/ |
| D | leds-qcom-lpg.rst | 35 The pattern is a series of brightness and hold-time pairs, with the hold-time
36 expressed in milliseconds. The hold time is a property of the pattern and must
52 0 5 10 15 time (100ms)
54 The LPG supports specifying a longer hold-time for the first and last element
67 0 5 10 15 20 25 time (100ms)
69 Similarly, the last entry can be stretched by using a higher hold-time on the
76 denotes the wait time before the pattern is run in reverse and as such the
77 specified hold-time of the middle item in the pattern is allowed to have a
78 different hold-time.
|
| /Documentation/admin-guide/ |
| D | rtc.rst | 2 Real Time Clock (RTC) Drivers for Linux
5 When Linux developers talk about a "Real Time Clock", they usually mean
6 something that tracks wall clock time and is battery backed so that it
8 the local time zone or daylight savings time -- unless they dual boot
9 with MS-Windows -- but will instead be set to Coordinated Universal Time
10 (UTC, formerly "Greenwich Mean Time").
12 The newest non-PC hardware tends to just count seconds, like the time(2)
13 system call reports, but RTCs also very commonly represent time using
14 the Gregorian calendar and 24 hour time, as reported by gmtime(3).
32 be able to schedule one any time in the upcoming century.
[all …]
|
| /Documentation/ABI/testing/ |
| D | procfs-diskstats | 16 7 time spent reading (ms)
20 11 time spent writing (ms)
22 13 time spent doing I/Os (ms)
23 14 weighted time spent doing I/Os (ms)
33 18 time spent discarding
40 20 time spent flushing
|
| D | sysfs-class-wakeup | 6 wakeup sources in the kernel at that moment in time.
46 This file contains the amount of time the wakeup source has
54 This file contains the total amount of time this wakeup source
61 This file contains the maximum amount of time this wakeup
68 This file contains the monotonic clock time when the wakeup
69 source was touched last time, in milliseconds.
75 The file contains the total amount of time this wakeup source
|
| /Documentation/devicetree/bindings/input/touchscreen/ |
| D | fsl,imx6ul-tsc.yaml | 43 measure-delay-time:
46 The value of measure delay time. Before X-axis or Y-axis measurement,
47 the screen need some time before even potential distribution ready.
52 pre-charge-time:
55 The touch screen need some time to precharge.
94 measure-delay-time = <0xfff>;
95 pre-charge-time = <0xffff>;
|
| /Documentation/admin-guide/media/ |
| D | cafe_ccic.rst | 19 sensor is known to work with this controller at this time.
30 Load time options
33 There are a few load-time options, most of which can be changed after
37 buffers until the time comes to transfer data. If this option is set,
38 then worst-case-sized buffers will be allocated at module load time.
43 option is only consulted for load-time allocation; when buffers are
44 allocated at run time, they will be sized appropriately for the current
|
12345678910>>...65