Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp108048ybt; Mon, 6 Jul 2020 05:17:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyEHfpaYV4KR90fG2Xo5eXkdm9zRaM5RV99elHbUN1NIyqDMcZ4+F6qWbAlYV2x/AnHoHlX X-Received: by 2002:a50:f01d:: with SMTP id r29mr55852270edl.158.1594037851941; Mon, 06 Jul 2020 05:17:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594037851; cv=none; d=google.com; s=arc-20160816; b=M1dsBkJO9bUn5JyhZDU2iDVlYokCl23e0ccz8G2Cy3tf3KyFuCZ+Cpv7XVAQZ1Wwwl 30K7VW//g4onLu2M+43x/JLBfud4ZpEDBWXgoClhqocwdGTEnGO7fCShUh3DjFFg/46R JGS8VaS5l/ryxbDWq1+6eF9cv3qcyVde6LyAYcVjEHTJ7qyc82EXmh9J/0vXAKqI45O8 fhh5awDmbNrspN3lJgmy1owWO1OavQB0DvZmbXvNgV0llr5EyahpDSpczzE6oo3e0ani DSqSrIyqQIIZNcMzSc2u3oK36+TraoU2oH9onsnFGqSHgr1cJh4b3xlLpEuZk5U44Tu+ XEqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=aA3ym1AthHEhYaJ5EpHcxeiM6ufljOK4pu+Se4omXlQ=; b=J4SHzNTnvAJ0YCJGqi1N9FBDEB3IE+L01VW68P2/bVNMxWpZ99iRGlD1nE0BuIzGct PB6AJZo2j0tGfs/UWN5Cmf/GXYsRqvNieUYQxgf8tUsyQzRSUDeHOdPfKhCtzTJi20OL X2XueMOVt5TJFjeFZtVQq1DofkJqEQvu0JYk+GGqPevoUrUOgQzNAv0/SA20b0LD1oXh RFFWQ7n2r9gIrCbw0GOuSOhCFvajEXSXEE3SRNbgbOYi2bvFcABH/Nxk/1nNZbwN4HOv 0iaaMJpue0aZFlf9nMc50IdBXP6Sm7HG14aDLlE9QmmRfvRp4miGoWF3vToWXzd14E9h GlGQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q22si13439398ejx.87.2020.07.06.05.17.08; Mon, 06 Jul 2020 05:17:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728980AbgGFMO7 (ORCPT + 99 others); Mon, 6 Jul 2020 08:14:59 -0400 Received: from foss.arm.com ([217.140.110.172]:34636 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727896AbgGFMO6 (ORCPT ); Mon, 6 Jul 2020 08:14:58 -0400 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 BB0EF1FB; Mon, 6 Jul 2020 05:14:57 -0700 (PDT) Received: from [192.168.178.2] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F3E973F68F; Mon, 6 Jul 2020 05:14:48 -0700 (PDT) Subject: Re: [PATCH 1/8] cpufreq: allow drivers to flag custom support for freq invariance To: Ionela Voinescu , Viresh Kumar Cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , Catalin Marinas , Sudeep Holla , Will Deacon , Russell King - ARM Linux , Valentin Schneider , Ingo Molnar , Peter Zijlstra , Linux PM , Linux ARM , Linux Kernel Mailing List References: <20200701090751.7543-1-ionela.voinescu@arm.com> <20200701090751.7543-2-ionela.voinescu@arm.com> <20200701094417.ffuvduz6pqknjcks@vireshk-i7> <20200701133330.GA32736@arm.com> <20200702025818.s4oh7rzz3tr6zwqr@vireshk-i7> <20200702114425.GB28120@arm.com> From: Dietmar Eggemann Message-ID: <389dd87f-fed0-e4ea-81f3-5491fd2a54d1@arm.com> Date: Mon, 6 Jul 2020 14:14:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200702114425.GB28120@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/07/2020 13:44, Ionela Voinescu wrote: > Hi, > > On Thursday 02 Jul 2020 at 08:28:18 (+0530), Viresh Kumar wrote: >> On 01-07-20, 18:05, Rafael J. Wysocki wrote: >>> On Wed, Jul 1, 2020 at 3:33 PM Ionela Voinescu wrote: >>>> On Wednesday 01 Jul 2020 at 16:16:17 (+0530), Viresh Kumar wrote: [...] >> There can be other reasons which we aren't able to imagine at this >> point of time. >> > > But I understand both the points you and Rafael raised so it's obvious > that a 'opt in' flag would be the better option. Why can't we just move the arch_set_freq_scale() call from cpufreq driver to cpufreq core w/o introducing a FIE related driver flag? Current scenario for Frequency Invariance Engine (FIE) on arm/arm64. +------------------------------+ +------------------------------+ | | | | | cpufreq core: | | arch: (arm, arm64) | | | | | | weak arch_set_freq_scale() {}| | | | | | | +------------------------------+ | | | | +------------------------------+ | | | | | | | cpufreq driver: | | | | +-----------> arch_set_freq_scale() | | | | { | +------------------------------+ | if (use counters) | | return; | +------------------------------+ | ... | | | | } | | task scheduler: | | | | +-----------> arch_scale_freq_tick()* | | | | { | | | | if (!use counters) | | | | return; | | | | ... | | | | } | +------------------------------+ +------------------------------+ * defined as topology_scale_freq_tick() in arm64 Only Arm/Arm64 defines arch_set_freq_scale() to get the 'legacy' CPUfreq based FIE. This would still be the case when we move arch_set_freq_scale() from individual cpufreq drivers to cpufreq core. Arm64 is the only arch which has to runtime-choose between two different FIEs. This is currently done by bailing out early in one of the FIE functions based on 'use counters'. X86 (and others) will continue to not define arch_set_freq_scale(). The issue with CONFIG_BL_SWITCHER (vexpress-spc-cpufreq.c) could be solved arm/arm64 internally (arch_topology.c) by putting arch_set_freq_scale() under a !CONFIG_BL_SWITCHER guard. I doubt that there are any arm bL systems out there running it. At least I'm not aware of any complaints due to missing FIE support in bl switcher setups so far.