Hi, Thomas Gleixner <t...@linutronix.de> writes: >> Thomas Gleixner <t...@linutronix.de> writes: >> > On Thu, 15 Aug 2019, Felipe Balbi wrote: >> >> Thomas Gleixner <t...@linutronix.de> writes: >> >> > On Tue, 16 Jul 2019, Felipe Balbi wrote: >> >> > >> >> > So some information what those interfaces are used for and why they are >> >> > needed would be really helpful. >> >> >> >> Okay, I have some more details about this. The TGPIO device itself uses >> >> ART since TSC is not directly available to anything other than the >> >> CPU. The 'problem' here is that reading ART incurs extra latency which >> >> we would like to avoid. Therefore, we use TSC and scale it to >> >> nanoseconds which, would be the same as ART to ns. >> > >> > Fine. But that's not really correct: >> > >> > TSC = art_to_tsc_offset + ART * scale; >> >> From silicon folks I got the equation: >> >> ART = ECX * EBX / EAX; > > What is the content of ECX/EBX/EAX and where is it coming from?
Since last email, I got a bit of extra information about how all of
these should work.
ECX contains crystal rate of TSC, EBX and EAX contain constants for
converting between TSC and ART.
So, ART = tsc_cycles * EBX/EAX, this will give me ART cycles. Also, the
time gpio IP needs ART cycles to be written to its comparator
registers, but the PTP framework wants time in nanoseconds.
Therefore we need two new conversion functions:
convert_tsc_to_art_cycles() and something which gives us current TSC in
nanoseconds.
>> If I'm reading this correctly, that's basically what
>> native_calibrate_tsc() does (together with some error checking the safe
>> defaults). Couldn't we, instead, just have a single function like below?
>>
>> u64 convert_tsc_to_art_ns()
>> {
>> return x86_platform.calibrate_tsc();
>> }
>
> Huch? How is that supposed to work? calibrate_tsc() returns the TSC
> frequency.
Yup, that was a total brain fart.
>> Another way would be extract the important parts from
>> native_calibrate_tsc() into a separate helper. This would safe another
>> call to cpuid(0x15,...);
>
> What for?
>
> The relation between TSC and ART is already established via detect_art()
> which reads all relevant data out of CPUID(ART_CPUID_LEAF).
>
> We use exactly that information for convert_art_to_tsc() so the obvious
> solution for calculating ART from TSC is to do the reverse operation.
>
> convert_art_to_tsc()
> {
> rem = do_div(art, art_to_tsc_denominator);
>
> res = art * art_to_tsc_numerator;
> tmp = rem * art_to_tsc_numerator;
>
> do_div(tmp, art_to_tsc_denominator);
> res += tmp + art_to_tsc_offset;
> }
>
> which is translated into math:
>
> TSC = ART * SCALE + OFFSET
>
> where
>
> SCALE = N / D
>
> and
>
> N = CPUID(ART_CPUID_LEAF).EAX
> D = CPUID(ART_CPUID_LEAF).EBX
>
> So the obvious reverse operation is:
>
> ART = (TSC - OFFSET) / SCALE;
>
> Translating that into code should not be rocket science.
Right, that's where we got after talking to other folks.
Do you have any preferences for the function names? Or does
convert_tsc_to_art() sound ok?
--
balbi
signature.asc
Description: PGP signature
