On 17.06.22 08:09, Jan Kiszka via Xenomai wrote:
> On 16.06.22 02:18, 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
>> 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]>
>> ---
>> arch/x86/kernel/tsc.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
>> index 835856efd71f..37faaf9a9e6c 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,9 @@ static void tsc_refine_calibration_work(struct
>> work_struct *work)
>> /* Inform the TSC deadline clockevent devices about the recalibration */
>> lapic_update_tsc_freq();
>>
>> + ipipe_freq = tsc_khz * 1000;
>
> You are still using a separate variable.
>
Seems I missed a reply on that in the list - spam filters or who knows...
__ipipe_report_clockfreq_update() is defined in an unhandy way to
enforce this, I see. Would have been better to define it like this:
#define __ipipe_report_clockfreq_update(freq) \
do { \
unsigned int __freq = (freq); \
__ipipe_notify_kevent(IPIPE_KEVT_CLOCKFREQ, &__freq); \
} while (0)
OTH, we are in maintenance mode, so let's ignore this.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
