LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Richard Cochran <richardcochran@gmail.com>,
	netdev@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>, "H . Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	"Christopher S . Hall" <christopher.s.hall@intel.com>
Subject: Re: [RFC PATCH 1/5] x86: tsc: add tsc to art helpers
Date: Thu, 17 Oct 2019 15:01:44 +0300	[thread overview]
Message-ID: <871rvblgwn.fsf@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1910171256580.1824@nanos.tec.linutronix.de>

[-- Attachment #1: Type: text/plain, Size: 3238 bytes --]


Hi,

Thomas Gleixner <tglx@linutronix.de> writes:
>> Thomas Gleixner <tglx@linutronix.de> writes:
>> > On Thu, 15 Aug 2019, Felipe Balbi wrote:
>> >> Thomas Gleixner <tglx@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2019-10-17 12:01 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-16  7:20 [RFC PATCH 0/5] PTP: add support for Intel's TGPIO controller Felipe Balbi
2019-07-16  7:20 ` [RFC PATCH 1/5] x86: tsc: add tsc to art helpers Felipe Balbi
2019-07-16  7:57   ` Thomas Gleixner
2019-08-15  5:57     ` Felipe Balbi
2019-08-15 14:16       ` Thomas Gleixner
2019-10-01 10:24         ` Felipe Balbi
2019-10-17 11:15           ` Thomas Gleixner
2019-10-17 12:01             ` Felipe Balbi [this message]
2019-07-16  7:20 ` [RFC PATCH 2/5] PTP: add a callback for counting timestamp events Felipe Balbi
2019-07-16  7:20 ` [RFC PATCH 3/5] PTP: implement PTP_EVENT_COUNT_TSTAMP ioctl Felipe Balbi
2019-07-16  7:20 ` [RFC PATCH 4/5] PTP: Add flag for non-periodic output Felipe Balbi
2019-07-16 16:39   ` Richard Cochran
2019-07-17  6:49     ` Felipe Balbi
2019-07-17 17:36       ` Richard Cochran
2019-07-18  8:59         ` Felipe Balbi
2019-07-18 16:41           ` Richard Cochran
2019-08-13  7:53             ` Felipe Balbi
2019-08-13 17:48               ` Richard Cochran
2019-08-13 18:06                 ` Richard Cochran
2019-08-14  7:05                   ` Felipe Balbi
2019-07-16  7:20 ` [RFC PATCH 5/5] PTP: Add support for Intel PMC Timed GPIO Controller Felipe Balbi
2019-07-16 19:14   ` Shannon Nelson
2019-07-17  6:51     ` Felipe Balbi
2019-07-16 16:41 ` [RFC PATCH 0/5] PTP: add support for Intel's TGPIO controller Richard Cochran
2019-07-17  6:52   ` Felipe Balbi
2019-07-17 17:39     ` Richard Cochran
2019-07-18  8:58       ` Felipe Balbi
2019-07-18 19:50 ` Andrew Lunn
2019-07-19  7:35   ` Felipe Balbi
2019-07-19 13:20     ` Andrew Lunn
2019-08-13  7:50       ` Felipe Balbi
2019-08-13 17:49         ` Richard Cochran

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871rvblgwn.fsf@gmail.com \
    --to=felipe.balbi@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=christopher.s.hall@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --subject='Re: [RFC PATCH 1/5] x86: tsc: add tsc to art helpers' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).