Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp3299964ybn; Fri, 27 Sep 2019 04:22:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqzSVNUueldNgDUyaCMQeszODEvZBneIfX65s+KGcMfZqiOC0FhhmApeuy9O/B0RNrfd94XX X-Received: by 2002:aa7:dd8e:: with SMTP id g14mr3786751edv.233.1569583376036; Fri, 27 Sep 2019 04:22:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569583376; cv=none; d=google.com; s=arc-20160816; b=rKzulXOVEAscVIlmHkjZTssWVEkXtAsNhk03fzbkpTTklmK+rMrK4k1iwYC9B/e720 jWHczeG2Z4/ssZABfDBuQV4Qfar7GLlFgPyko0Dbe6va20Rw7+pKnzudaanFiMmXNQqk NzG0tTkTQNaEkcXjwGurORb+dKvPy6igMd6piJBgQUGtHZ7sFyZupW20DBXveXyHbKD+ g9DP9/F3MnybfCIQBdmJeiCHHsZtFYhDHFOARgh7Im8ARsIm4nUFeYxwvREQ9yiokt3k gbba2oaAeouTRM7Lof7yIEafmSfEY0J/GDixtceA/IEy1Air7LYojx0kguz54KKQp3U+ D0pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:cc:from:date:content-transfer-encoding:mime-version :subject:to; bh=CfjuQOw5uXDiVZWmFBRXXrbhUg29QfwMmDVJNfz0VxU=; b=cFv8CuRSDoCQbEU/2ueIQDIu6va4GXKQxWoRbFZygX70ROwA6saD/mxStOXWt0BLHo KBo+1plcXysm1zg28uTLUF/zY5P7x+WI+7XmE8N1WGOYZG3IAZYF1f1pp5w3L+ozyshO AezL8DKmGPeVb9XfGJeuopPA/tsDXjWvvJ9Rw+5hyZpLlWNxLRQPNVKfzgCCCj1Gq7ou EwKfBgaxMt0hEU7GVvksyvR2/biJcV8y7NXecD9ERcG/PysZtg9dCGnR3yF+cGaOvQ9i J3x+B9GZKZv6zMH3iGtuZoWXpsQBiVAPydyuINXbSWfBtTrciKT/cJtsjx2IVP1A0Cv+ ZF+A== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w1si1309384eda.214.2019.09.27.04.22.30; Fri, 27 Sep 2019 04:22:56 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727076AbfI0LWW (ORCPT + 99 others); Fri, 27 Sep 2019 07:22:22 -0400 Received: from inca-roads.misterjones.org ([213.251.177.50]:50764 "EHLO inca-roads.misterjones.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725992AbfI0LWW (ORCPT ); Fri, 27 Sep 2019 07:22:22 -0400 Received: from www-data by cheepnis.misterjones.org with local (Exim 4.80) (envelope-from ) id 1iDoKF-00076R-Dm; Fri, 27 Sep 2019 13:22:15 +0200 To: Benjamin Gaignard Subject: Re: [PATCH] ARM: dts: stm32: Enable high resolution timer X-PHP-Originating-Script: 0:main.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 27 Sep 2019 12:22:13 +0100 From: Marc Zyngier Cc: , , , , , , In-Reply-To: <20190927084819.645-1-benjamin.gaignard@st.com> References: <20190927084819.645-1-benjamin.gaignard@st.com> Message-ID: X-Sender: maz@kernel.org User-Agent: Roundcube Webmail/0.7.2 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: benjamin.gaignard@st.com, alexandre.torgue@st.com, robh+dt@kernel.org, mark.rutland@arm.com, devicetree@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on cheepnis.misterjones.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-09-27 09:48, Benjamin Gaignard wrote: > Adding always-on makes arm arch_timer claim to be an high resolution > timer. > That is possible because power mode won't stop clocking the timer. The "always-on" is not about the clock. It is about the comparator. The clock itself is *guaranteed* to always tick. If it didn't, that'd be an integration bug, and a pretty bad one. What you're claiming here is that your CPU never enters a low-power mode? Ever? I find this very hard to believe. Furthermore, claiming that always-on is the way to force the arch-timer to be an hrtimer is factually wrong. This is what happens *if* this is the only timer in the system. The only case this is true is for virtual machines. Anything else has a global timer somewhere that will allow the arch timers to be used as an hrtimer. I'm pretty sure you too have a global timer somewhere in your system. Enable it, and enjoy hrtimers without having to lie about the properties of your system! ;-) M. > > Signed-off-by: Benjamin Gaignard > --- > arch/arm/boot/dts/stm32mp157c.dtsi | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi > b/arch/arm/boot/dts/stm32mp157c.dtsi > index 9b11654a0a39..74f64745d60d 100644 > --- a/arch/arm/boot/dts/stm32mp157c.dtsi > +++ b/arch/arm/boot/dts/stm32mp157c.dtsi > @@ -50,6 +50,7 @@ > , > ; > interrupt-parent = <&intc>; > + always-on; > }; > > clocks { -- Jazz is not dead. It just smells funny...