Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1633826pxb; Wed, 9 Feb 2022 00:41:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJxgCtQV9rSp3Gs75XgLybZEMot98FiXnx8yoEyu2hW1UOpDzQudkKz98kNYUp1SHjOL/EEs X-Received: by 2002:a63:d1:: with SMTP id 200mr1059222pga.402.1644396113843; Wed, 09 Feb 2022 00:41:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644396113; cv=none; d=google.com; s=arc-20160816; b=Hq92tdfOWLWL+GFyN2RxlAzHSgUiTsaLTy8SoUcpSjuKKtWxKa5Z5QjFMUhtYBAbgT e14bNR0T3y1DE4udObS6tWBe5CLE4qqrbz89QqNvoz+u/OZI4zGHPN466AGQElup6PxZ 6qvzYV/iq8M8WqGFQhlsxT/PEntv7v6Cpc1J72XwSvdEMR2jgBWrr+LidQLnPrz0ftq3 cWsXf1FftjNkWrCXwly4HQwn4yyfkLECRH0dNz7uIt0dRMZ2cJiO5um+2Pf06DASw6KK cnZAQzV6OQsnxDe6h1IixhR2Cy8575CT9s3xoq/15h1bMZR+Ft256EgkE6kHvQPMde+2 rEfQ== 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=ljQ9y2X6n07wdkWrgsEdZE7OVyidjfyidkGu/15t/4I=; b=AgVULdOPwQET3AZzGpUEZKdVLCxC9/89Q+o8nt/3qnpR/CW9hVXmq2EmI+jP1OntnF WmqcfVAtKU3rTOfUahK3a3BlyEZpzfdX9or8IsuWzyvbv1WQr94QNFGnsIFOhO/aucj3 tdme+Ws7j173een3jFLNV6KWiv0cPkbJkLsxBCY9iVwyMfcAvJk4n+T0Zl/R+ppNNnrz SpqKBIbj5Dkw5nng2mXS8JpiCfoomFx5BQPo3hjoSt5dNXMdWLijDtYJgcZPU/iKzAPu XLZo6V4bRr71tshbz8DwA94uknq95U9ihg8ukLUfu5UavYAXjLLvUKvb4Wj5nRH88ZFe jVOw== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id e191si14967958pgc.696.2022.02.09.00.41.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 00:41:53 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id DA43BC014C9A; Wed, 9 Feb 2022 00:39:52 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1391763AbiBGMDB (ORCPT + 99 others); Mon, 7 Feb 2022 07:03:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55262 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1385880AbiBGLpB (ORCPT ); Mon, 7 Feb 2022 06:45:01 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id CB145C0401ED; Mon, 7 Feb 2022 03:44:48 -0800 (PST) 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 258F911B3; Mon, 7 Feb 2022 03:44:48 -0800 (PST) Received: from [10.57.15.201] (unknown [10.57.15.201]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 31D9B3F70D; Mon, 7 Feb 2022 03:44:45 -0800 (PST) Subject: Re: [PATCH 0/2] Ignore Energy Model with abstract scale in IPA and DTPM To: Daniel Lezcano Cc: amit.kachhap@gmail.com, viresh.kumar@linaro.org, rafael@kernel.org, amitk@kernel.org, rui.zhang@intel.com, dietmar.eggemann@arm.com, Pierre.Gondois@arm.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org References: <20220207073036.14901-1-lukasz.luba@arm.com> <0d2217e0-44f7-8587-3e1f-a73d301ab166@linaro.org> From: Lukasz Luba Message-ID: <616307f7-b419-8e36-6879-6cf6f4e02d5a@arm.com> Date: Mon, 7 Feb 2022 11:44:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <0d2217e0-44f7-8587-3e1f-a73d301ab166@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/7/22 10:41 AM, Daniel Lezcano wrote: > On 07/02/2022 08:30, Lukasz Luba wrote: >> Hi all, >> >> The Energy Model supports abstract scale power values. This might cause >> issues for some mechanisms like thermal governor IPA or DTPM, which >> expect that all devices provide sane power values. This patch set >> prevents >> from registering such devices for IPA and DTPM. > > > Does it mean for example big and little have both 0-100 ? > > Unfortunately, these can be any numbers. I hope at least the CPUs Big and Little power have sense: Little power is not higher than Big power. The purpose of EM is to enable EAS, so this power relation between Big and Little should have sense. Someone who is not willing to or cannot expose real power values, still wants the EAS to operate (my assumption and hope). The SCMI FW can provide abstract power values. It's in the SCMI spec. Thus, creating these abstract scale power values for big.LITTLE the right way should result in properly working EAS. I can also have hope for GPU vs. Big power, but it is a weaker hope. The second is more tricky to distinguish even if you have a domain knowledge, but not the real measurements with you. The GPU power values is also a 'sensitive' knowledge to share. Open source guys can do that (after measurements), but some vendor's engineers probably can't.