Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp359318pxb; Thu, 17 Feb 2022 05:50:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJwvPA/O+fc6shOGxskw6ehmatgOxIyqwtgAOC8tOH7DXgSVKj4WdbFGXo/cuwDzYaQ7Bu2H X-Received: by 2002:a63:83c7:0:b0:36c:3e9a:aa4d with SMTP id h190-20020a6383c7000000b0036c3e9aaa4dmr2479407pge.609.1645105810670; Thu, 17 Feb 2022 05:50:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645105810; cv=none; d=google.com; s=arc-20160816; b=g5i1bIUJw6OHYs4J7XOjPzgoQQXi8XvCCAmVHCUe91W64awUkaNvdHT0q1fQU2RI29 svPRjQS7L76tDEe0mXVpAfiJnAeairGeOt36rbS0qdTe5WoZoL9fspXZj0IDagNASroI FBxRuQpTbu5O8Z0kX+zCAyHZCQ6jKdykK8rdpLyJnzzgEk6Nxh1iFyoWivLs66e7t4Wp RVhuX+4vagDr59nan1eg5ydv/dVjkCYNi1O8weNnTk/Ay4aWpzqsoHToUAhz9r+vlsO+ iiLeuX0JRI6FPizmzpmUO0yagjzMqBIZ7azoKV8UcXYVRdJXRBHzwrpu+VVn5NWpVKjC wfDg== 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=VU7c4EO4Zf1CvSL5CJAbzTIc0kqfOTpgi9r6XvipTNE=; b=mN2J+mvrVb6N84Jc9hEVTgv9LYrB3eyWGIbEKdhmvMw/BdGv0j6wE2SplN2dNDu1mL rrjGMPLk9rHws9wS/BKiJN0+HBP7v6/ru1DLt3N+5hNjtoq/Oyyklma4ovgfPiDArS1m bC65nMI+dyPvbofiuBsMJfmqhETalR9hmviHw26aEnJcllLb3GTvIzJJJAAyuA3J+aZB XAboSOC5XVJ80Wc0iUepTZx1XLGV2n2xJNkRxgyqrK8W7hlJtfMAi8uhncorSM1qm6tL mv4XcZCXX7+wpMAf7YMN4QowiYiYWgaEUUxgmxafIYpL7r/qmux7eOr5hjA3Sjt5H/ru thWw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k24si33925651pfi.65.2022.02.17.05.49.54; Thu, 17 Feb 2022 05:50:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S237341AbiBPWnx (ORCPT + 99 others); Wed, 16 Feb 2022 17:43:53 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:46022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229451AbiBPWnw (ORCPT ); Wed, 16 Feb 2022 17:43:52 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id CCA972819AB; Wed, 16 Feb 2022 14:43:38 -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 7C08B12FC; Wed, 16 Feb 2022 14:43:38 -0800 (PST) Received: from [10.57.13.238] (unknown [10.57.13.238]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 37C9E3F718; Wed, 16 Feb 2022 14:43:36 -0800 (PST) Subject: Re: [PATCH 1/2] thermal: cooling: Check Energy Model type in cpufreq_cooling and devfreq_cooling To: Matthias Kaehlcke , Doug Anderson Cc: LKML , Linux PM , amit daniel kachhap , Daniel Lezcano , Viresh Kumar , "Rafael J. Wysocki" , Amit Kucheria , Zhang Rui , Dietmar Eggemann , Pierre.Gondois@arm.com, Stephen Boyd , Rajendra Nayak , Bjorn Andersson References: <20220207073036.14901-1-lukasz.luba@arm.com> <20220207073036.14901-2-lukasz.luba@arm.com> <4a7d4e94-1461-5bac-5798-29998af9793a@arm.com> From: Lukasz Luba Message-ID: Date: Wed, 16 Feb 2022 22:43:34 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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/16/22 10:13 PM, Matthias Kaehlcke wrote: > On Wed, Feb 16, 2022 at 09:33:50AM -0800, Doug Anderson wrote: >> Hi, >> >> On Wed, Feb 16, 2022 at 7:35 AM Lukasz Luba wrote: >>> >>> Hi Matthias, >>> >>> On 2/9/22 10:17 PM, Matthias Kaehlcke wrote: >>>> On Wed, Feb 09, 2022 at 11:16:36AM +0000, Lukasz Luba wrote: >>>>> >>>>> >>>>> On 2/8/22 5:25 PM, Matthias Kaehlcke wrote: >>>>>> On Tue, Feb 08, 2022 at 09:32:28AM +0000, Lukasz Luba wrote: >>>>>>> >>>>>>> >>> >>> [snip] >>> >>>>>>> Could you point me to those devices please? >>>>>> >>>>>> arch/arm64/boot/dts/qcom/sc7180-trogdor-* >>>>>> >>>>>> Though as per above they shouldn't be impacted by your change, since the >>>>>> CPUs always pretend to use milli-Watts. >>>>>> >>>>>> [skipped some questions/answers since sc7180 isn't actually impacted by >>>>>> the change] >>>>> >>>>> Thank you Matthias. I will investigate your setup to get better >>>>> understanding. >>>> >>>> Thanks! >>>> >>> >>> I've checked those DT files and related code. >>> As you already said, this patch is safe for them. >>> So we can apply it IMO. >>> >>> >>> -------------Off-topic------------------ >>> Not in $subject comments: >>> >>> AFAICS based on two files which define thermal zones: >>> sc7180-trogdor-homestar.dtsi >>> sc7180-trogdor-coachz.dtsi >>> >>> only the 'big' cores are used as cooling devices in the >>> 'skin_temp_thermal' - the CPU6 and CPU7. >>> >>> I assume you don't want to model at all the power usage >>> from the Little cluster (which is quite big: 6 CPUs), do you? >>> I can see that the Little CPUs have small dyn-power-coeff >>> ~30% of the big and lower max freq, but still might be worth >>> to add them to IPA. You might give them more 'weight', to >>> make sure they receive more power during power split. > > In experiments we saw that including the little cores as cooling > devices for 'skin_temp_thermal' didn't have a significant impact on > thermals, so we left them out. > >>> You also don't have GPU cooling device in that thermal zone. >>> Based on my experience if your GPU is a power hungry one, >>> e.g. 2-4Watts, you might get better results when you model >>> this 'hot' device (which impacts your temp sensor reported value). >> >> I think the two boards you point at (homestar and coachz) are just the >> two that override the default defined in the SoC dtsi file. If you >> look in sc7180.dtsi you'll see 'gpuss1-thermal' which has a cooling >> map. You can also see the cooling maps for the littles. > > Yep, plus thermal zones with cooling maps for the big cores. > >> I guess we don't have a `dynamic-power-coefficient` for the GPU, >> though? Seems like we should, but I haven't dug through all the code >> here... > > To my knowledge the SC7x80 GPU doesn't register an energy model, which is > one of the reasons the GPU wasn't included as cooling device for > 'skin_temp_thermal'. > You can give it a try by editing the DT and adding in the GPU node the 'dynamic-power-coefficient' + probably small modification in the driver code. If the GPU driver registers the cooling device in the new way, you would also get EM registered thanks to the devfreq cooling new code (commit: 84e0d87c9944eb36ae6037a). You can check an example from Panfrost GPU driver [1]. I can see some upstream MSM GPU driver, but I don't know if that is your GPU driver. It registers the 'old' way the devfreq cooling [2] but it would be easy to change to use the new function. The GPU driver would use the same dev_pm_opp_of_register_em() as your CPUs do, so EM would be in 'milli-Watts' (so should be fine). [1] https://elixir.bootlin.com/linux/v5.16/source/drivers/gpu/drm/panfrost/panfrost_devfreq.c#L153 [2] https://elixir.bootlin.com/linux/v5.16/source/drivers/gpu/drm/msm/msm_gpu_devfreq.c#L129