| Message ID | 20200820081118.10105-1-kurt@linutronix.de |
|---|---|
| Headers | show |
| Series | Hirschmann Hellcreek DSA driver | expand |
On Tue Aug 25 2020, Vladimir Oltean wrote: > On Tue, Aug 25, 2020 at 11:23:56AM +0200, Kurt Kanzenbach wrote: >> On Mon Aug 24 2020, Vinicius Costa Gomes wrote: >> > Hi, >> > >> > Kurt Kanzenbach <kurt@linutronix.de> writes: >> > >> [snip] >> >> + /* Setup timer for schedule switch: The IP core only allows to set a >> >> + * cycle start timer 8 seconds in the future. This is why we setup the >> >> + * hritmer to base_time - 5 seconds. Then, we have enough time to >> >> + * activate IP core's EST timer. >> >> + */ >> >> + start = ktime_sub_ns(schedule->base_time, (u64)5 * NSEC_PER_SEC); >> >> + hrtimer_start_range_ns(&hellcreek_port->cycle_start_timer, start, >> >> + NSEC_PER_SEC, HRTIMER_MODE_ABS); >> > >> > If we are talking about seconds here, I don't think you need to use a >> > hrtimer, you could use a workqueue/delayed_work. Should make things a >> > bit simpler. >> >> I've used hrtimers for one reason: The hrtimer provides a way to fire at >> an absolute base time based on CLOCK_TAI. All the other facilities such >> as workqueues, timer list timers, etc do not. > > That still doesn't justify the complexity of irqsave spinlocks and such. > You could just as well schedule a workqueue from that hrtimer and have > process context... After giving this a bit more thought, it can be implemented by using workqueues only. That ptp time is "cached" anyway the we could just periodically check for the base time arrival. That should solve the irqsave and the being synchronized problem. Thanks, Kurt
On Tue, Sep 01, 2020 at 04:20:00PM +0200, Kurt Kanzenbach wrote: > > After giving this a bit more thought, it can be implemented by using > workqueues only. That ptp time is "cached" anyway the we could just > periodically check for the base time arrival. That should solve the > irqsave and the being synchronized problem. > > Thanks, > Kurt Ok, this sounds simple enough. If the base-time is within 8 seconds of the current PTP time, then apply the taprio configuration, otherwise reschedule a delayed workqueue after N seconds (where N has what value?). If my math is correct, then N can't simply be the the delta between the current PTP time and the (base-time minus 8 seconds) value - i.e. just one schedule_delayed_work - because at large deltas, the PHC frequency adjustment (+/- 6.25%) starts to matter. At maximum frequency, the PHC can exceed the monotonic clock of the system by more than 8 seconds in (8 * 100 / 6.25) = 128 seconds. So if the base-time is in the future by more than 128 seconds and you plan for a single schedule_delayed_work, there's a chance that you'll miss the window. And even if you try to compensate using the current frequency adjustment, that's all that it is - the current, instantaneous frequency adjustment, not the one from 128 seconds later. How about N being half that delta? It's not ideal, since there would need to be log2(delta) reschedules, but at least the error of the first approximation won't propagate to the next, and the delta will keep decreasing as time passes, therefore so will the error. Thanks, -Vladimir