Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp3519435pxt; Tue, 10 Aug 2021 05:41:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxdslDXpwadvMoVE2u8MAAtg7u0asUE0XXQu/KlWuUUfPy6M13fIEur0Xs/k/dcKRoCPbfJ X-Received: by 2002:a92:8e41:: with SMTP id k1mr520607ilh.276.1628599268502; Tue, 10 Aug 2021 05:41:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628599268; cv=none; d=google.com; s=arc-20160816; b=f8NTmIO3oCrqYONY2lrGRENU37prx6Z5LMLkmKYhevUQ+4tkHz8/1DUXKuMz1BMIQf 2y+T6xSTBqvA7M2AHTfBEIoKoGer0g/+iMb7Kxg7Vhoh80x8BizKRroR8XRz2FjhacaN ENhBBbG3y4fm7SRHjxjHxF4JR4Ytn+1Q4KIUQXJEEXkRObfrVLVrIJe96CqbWbWzi7Mn jZAJ4jvj1fmqYO6u9x70cSDWvyooiBi6VidOQX2j6K57g2bP6CyuQO6MFQbBnqtWrfa2 m0VpsgemPuEDzhkzpYSFFSi8ZLPJNRDP4UlhM8RBKTwWIdj1cLNMUtrFefcQzRe3NzWu DOFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=Y97hS2TYHgUS2jXNBJlGIbsICKC6/8Rk2kh3bEOBqCc=; b=cj9ab42/AoV2LSlHFjHBKGqKPYQnvo8KjEA5cdmdG64Jo31zwawiIN3ayV84xulmqK 6XzrBNs4VdKIlhj6oBXgnWEnM2BQTGzmrq7ZLbGqLel22rY+qML8zBmjqYir42jxtNcZ +D0grNsrPre1kk6woIUjvDUGQ65z0/SG2ltir13a+jw3gQNcipCb/nSiMrJOGO9O0uhq 4C4/GXw5THZPe62wAJIK7OUk8tmy3p9pkA+v4+6m8CUGbembp/DNTyePGOspwMujoUos hk17G1l1O0eX4AAGt6vuexTu+k6xmzYUo3DIxaB4k5Xri7CWCv+rUatiEo4m4fItjFYE JK1w== 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 n1si23862668ilt.39.2021.08.10.05.40.54; Tue, 10 Aug 2021 05:41:08 -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 S238851AbhHJJSb (ORCPT + 99 others); Tue, 10 Aug 2021 05:18:31 -0400 Received: from foss.arm.com ([217.140.110.172]:51682 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238813AbhHJJS0 (ORCPT ); Tue, 10 Aug 2021 05:18:26 -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 78AA6D6E; Tue, 10 Aug 2021 02:18:04 -0700 (PDT) Received: from [10.57.9.181] (unknown [10.57.9.181]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EC2E23F718; Tue, 10 Aug 2021 02:17:59 -0700 (PDT) Subject: Re: [PATCH 0/8] cpufreq: Auto-register with energy model To: Viresh Kumar , Andy Gross Cc: Rafael Wysocki , Vincent Donnefort , Bjorn Andersson , Cristian Marussi , Fabio Estevam , Kevin Hilman , Matthias Brugger , NXP Linux Team , Pengutronix Kernel Team , Sascha Hauer , Shawn Guo , Sudeep Holla , linux-pm@vger.kernel.org, Vincent Guittot , linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-omap@vger.kernel.org References: From: Lukasz Luba Message-ID: <6449a61f-a5fc-0b81-65b2-7bf77b8a71aa@arm.com> Date: Tue, 10 Aug 2021 10:17:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Viresh, I like the idea, only small comments here in the cover letter. On 8/10/21 8:36 AM, Viresh Kumar wrote: > Provide a cpufreq driver flag so drivers can ask the cpufreq core to register > with the EM core on their behalf. This allows us to get rid of duplicated code > in the drivers and fix the unregistration part as well, which none of the > drivers have done until now. The EM is never freed for CPUs by design. The unregister function was introduced for devfreq devices. > > This would also make the registration with EM core to happen only after policy > is fully initialized, and the EM core can do other stuff from in there, like > marking frequencies as inefficient (WIP). Though this patchset is useful without > that work being done and should be merged nevertheless. > > This doesn't update scmi cpufreq driver for now as it is a special case and need > to be handled differently. Though we can make it work with this if required. The scmi cpufreq driver uses direct EM API, which provides flexibility and should stay as is. Let me review the patches. Regards, Lukasz