Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp323891pxj; Thu, 27 May 2021 00:37:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyuxvw7tgU4yu3JZK/r1rc1LLdoLaDFICUvJgBd/yVDLtxlRXV3DiGxCddnIk392NSsXeFo X-Received: by 2002:a6b:630b:: with SMTP id p11mr1835333iog.133.1622101078250; Thu, 27 May 2021 00:37:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622101078; cv=none; d=google.com; s=arc-20160816; b=GZVVB4Px3pOds56UeVwjA8N1921D3tYXryeRjNDwU8Y9IVEcYgIx4xfNn9KDrQZgiA 6IJAlVLCVozV/d6j7z8WG/1rGTHdHZVQuHfV0WXqgOYCxi0i2kx781al3xa8lFAMr7Cn np8LiuESziAUNGBq5zyF6h2WUPXc7Py9s3pubDc1cxzEeTfHd7igwbpkn/s3Z32W1Gq6 WytJUTb7r+OyL73hsEVMtYWuN3WYmusPIweCQB4x0vHZP2TlKXgtsS+XOdZfViFGhT6V gxoIz5uxpvCMwvYb+G9Fzi0q7AAypXmUbOaETYZQkumWUyxdeHymHEAp89EWeF1rLw6a pxyw== 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=KtloLaSAYF9UXXOH76f2wFuwAOplW6U5iq2zm9Vv9gM=; b=iZ4BpL+3SyyAzhc+Io8hOuCycOeFyeh3857UGkm1WTYhCoECC67lI/98rYMOeDq3Cu 3XWm4+EJwX8eSnQTVuyfx2jwNfFUm993rsx4cqeA2DQYerjpLgRhChA1N153oW4yATRY UqpXaMi3qYC0oxa2qdL0qKkvLlb83S/vFRx0bFkPLAeZP6Ff9h4oTyY2OL7O0DuzSl2R HYmqNPB/oMTRnXruNFKG4biNE8gSI7+dmWtD41TcAmxum15txkrTCEEDtqtcpN+fUABX oW8eRHRBiHDlsd8yClFzbkD/qBllKhUUgrEfsakBpwD61cYIg8CwKFGuBR9Qraj4IcMn h5ig== 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 g9si1515634ild.113.2021.05.27.00.37.43; Thu, 27 May 2021 00:37:58 -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 S234492AbhE0HOt (ORCPT + 99 others); Thu, 27 May 2021 03:14:49 -0400 Received: from foss.arm.com ([217.140.110.172]:53154 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234709AbhE0HOp (ORCPT ); Thu, 27 May 2021 03:14:45 -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 1445A11D4; Thu, 27 May 2021 00:13:13 -0700 (PDT) Received: from [10.57.31.236] (unknown [10.57.31.236]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 011343F73B; Thu, 27 May 2021 00:13:10 -0700 (PDT) Subject: Re: [PATCH v2 0/3] EM / PM: Inefficient OPPs To: Viresh Kumar Cc: Vincent Donnefort , peterz@infradead.org, rjw@rjwysocki.net, vincent.guittot@linaro.org, qperret@google.com, linux-kernel@vger.kernel.org, ionela.voinescu@arm.com, dietmar.eggemann@arm.com References: <1621616064-340235-1-git-send-email-vincent.donnefort@arm.com> <20210526034751.5fl4kekq73gqy2wq@vireshk-i7> <068fa9c4-2b55-3d75-adc7-cf5ef2174b12@arm.com> <20210526093318.cbtjkybzwdchxi5y@vireshk-i7> From: Lukasz Luba Message-ID: Date: Thu, 27 May 2021 08:13:09 +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: <20210526093318.cbtjkybzwdchxi5y@vireshk-i7> 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, On 5/26/21 10:33 AM, Viresh Kumar wrote: > On 26-05-21, 09:56, Lukasz Luba wrote: >> No, these OPPs have to stay because they are used in thermal for cooling >> states. > > This won't break the thermal tables. Thermal just sets the max-freq for a CPU, > and it doesn't depend on the OPP table for that. > >> DT cooling devices might have them set as a scope of possible >> states. We don't want to break existing platforms, don't we? > > I don't think we will end up breaking anything here. > >> We want to 'avoid' those OPPs when possible (no thermal pressure), but >> we might have to use them sometimes. > > Why would we want to use them if they are inefficient ? Thermal or something > else as well ? > > More in the other reply I am sending to Vincent. > I have responded to your email there. I don't know if you have seen it. As I said there, these OPPs, which from energy perspective we call 'inefficient', might be used to provide enough performance under thermal constraints. Regards, Lukasz