>-----Original Message----- >From: Jan Kiszka <[email protected]> >Sent: Thursday, June 9, 2022 1:48 PM >To: Chen, Hongzhan <[email protected]>; [email protected] >Subject: Re: [Cobalt Xenoami3.1 PATCH 0/2] notify Xenomai udpated clockfreq. > >On 09.06.22 04:06, Chen, Hongzhan wrote: >>> -----Original Message----- >>> From: Jan Kiszka <[email protected]> >>> Sent: Wednesday, June 8, 2022 11:21 PM >>> To: Chen, Hongzhan <[email protected]>; [email protected] >>> Subject: Re: [Cobalt Xenoami3.1 PATCH 0/2] notify Xenomai udpated clockfreq. >>> >>> On 02.06.22 14:56, Chen, Hongzhan wrote: >>>> >>>> >>>>> -----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. >>> >>> Right, that is reason... >>> >>>> >>>>> - 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. >>>> >>> >>> Please check stable/v3.2.x first (or as well) as that is the latest >>> stable with I-pipe still included. Once the fix is merged there, we can >>> pick it for 3.1 and possibly even 3.0 as well. >> >> The code between 3.2 and 3.1 involving this patchset is quite different now. >> For 3.2, we already dropped code related to clockfreq parameter >> in 6d2989b6da73ec52fe8c990798be8a637e4db5b9 by Philippe. >> But in my patchset for 3.1, we have to update value of clockfreq parameter >> to show correct clock freq after we update to refined clock freq. >> To keep consistency between 3.1 and 3.2 for I-PIPE based code, do we need to >> revert this part of code related to clockfreq parameter for 3.2? > >Do you see the problem of 3.1+ipipe with 3.2 as well? I suspect so, but
Yes. On 3.2 + IPIPE, it still use the clock freq at first got to do init but never update accordingly even after there is refined tsc clock. In cobalt_ticks_init of lib/cobalt/ticks.c, it init tsc_scale and tsc_shift when there is non-zero freq passed but never change and pipeline_update_clock_freq never called to update them when there is refined tsc clock. Regards Hongzhan Chen >please confirm. Then we do need a solution there, too. How is the next >question, I need to dive into that again. > >Jan > >-- >Siemens AG, Technology >Competence Center Embedded Linux
