Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp949434pxv; Fri, 25 Jun 2021 01:57:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzY1HlJhH58JK7EcC87mL/aUq6qPDgMXD8g+HlcXf1t6ZGmowBInp/DEIKJ6oVNgVsVeSJ3 X-Received: by 2002:a6b:b2c4:: with SMTP id b187mr5660474iof.206.1624611423763; Fri, 25 Jun 2021 01:57:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624611423; cv=none; d=google.com; s=arc-20160816; b=Sv8ps7xFZ35oO01GJz+i2PX3vZ4IRCXen1SJzmpDCqq6zjOvVIjSHZR54fMJal0DTN YtX166m5ZzQW5CPfavoR6vxj7i66GJAR2Etldgf1dJB8zjrHgh216A2sVYcZMTQzYyPs kkj/tgGwyVuasLxyOVNXbzY+42Vcj3Xbh+FXgemBl6pD+JsHkL748QRDZt4fGvlaav/v JQ8wEF8h8Eu5jRQ/FUCgHD1rvutlk8wSPHgAZJ+/NPOcL/pIvITzUosVzHsG42laoPmM wNIw55tY4+w39KMbE2dprR9GFYQIc0ZCZyshiIF5zFR6RZG5cpl8re2aJbP2JvlxoNyi /n7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=52TCNLVbbIghUZIXhwTm690RPqm8ossBdOK+OlmMyz0=; b=pbSOmT0F0ovdg87/NVagSZHZScsV8o2cl+HrNd95lvJ0IrG2yI8dq3Sk+5tj0zcSzX +zKOglLuPBP3lb6e+Q9XRTzZdVErg2RwnTJB0M/IMT/1tMWvH8TATK0tqUlZs/GmeINE +0css0exxMkIjXuklcrleyL3lRRG/Ne6Nb4QVrfz99JRqwL4slircQNRtXFg2Rt+qD8A dmaFgLmx3xqVNDcdXq5ssuzSFgzFu5xsUk/mXg2Ylfr8/ftt91w0AMNmW+uQmCR54fPf ltgFzPBByVQNPFVNev3NRykH61yICSSIcZA0DfCZvTa4+8X8TYPg5DeAizPwFrhccctV kwkA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j25si6060385jaj.93.2021.06.25.01.56.52; Fri, 25 Jun 2021 01:57:03 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230449AbhFYI5S (ORCPT + 99 others); Fri, 25 Jun 2021 04:57:18 -0400 Received: from foss.arm.com ([217.140.110.172]:50524 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230433AbhFYI5R (ORCPT ); Fri, 25 Jun 2021 04:57:17 -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 6903331B; Fri, 25 Jun 2021 01:54:56 -0700 (PDT) Received: from localhost (unknown [10.1.195.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 058393F719; Fri, 25 Jun 2021 01:54:55 -0700 (PDT) Date: Fri, 25 Jun 2021 09:54:54 +0100 From: Ionela Voinescu To: Viresh Kumar Cc: Rafael Wysocki , Sudeep Holla , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , linux-pm@vger.kernel.org, Qian Cai , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V3 4/4] cpufreq: CPPC: Add support for frequency invariance Message-ID: <20210625085454.GA15540@arm.com> References: <20210624094812.GA6095@arm.com> <20210624130418.poiy4ph66mbv3y67@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210624130418.poiy4ph66mbv3y67@vireshk-i7> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hey, On Thursday 24 Jun 2021 at 18:34:18 (+0530), Viresh Kumar wrote: > On 24-06-21, 10:48, Ionela Voinescu wrote: > > On Monday 21 Jun 2021 at 14:49:37 (+0530), Viresh Kumar wrote: > > > The Frequency Invariance Engine (FIE) is providing a frequency scaling > > > correction factor that helps achieve more accurate load-tracking. > > [..] > > > +static void cppc_cpufreq_cpu_fie_exit(struct cpufreq_policy *policy) > > > +{ > > > + struct cppc_freq_invariance *cppc_fi; > > > + int cpu; > > > + > > > + if (cppc_cpufreq_driver.get == hisi_cppc_cpufreq_get_rate) > > > + return; > > > + > > > + /* policy->cpus will be empty here, use related_cpus instead */ > > > + topology_clear_scale_freq_source(SCALE_FREQ_SOURCE_CPPC, policy->related_cpus); > > > + > > > + for_each_cpu(cpu, policy->related_cpus) { > > > + cppc_fi = &per_cpu(cppc_freq_inv, cpu); > > > > Do you think it might be worth having here something like: > > > > if (!cppc_fi->cpu_data) > > continue; > > > > This would be to protect against cases where the platform does not boot > > with all CPUs or the module is loaded after some have already been > > offlined. Unlikely, but.. > > Even in that case policy->cpus will contain all offline+online CPUs (at ->init() > time), isn't it ? > Right, my bad. I missed cpumask_and(policy->cpus, policy->cpus, cpu_online_mask) being done after init(). It logically seems a bit wrong, but drivers are in control of setting policy->cpus and acting on it, and in this case the driver does the right thing. Thanks, Ionela. > > > + irq_work_sync(&cppc_fi->irq_work); > > > + kthread_cancel_work_sync(&cppc_fi->work); > > > + } > > > +} > > > > The rest of the code is almost the same as the original, so that is all > > from me :). > > > > Thanks, > > Ionela. > > -- > viresh