Searched refs:nanosecond (Results 1 – 11 of 11) sorted by relevance
| /linux-4.1.27/drivers/char/ |
| D | efirtc.c | 112 eft->nanosecond = 0; in convert_to_efi_time()
322 eft.hour, eft.minute, eft.second, eft.nanosecond, in efi_rtc_proc_show()
339 alm.hour, alm.minute, alm.second, alm.nanosecond, in efi_rtc_proc_show()
|
| /linux-4.1.27/Documentation/timers/ |
| D | timekeeping.txt | 54 into a nanosecond value as an unsigned long long (unsigned 64 bit) number.
57 possible to a nanosecond value using only the arithmetic operations
129 i.e. after 64 bits. Since this is a nanosecond value this will mean it wraps
146 counter to derive a 64-bit nanosecond value, so for example on the ARM
148 sched_clock() nanosecond base from a 16- or 32-bit counter. Sometimes the
|
| D | hrtimers.txt | 126 special nanosecond-resolution type: ktime_t. The kernel-internal
|
| D | highres.txt | 52 convert the clock ticks to nanosecond based time values. All other time keeping
|
| /linux-4.1.27/drivers/rtc/ |
| D | rtc-efi.c | 77 eft->nanosecond = 0; in convert_to_efi_time()
|
| /linux-4.1.27/drivers/staging/unisys/common-spar/include/channels/ |
| D | diagchannel.h | 117 u32 nanosecond; /* 0 - 999, 999, 999 */ member
|
| /linux-4.1.27/Documentation/scheduler/ |
| D | sched-design-CFS.txt | 88 CFS uses nanosecond granularity accounting and does not rely on any jiffies or
|
| /linux-4.1.27/Documentation/sound/alsa/ |
| D | timestamping.txt | 110 The accuracy is reported in nanosecond units (using an unsigned 32-bit
|
| /linux-4.1.27/include/linux/ |
| D | efi.h | 146 u32 nanosecond; member
|
| /linux-4.1.27/arch/ia64/kernel/ |
| D | efi.c | 250 ts->tv_nsec = tm.nanosecond; in STUB_GET_TIME()
|
| /linux-4.1.27/Documentation/virtual/kvm/ |
| D | timekeeping.txt | 567 back into nanosecond resolution values.
|