>-----Original Message----- >From: Jan Kiszka <[email protected]> >Sent: Thursday, June 2, 2022 5:54 PM >To: Chen, Hongzhan <[email protected]>; [email protected] >Subject: Re: [Cobalt Xenoami3.1 PATCH 0/2] notify Xenomai udpated clockfreq. > >On 27.05.22 08:22, Hongzhan Chen via Xenomai wrote: >> When there is refined tsc clock, notify Xenomai to apply it. >> 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 >> timing issue. >> >> 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. >> >> The patchset includes IPIPE patch and cobalt-patch. >> > >Sounds reasonable, but you could help me with reviewing this by already >answering: > > - How does dovetail (and xenomai 3.2 or evl) address this?
So far , I have not found similar issue on dovetail-based. Dovetail-based would go vdso uniformly so there is no such issue but IPIPE would have to depend on tsc_khz value it got at first to do translation even after tsc clockfreq is refined and changed. > - Why is this tagged "3.1" only? > - Which I-pipe series is this targeting (5.4, or also 4.19)? Currently , I just reproduced this issue and verified the patch on 5.4.133 + xenomai 3.1. But according to [1] reported, the issue can be found on 4.19 and I think my patch may work but I have not verified on 4.19. Regards Hongzhan Chen [1]: https://xenomai.org/pipermail/xenomai/2022-May/047770.html
