From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14649C3F68F for ; Wed, 29 Jan 2020 23:39:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E3E2B207FD for ; Wed, 29 Jan 2020 23:39:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726833AbgA2XjU (ORCPT ); Wed, 29 Jan 2020 18:39:20 -0500 Received: from foss.arm.com ([217.140.110.172]:46970 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726528AbgA2XjU (ORCPT ); Wed, 29 Jan 2020 18:39:20 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 39A9331B; Wed, 29 Jan 2020 15:39:19 -0800 (PST) Received: from [10.0.2.15] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 570803F52E; Wed, 29 Jan 2020 15:39:17 -0800 (PST) Subject: Re: [PATCH v2 6/6] arm64: use activity monitors for frequency invariance From: Valentin Schneider To: Ionela Voinescu , catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, maz@kernel.org, suzuki.poulose@arm.com, sudeep.holla@arm.com, dietmar.eggemann@arm.com Cc: peterz@infradead.org, mingo@redhat.com, ggherdovich@suse.cz, vincent.guittot@linaro.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org References: <20191218182607.21607-1-ionela.voinescu@arm.com> <20191218182607.21607-7-ionela.voinescu@arm.com> <96fdead6-9896-5695-6744-413300d424f5@arm.com> Message-ID: <3ed9af08-82ef-e30c-b1ec-3a1dac0d2091@arm.com> Date: Wed, 29 Jan 2020 23:39:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <96fdead6-9896-5695-6744-413300d424f5@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29/01/2020 17:13, Valentin Schneider wrote: > I had a brief look at the Arm ARM, for the arch timer it says it is > "typically in the range 1-50MHz", but then also gives an example with 20KHz > in a low-power mode. > > If we take say 5GHz max CPU frequency, our lower bound for the arch timer > (with that SCHED_CAPACITY_SCALE² trick) is about ~4.768KHz. It's not *too* > far from that 20KHz, but I'm not sure we would actually be executing stuff > in that low-power mode. > I mixed up a few things in there; that low-power mode is supposed to do higher increments, so it would emulate a similar frequency as the non-low-power mode. Thus the actual frequency matters less than what is reported in CNTFRQ (though we hope to get the behaviour we're told we should see), so we should be quite safe from that ~5KHz value. Still, to make it obvious, I don't think something like this would hurt: --- diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index 9a5464c625b45..a72832093575a 100644 --- a/drivers/clocksource/arm_arch_timer.c +++ b/drivers/clocksource/arm_arch_timer.c @@ -885,6 +885,17 @@ static int arch_timer_starting_cpu(unsigned int cpu) return 0; } +static int validate_timer_rate(void) +{ + if (!arch_timer_rate) + return 1; + + /* Arch timer frequency < 1MHz is shady */ + WARN_ON(arch_timer_rate < 1000000); + + return 0; +} + /* * For historical reasons, when probing with DT we use whichever (non-zero) * rate was probed first, and don't verify that others match. If the first node @@ -900,7 +911,7 @@ static void arch_timer_of_configure_rate(u32 rate, struct device_node *np) arch_timer_rate = rate; /* Check the timer frequency. */ - if (arch_timer_rate == 0) + if (validate_timer_rate()) pr_warn("frequency not available\n"); } @@ -1594,7 +1605,7 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *table) * CNTFRQ value. This *must* be correct. */ arch_timer_rate = arch_timer_get_cntfrq(); - if (!arch_timer_rate) { + if (validate_timer_rate()) { pr_err(FW_BUG "frequency not available.\n"); return -EINVAL; } --- > Long story short, we're probably fine, but it would nice to shove some of > the above into comments (especially the SCHED_CAPACITY_SCALE² trick) >