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@xxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
