| /kernel/linux/linux-5.10/drivers/iio/imu/inv_icm42600/ |
| D | inv_icm42600_timestamp.c | 13 /* internal chip period is 32kHz, 31250ns */
44 uint32_t period) in inv_icm42600_timestamp_init() argument
49 /* current multiplier and period values after reset */ in inv_icm42600_timestamp_init()
51 ts->period = default_period; in inv_icm42600_timestamp_init()
53 ts->new_mult = period / INV_ICM42600_TIMESTAMP_PERIOD; in inv_icm42600_timestamp_init()
55 /* use theoretical value for chip period */ in inv_icm42600_timestamp_init()
71 uint32_t period, bool fifo) in inv_icm42600_timestamp_update_odr() argument
77 ts->new_mult = period / INV_ICM42600_TIMESTAMP_PERIOD; in inv_icm42600_timestamp_update_odr()
82 static bool inv_validate_period(uint32_t period, uint32_t mult) in inv_validate_period() argument
87 /* check that period is acceptable */ in inv_validate_period()
[all …]
|
| /kernel/linux/linux-6.6/lib/ |
| D | flex_proportions.c | 3 * Floating proportions with flexible aging period
14 * Where x_{i,j} is j's number of events in i-th last time period and x_i is
15 * total number of events in i-th last time period.
26 * When a new period is declared, we could do:
33 * occurs. This can bit trivially implemented by remembering last period in
42 p->period = 0; in fprop_global_init()
57 * Declare @periods new periods. It is upto the caller to make sure period
79 p->period += periods; in fprop_new_period()
93 pl->period = 0; in fprop_local_init_single()
105 unsigned int period = p->period; in fprop_reflect_period_single() local
[all …]
|
| /kernel/linux/linux-5.10/lib/ |
| D | flex_proportions.c | 3 * Floating proportions with flexible aging period
14 * Where x_{i,j} is j's number of events in i-th last time period and x_i is
15 * total number of events in i-th last time period.
26 * When a new period is declared, we could do:
33 * occurs. This can bit trivially implemented by remembering last period in
42 p->period = 0; in fprop_global_init()
57 * Declare @periods new periods. It is upto the caller to make sure period
83 p->period += periods; in fprop_new_period()
97 pl->period = 0; in fprop_local_init_single()
109 unsigned int period = p->period; in fprop_reflect_period_single() local
[all …]
|
| /kernel/linux/linux-5.10/drivers/gpu/drm/tegra/ |
| D | mipi-phy.c | 17 unsigned long period) in mipi_dphy_timing_get_default() argument
20 timing->clkpost = 70 + 52 * period; in mipi_dphy_timing_get_default()
30 timing->hsprepare = 65 + 5 * period; in mipi_dphy_timing_get_default()
31 timing->hszero = 145 + 5 * period; in mipi_dphy_timing_get_default()
32 timing->hssettle = 85 + 6 * period; in mipi_dphy_timing_get_default()
39 * T_HS-TRAIL = max(n * 8 * period, 60 + n * 4 * period) in mipi_dphy_timing_get_default()
43 * not parameterize on anything other that period, so this code will in mipi_dphy_timing_get_default()
46 timing->hstrail = max(4 * 8 * period, 60 + 4 * 4 * period); in mipi_dphy_timing_get_default()
63 unsigned long period) in mipi_dphy_timing_validate() argument
68 if (timing->clkpost < (60 + 52 * period)) in mipi_dphy_timing_validate()
[all …]
|
| /kernel/linux/linux-6.6/drivers/gpu/drm/tegra/ |
| D | mipi-phy.c | 17 unsigned long period) in mipi_dphy_timing_get_default() argument
20 timing->clkpost = 70 + 52 * period; in mipi_dphy_timing_get_default()
30 timing->hsprepare = 65 + 5 * period; in mipi_dphy_timing_get_default()
31 timing->hszero = 145 + 5 * period; in mipi_dphy_timing_get_default()
32 timing->hssettle = 85 + 6 * period; in mipi_dphy_timing_get_default()
39 * T_HS-TRAIL = max(n * 8 * period, 60 + n * 4 * period) in mipi_dphy_timing_get_default()
43 * not parameterize on anything other that period, so this code will in mipi_dphy_timing_get_default()
46 timing->hstrail = max(4 * 8 * period, 60 + 4 * 4 * period); in mipi_dphy_timing_get_default()
63 unsigned long period) in mipi_dphy_timing_validate() argument
68 if (timing->clkpost < (60 + 52 * period)) in mipi_dphy_timing_validate()
[all …]
|
| /kernel/linux/linux-6.6/drivers/iio/common/inv_sensors/ |
| D | inv_sensors_timestamp.c | 46 /* save chip parameters and compute min and max clock period */ in inv_sensors_timestamp_init()
51 /* current multiplier and period values after reset */ in inv_sensors_timestamp_init()
53 ts->period = chip->init_period; in inv_sensors_timestamp_init()
55 /* use theoretical value for chip period */ in inv_sensors_timestamp_init()
61 uint32_t period, bool fifo) in inv_sensors_timestamp_update_odr() argument
67 ts->new_mult = period / ts->chip.clock_period; in inv_sensors_timestamp_update_odr()
73 static bool inv_validate_period(struct inv_sensors_timestamp *ts, uint32_t period, uint32_t mult) in inv_validate_period() argument
77 /* check that period is acceptable */ in inv_validate_period()
80 if (period > period_min && period < period_max) in inv_validate_period()
87 uint32_t mult, uint32_t period) in inv_update_chip_period() argument
[all …]
|
| /kernel/linux/linux-5.10/Documentation/RCU/Design/Memory-Ordering/ |
| D | Tree-RCU-Memory-Ordering.rst | 2 A Tour Through TREE_RCU's Grace-Period Memory Ordering
13 grace-period memory ordering guarantee is provided.
15 What Is Tree RCU's Grace Period Memory Ordering Guarantee?
20 Any code that happens after the end of a given RCU grace period is guaranteed
22 period that are within RCU read-side critical sections.
24 period is guaranteed to see the effects of all accesses following the end
25 of that grace period that are within RCU read-side critical sections.
34 two phases, one of which is executed before the grace period and
35 the other of which is executed after the grace period.
46 Tree RCU Grace Period Memory Ordering Building Blocks
[all …]
|
| /kernel/linux/linux-6.6/drivers/pwm/ |
| D | pwm-microchip-core.c | 17 * As setting the period/duty cycle takes 4 register writes, there is a window
18 * in which this races against the start of a new period.
23 * period. Therefore to get a 0% waveform, the output is set the max high/low
25 * If the duty cycle is 0%, and the requested period is less than the
26 * available period resolution, this will manifest as a ~100% waveform (with
28 * - The PWM period is set for the whole IP block not per channel. The driver
29 * will only change the period if no other PWM output is enabled.
60 struct mutex lock; /* protects the shared period */
72 bool enable, u64 period) in mchp_core_pwm_enable() argument
95 * applied to the waveform at the beginning of the next period. in mchp_core_pwm_enable()
[all …]
|
| D | pwm-visconti.c | 15 * running period is completed. This way the hardware switches atomically
17 * - Disabling the hardware completes the currently running period and keeps
50 u32 period, duty_cycle, pwmc0; in visconti_pwm_apply() local
58 * The biggest period the hardware can provide is in visconti_pwm_apply()
63 if (state->period > (0xffff << 3) * 1000) in visconti_pwm_apply()
64 period = (0xffff << 3) * 1000; in visconti_pwm_apply()
66 period = state->period; in visconti_pwm_apply()
68 if (state->duty_cycle > period) in visconti_pwm_apply()
69 duty_cycle = period; in visconti_pwm_apply()
78 period /= 1000; in visconti_pwm_apply()
[all …]
|
| D | pwm-ntxec.c | 16 * - The period and duty cycle can't be changed together in one atomic action.
45 * The time base used in the EC is 8MHz, or 125ns. Period and duty cycle are
58 int period, int duty) in ntxec_pwm_set_raw_period_and_duty_cycle() argument
63 * Changes to the period and duty cycle take effect as soon as the in ntxec_pwm_set_raw_period_and_duty_cycle()
65 * to an inconsistent state after the period is written and before the in ntxec_pwm_set_raw_period_and_duty_cycle()
67 * is longer than the new period, the EC may output 100% for a moment. in ntxec_pwm_set_raw_period_and_duty_cycle()
69 * To minimize the time between the changes to period and duty cycle in ntxec_pwm_set_raw_period_and_duty_cycle()
74 { NTXEC_REG_PERIOD_HIGH, ntxec_reg8(period >> 8) }, in ntxec_pwm_set_raw_period_and_duty_cycle()
76 { NTXEC_REG_PERIOD_LOW, ntxec_reg8(period) }, in ntxec_pwm_set_raw_period_and_duty_cycle()
87 unsigned int period, duty; in ntxec_pwm_apply() local
[all …]
|
| /kernel/linux/linux-6.6/Documentation/RCU/Design/Expedited-Grace-Periods/ |
| D | Expedited-Grace-Periods.rst | 17 Expedited Grace Period Design
23 grace period.
32 state, the expedited grace period has completed.
43 expedited grace period is shown in the following diagram:
54 Otherwise, the expedited grace period will use
72 block the current expedited grace period until it resumes and finds its
75 the CPU is no longer blocking the grace period.
86 | Why not just have the expedited grace period check the state of all |
116 the handling of a given CPU by an RCU-sched expedited grace period is
137 Expedited Grace Period and CPU Hotplug
[all …]
|
| /kernel/linux/linux-5.10/Documentation/RCU/Design/Expedited-Grace-Periods/ |
| D | Expedited-Grace-Periods.rst | 17 Expedited Grace Period Design
23 grace period.
32 state, the expedited grace period has completed.
43 expedited grace period is shown in the following diagram:
54 Otherwise, the expedited grace period will use
72 block the current expedited grace period until it resumes and finds its
75 the CPU is no longer blocking the grace period.
86 | Why not just have the expedited grace period check the state of all |
116 the handling of a given CPU by an RCU-sched expedited grace period is
137 Expedited Grace Period and CPU Hotplug
[all …]
|
| /kernel/linux/linux-6.6/Documentation/RCU/Design/Memory-Ordering/ |
| D | Tree-RCU-Memory-Ordering.rst | 2 A Tour Through TREE_RCU's Grace-Period Memory Ordering
13 grace-period memory ordering guarantee is provided.
15 What Is Tree RCU's Grace Period Memory Ordering Guarantee?
20 Any code that happens after the end of a given RCU grace period is guaranteed
22 period that are within RCU read-side critical sections.
24 period is guaranteed to not see the effects of all accesses following the end
25 of that grace period that are within RCU read-side critical sections.
34 two phases, one of which is executed before the grace period and
35 the other of which is executed after the grace period.
46 Tree RCU Grace Period Memory Ordering Building Blocks
[all …]
|
| /kernel/linux/linux-5.10/Documentation/scheduler/ |
| D | sched-bwc.rst | 11 The bandwidth allowed for a group is specified using a quota and period. Within
12 each given "period" (microseconds), a task group is allocated up to "quota"
17 period when the quota is replenished.
20 cfs_quota units at each period boundary. As threads consume this bandwidth it
26 Quota and period are managed within the cpu subsystem via cgroupfs.
28 cpu.cfs_quota_us: the total available run-time within a period (in microseconds)
29 cpu.cfs_period_us: the length of a period (in microseconds)
43 The minimum quota allowed for the quota or period is 1ms. There is also an
44 upper bound on the period length of 1s. Additional restrictions exist when
95 a. it fully consumes its own quota within a period
[all …]
|
| D | sched-rt-group.rst | 27 system when the period is smaller than either the available hrtimer
53 in a given period. We allocate this "run time" for each realtime group which
61 frames a second, which yields a period of 0.04s per frame. Now say it will also
66 This way the graphics group will have a 0.04s period with a 0.032s run time
69 0.00015s. So this group can be scheduled with a period of 0.005s and a run time
90 The scheduling period that is equivalent to 100% CPU bandwidth
102 * A run time of -1 specifies runtime == period, ie. no limit.
115 period from /proc/sys/kernel/sched_rt_period_us and a run time of 0. If you
151 There is work in progress to make the scheduling period for each group
154 The constraint on the period is that a subgroup must have a smaller or
[all …]
|
| /kernel/linux/linux-6.6/include/linux/iio/common/ |
| D | inv_sensors_timestamp.h | 11 * @clock_period: internal clock period in ns
13 * @init_period: chip initial period at reset in ns
46 * @min_period: minimal acceptable clock period
47 * @max_period: maximal acceptable clock period
50 * @mult: current internal period multiplier
51 * @new_mult: new set internal period multiplier (not yet effective)
52 * @period: measured current period of the sensor
53 * @chip_period: accumulator for computing internal chip period
63 uint32_t period; member
71 uint32_t period, bool fifo);
[all …]
|
| /kernel/linux/linux-6.6/include/linux/ |
| D | flex_proportions.h | 3 * Floating proportions with flexible aging period
19 * bound on the number of events per period like
29 /* Number of events in the current period */
31 /* Current period */
32 unsigned int period; member
33 /* Synchronization with period transitions */
47 /* Period in which we last updated events */
48 unsigned int period; member
49 raw_spinlock_t lock; /* Protect period and numerator */
79 /* Period in which we last updated events */
[all …]
|
| D | pwm.h | 15 * period
18 * period
27 * @period: reference period
39 u64 period; member
50 * @period: PWM period (in nanoseconds)
60 u64 period; member
117 static inline void pwm_set_period(struct pwm_device *pwm, u64 period) in pwm_set_period() argument
120 pwm->state.period = period; in pwm_set_period()
129 return state.period; in pwm_get_period()
169 * that first retrieves the current PWM state and the replaces the period
[all …]
|
| /kernel/linux/linux-5.10/include/linux/ |
| D | flex_proportions.h | 3 * Floating proportions with flexible aging period
19 * bound on the number of events per period like
29 /* Number of events in the current period */
31 /* Current period */
32 unsigned int period; member
33 /* Synchronization with period transitions */
47 /* Period in which we last updated events */
48 unsigned int period; member
49 raw_spinlock_t lock; /* Protect period and numerator */
79 /* Period in which we last updated events */
[all …]
|
| D | pwm.h | 18 * period
21 * period
30 * @period: reference period
42 u64 period; member
53 * @period: PWM period (in nanoseconds)
59 u64 period; member
110 static inline void pwm_set_period(struct pwm_device *pwm, u64 period) in pwm_set_period() argument
113 pwm->state.period = period; in pwm_set_period()
122 return state.period; in pwm_get_period()
162 * that first retrieves the current PWM state and the replaces the period
[all …]
|
| /kernel/linux/linux-6.6/Documentation/RCU/ |
| D | stallwarn.rst | 40 - Anything that prevents RCU's grace-period kthreads from running.
51 in which case the next RCU grace period can never complete, which
120 Please note that RCU only detects CPU stalls when there is a grace period
121 in progress. No grace period, no CPU stall warnings.
149 This kernel configuration parameter defines the period of time
150 that RCU will wait from the beginning of a grace period until it
151 issues an RCU CPU stall warning. This time period is normally
170 the expedited grace period. This parameter defines the period
172 grace period until it issues an RCU CPU stall warning. This time
173 period is normally 20 milliseconds on Android devices. A zero
[all …]
|
| /kernel/linux/linux-5.10/Documentation/RCU/ |
| D | stallwarn.rst | 40 - Anything that prevents RCU's grace-period kthreads from running.
51 in which case the next RCU grace period can never complete, which
107 RCU only detects CPU stalls when there is a grace period in progress.
108 No grace period, no CPU stall warnings.
136 This kernel configuration parameter defines the period of time
137 that RCU will wait from the beginning of a grace period until it
138 issues an RCU CPU stall warning. This time period is normally
184 task stalling the current RCU-tasks grace period.
209 interrupts during the current stalled grace period.
222 last noted the beginning of a grace period, which might be the current
[all …]
|
| /kernel/linux/linux-6.6/Documentation/scheduler/ |
| D | sched-bwc.rst | 12 The bandwidth allowed for a group is specified using a quota and period. Within
13 each given "period" (microseconds), a task group is allocated up to "quota"
18 period when the quota is replenished.
21 cfs_quota units at each period boundary. As threads consume this bandwidth it
70 Quota, period and burst are managed within the cpu subsystem via cgroupfs.
77 - cpu.cfs_quota_us: run-time replenished within a period (in microseconds)
78 - cpu.cfs_period_us: the length of a period (in microseconds)
95 period is 1ms. There is also an upper bound on the period length of 1s.
155 a. it fully consumes its own quota within a period
156 b. a parent's quota is fully consumed within its period
[all …]
|
| D | sched-rt-group.rst | 27 system when the period is smaller than either the available hrtimer
53 in a given period. We allocate this "run time" for each realtime group which
61 frames a second, which yields a period of 0.04s per frame. Now say it will also
66 This way the graphics group will have a 0.04s period with a 0.032s run time
69 0.00015s. So this group can be scheduled with a period of 0.005s and a run time
90 The scheduling period that is equivalent to 100% CPU bandwidth
102 * A run time of -1 specifies runtime == period, ie. no limit.
115 period from /proc/sys/kernel/sched_rt_period_us and a run time of 0. If you
151 There is work in progress to make the scheduling period for each group
154 The constraint on the period is that a subgroup must have a smaller or
[all …]
|
| /kernel/linux/linux-6.6/drivers/watchdog/ |
| D | booke_wdt.c | 22 * Also, the wdt_period sets the watchdog timer period timeout.
50 /* For the specified period, determine the number of seconds
55 * 2.5 * (2^(63-period+1)) / timebase_freq
57 * In order to simplify things, we assume that period is
60 static unsigned long long period_to_sec(unsigned int period) in period_to_sec() argument
62 unsigned long long tmp = 1ULL << (64 - period); in period_to_sec()
75 * This procedure will find the highest period which will give a timeout
81 unsigned int period; in sec_to_period() local
82 for (period = 63; period > 0; period--) { in sec_to_period()
83 if (period_to_sec(period) >= secs) in sec_to_period()
[all …]
|