Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp878442ybg; Fri, 18 Oct 2019 08:41:42 -0700 (PDT) X-Google-Smtp-Source: APXvYqyLhHuMaq2fKLGc03ljS799knLlZTvxuKVgi7dZBdMt20NSINHcl8aXmxMyS5oDdRbEXYqz X-Received: by 2002:a17:906:314c:: with SMTP id e12mr9199760eje.140.1571413302308; Fri, 18 Oct 2019 08:41:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571413302; cv=none; d=google.com; s=arc-20160816; b=YM+117DJoifE4Df/cD9gwzpLgLw+GEbNuFNScAP9zKB8CVPvoVt5d5b8aS5NsUbY/x CAVjkjc4eH7GsaRcSiPxXbBfHmVLxSKnmsNADUrvTFLlKvgd55RY1TqFLY25OnANzYVg hh+bwlFdjW/6JwyxQ+hDtL71SK0bMUK0A0tym67f+sdyV9Ir71c1NVk4s2XeTcSDEBS6 sZj9xz4mUPTjAsb68+W+SEVLRpXenxv/iZXx7r33GZT7MKE7mvov2dCt8XBlvcVo9Gc2 2fbcxZqfkU7sy0JLXtNYX75a0W33eam8740JQ6HpNkjyFw2CmM23VZqoqclfIjZIr4ZA d2NQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=c10RKATv91WUJd+A/GRjteE37dfdP8EFuwtjFzziEOs=; b=GSRAs5gH/ywmsEyzmjoIebuPj7HTNYFA+bhLIW9xjQ4At8Qz4SJzvDYcM26w0qG7fT 6Z4GSTL4temE6JEwX+co7ljARkTHlWg28DkJdbSemYTpBLjEfir8IwCH8jVhCFsj/iS1 Gk1HvIg7/S7lIqO4ZDklZ6kziO/+EzNQaICemrkDh4cyU95fDrfo2gcRBUuTfecLPDqQ 5mp1qBPIMvGRQzgSoiqeukQ2R0UqhGzkWr+gMhZmCiSNKvh0myzZyONsGMGIFXRASj0f vjNWKzPEkKIVfrSZJMTnKz99frnpiOuF7RiLDcSKijmXx6c118sYrYqCuD5bw6vgA0s3 OrhA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a33si4523219edf.121.2019.10.18.08.41.19; Fri, 18 Oct 2019 08:41:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2502096AbfJQLPZ (ORCPT + 99 others); Thu, 17 Oct 2019 07:15:25 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:52702 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2406044AbfJQLPZ (ORCPT ); Thu, 17 Oct 2019 07:15:25 -0400 Received: from [5.158.153.52] (helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iL3kR-0006th-Mr; Thu, 17 Oct 2019 13:15:15 +0200 Date: Thu, 17 Oct 2019 13:15:15 +0200 (CEST) From: Thomas Gleixner To: Felipe Balbi cc: Richard Cochran , netdev@vger.kernel.org, Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org, "Christopher S . Hall" Subject: Re: [RFC PATCH 1/5] x86: tsc: add tsc to art helpers In-Reply-To: <87y2y4vk4g.fsf@gmail.com> Message-ID: References: <20190716072038.8408-1-felipe.balbi@linux.intel.com> <20190716072038.8408-2-felipe.balbi@linux.intel.com> <87y2zvt1hk.fsf@gmail.com> <87y2y4vk4g.fsf@gmail.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Tue, 1 Oct 2019, Felipe Balbi wrote: > (sorry for the long delay, got caught up in other tasks) Delayed by vacation :) > Thomas Gleixner writes: > > On Thu, 15 Aug 2019, Felipe Balbi wrote: > >> Thomas Gleixner 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? > 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. > 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. Thanks, tglx