On 27.05.22 08:22, Hongzhan Chen via Xenomai wrote: > When there is refined tsc clock, notify Xenomai to apply it.
Xenomai is conceptually not known to I-pipe. This patch is about calling the well-defined kevent hook when the TSC frequency changes after a recalibration. ARM does something similar on frequency changes. > Linux may schedule a delayed work to refine tsc clock and update > tsc_khz which happen after Xenomai finsih init but tsc_scale and > tsc_shift still keep the value depending on origianl tsc clock > which is outdated. The difference between two clocks may cause > unexpected timing drift. > > For example: > [ 0.001731] tsc: Detected 2899.886 MHz TSC > [ 5.588387] tsc: Refined TSC clocksource calibration: 2903.999 MHz > cat /sys/module/xenomai/parameters/clockfreq > 2899886000 > After patching, we like to use 2903.999 MHz. > > Signed-off-by: Hongzhan Chen <[email protected]> > > diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c > index 835856efd71f..e2ca733d76ee 100644 > --- a/arch/x86/kernel/tsc.c > +++ b/arch/x86/kernel/tsc.c > @@ -1294,6 +1294,7 @@ static void tsc_refine_calibration_work(struct > work_struct *work) > u64 tsc_stop, ref_stop, delta; > unsigned long freq; > int cpu; > + unsigned int ipipe_freq; > > /* Don't bother refining TSC on unstable systems */ > if (tsc_unstable) > @@ -1345,6 +1346,10 @@ static void tsc_refine_calibration_work(struct > work_struct *work) > /* Inform the TSC deadline clockevent devices about the recalibration */ > lapic_update_tsc_freq(); > > + /* notify xenomai about updated clockfreq */ Drop the comment, it's misleading. > + ipipe_freq = tsc_khz * 1000; > + __ipipe_report_clockfreq_update(ipipe_freq); Why not simply __ipipe_report_clockfreq_update(tsc_khz * 1000); ? > + > /* Update the sched_clock() rate to match the clocksource one */ > for_each_possible_cpu(cpu) > set_cyc2ns_scale(tsc_khz, cpu, tsc_stop); The patch looks like valid candidate for 5.4, 4.19-cip and even 4.4-cip. Jan -- Siemens AG, Technology Competence Center Embedded Linux
