Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1861909pxb; Fri, 5 Mar 2021 01:12:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJxnKcPyn49cgOTfZgl+zaMjVaIcCT0ex9PEQBMrkrjEztFVEkl9NsmB/WpbR6mAzyYGy+TT X-Received: by 2002:a92:60a:: with SMTP id x10mr7884707ilg.262.1614935521081; Fri, 05 Mar 2021 01:12:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614935521; cv=none; d=google.com; s=arc-20160816; b=Ku2PBSkTyZ+IeJ3SgviIv1S3twW/OxoiNxCzUBUISio7UYkH/9Eoem1VlMeCxUCbOh 7DRsCCwIwA2WKGUxJe8PezwB3CahIEq5DE9XKsGI5NyVSJp55fq7qQdjsbPhpx+Uj2jt yKX2mYWVx00ht+CcTrua6I/WJqwEJYn4xKcTmKry/zoSiOuvGzCoKdZLluV4rUMHx+Wa Og1FEMmDxQ7ff3O+rbes5YwPeloh3ifqplkmExW5ABL5adV8vUibm62gJq8OxCYbuXP6 TAMJFfck8aezyYTfzIJaaH/PqqDy32itu2MceaZ6TrUaBgsEbE3p8iPYRLWCYerECfaI 8c8A== 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:dkim-signature; bh=63BZTwf3MLMQAkn2BdrHZ1xTK2bwmRKITVezIt3sV9k=; b=RB4hlzWljq480Q9ah5uCwCunM3xuV6ujdJF5nOUWfmGx1+lm1MnQo1/5Uvsx1do+DV azN8cYy8QSYwJPIFS4HSS5X+qdyaouxalWx4ZITwIKPuQ0yvOAwPAxl1by83iR5zKOGL Ivj4fjxOblRf/R1ypR+Ojr6suysp2FVkNIKcSNaZ+mOOTgeXf8c2fc1t10DqG1FkJPnH g4AKGzoJPtQsP/VI0QOn4o3xC3U5Gl20N+wBUcFxtaTsxbGKZPlpp7gMACh8A9dKcJIf COL7ZQsIO5m2HH7qH0uLIWl7dD26JfPKzwS9Ng3xPPgaVIzmB1XR7iyOAFwNgnUFO6tu YXPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=qIhQjiqO; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l11si1815504iop.53.2021.03.05.01.11.47; Fri, 05 Mar 2021 01:12:01 -0800 (PST) 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; dkim=pass header.i=@linaro.org header.s=google header.b=qIhQjiqO; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229464AbhCEJK3 (ORCPT + 99 others); Fri, 5 Mar 2021 04:10:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50584 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229589AbhCEJKV (ORCPT ); Fri, 5 Mar 2021 04:10:21 -0500 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C570EC06175F for ; Fri, 5 Mar 2021 01:10:19 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id w11so1220680wrr.10 for ; Fri, 05 Mar 2021 01:10:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=63BZTwf3MLMQAkn2BdrHZ1xTK2bwmRKITVezIt3sV9k=; b=qIhQjiqOP57bI/hD1kFs2/6tOxvCVgreYU6SWkrNvwDFlxQwEnv3kFFVIEiRAtV0bs ghqevsOeKImy2rOLICgbeqWEThfUBb62WD98f6OLGoRbJPi+3ECHQTjzD7T09L6iNH1X oAm7OJWf/W0mgFiXr47BHOFHjWLpDx1yqdw07vCbJeqMn/SZ6et48VCP9iSh47jL2RrG gVVStZeH/O8pcqGXOJ9EMd4F8njNQwNN9alPkOkaB3F9hedHZi9ivpiK4dy/1O75s2EC b80SYjFrOOr3XHujkCejze9BNQcAsrZT3Cpqt9O3cmDicy//qO7rhTZOo3V9VbGlcI9b TE4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=63BZTwf3MLMQAkn2BdrHZ1xTK2bwmRKITVezIt3sV9k=; b=lstpnIf9NlRwm2C8qAmFQjlwP56YEj8rTQeQTEWJF+JSIrglC+fcwMM5LcLdEiaiVq f3WSLJmPbqahEGxZwpgZylG0Y9D2gtOICXmQWo+7kcCgVOIEud8xum54X823xi+Sxu8w HQduBbYop4mjU3+TFu7ZSuzek1SebCC+yGIua3seEpW2hUhbRmPJ4Z0+eL+WDGL6/8mL BrjUBFaF4AGjSnph/qJczoq267Dg/JYme/YP161lTWBal3QpRf5JNlcxA2m+u65ZoeZc 3Ga/7KuclybMvB2yjBdrCmGANtUoEy3aETBzrTkEPF2eO5c5WCEOZZ1+3zNkoAS6hiLK qjyw== X-Gm-Message-State: AOAM530Y9fKq3S7xCUXxOI/0+/KAQZ/jOFldluNo/nAry06OCfEOaUT/ CF4bNzLrL3advsGgE+Wl2JVO/g== X-Received: by 2002:a5d:5411:: with SMTP id g17mr8376871wrv.194.1614935418378; Fri, 05 Mar 2021 01:10:18 -0800 (PST) Received: from [192.168.0.41] (lns-bzn-59-82-252-144-192.adsl.proxad.net. [82.252.144.192]) by smtp.googlemail.com with ESMTPSA id 36sm3695411wrh.94.2021.03.05.01.10.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Mar 2021 01:10:17 -0800 (PST) Subject: Re: [PATCH] devfreq: Register devfreq as a cooling device To: Steven Price , cwchoi00@gmail.com, kyungmin.park@samsung.com, myungjoo.ham@samsung.com Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Chanwoo Choi , Qiang Yu , David Airlie , Daniel Vetter , Rob Clark , Sean Paul , Rob Herring , Tomeu Vizoso , Alyssa Rosenzweig , "open list:DRM DRIVERS FOR LIMA" , "moderated list:DRM DRIVERS FOR LIMA" , "open list:DRM DRIVER FOR MSM ADRENO GPU" , "open list:DRM DRIVER FOR MSM ADRENO GPU" References: <20210304125034.28404-1-daniel.lezcano@linaro.org> <23db1b13-9418-91f5-4871-f45b983f6e3c@arm.com> From: Daniel Lezcano Message-ID: Date: Fri, 5 Mar 2021 10:10:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <23db1b13-9418-91f5-4871-f45b983f6e3c@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/03/2021 09:12, Steven Price wrote: > On 04/03/2021 12:50, Daniel Lezcano wrote: >> Currently the default behavior is to manually having the devfreq >> backend to register themselves as a devfreq cooling device. >> >> There are no so many and actually it makes more sense to register the >> devfreq device when adding it. >> >> Consequently, every devfreq becomes a cooling device like cpufreq is. >> >> Having a devfreq being registered as a cooling device can not mitigate >> a thermal zone if it is not bound to this one. Thus, the current >> configurations are not impacted by this change. >> >> Signed-off-by: Daniel Lezcano >> --- [ ... ] >>       if (pfdevfreq->opp_of_table_added) { >>           dev_pm_opp_of_remove_table(&pfdev->pdev->dev); >>           pfdevfreq->opp_of_table_added = false; > > You've removed all references to pfdevfreq->cooling, so please also > remove the member from struct panfrost_devfreq (as already done with > lima and msm). Sure, thanks for spotting this. -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog