From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18CC8C433E0 for ; Sun, 7 Mar 2021 14:15:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C974B650F5 for ; Sun, 7 Mar 2021 14:15:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231950AbhCGOPJ (ORCPT ); Sun, 7 Mar 2021 09:15:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231889AbhCGOPJ (ORCPT ); Sun, 7 Mar 2021 09:15:09 -0500 Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 006EFC06174A; Sun, 7 Mar 2021 06:15:08 -0800 (PST) Received: by mail-pj1-x1035.google.com with SMTP id kr3-20020a17090b4903b02900c096fc01deso1655649pjb.4; Sun, 07 Mar 2021 06:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ipLIvxmXFEp/52jBUxtNr8uo8Uz63NhczbFOPgGp9eU=; b=eTWA6KFYfUmie1OZqJRYRnwhZxvhyHMcPLD3qq8VvyJyj/x4pm3PrPwpcsDoT0AZI2 5wK+VTCj+R9dI1p39rZkxgjXupcdBoKxyiVaX9Gyr5i2QJuzYAZ3wScGDZH4UWeMUaxd uIRaM0fbAuVNwACeMcYFSnskoD4WLbAjJ6pKQQgMLxWR2+lLjuLHcAGTp4aAbWIRtYJW 3551EQseelPVIMJT6FnMQxhg6T4ykk3pWltDxyaLggSIZUuAbhHzO1wIa5jbQaBFQgt7 qI3jbdb4c/wgjgZ3q/kAUI7MlT9I4BmrBLi0oL6emoaifnySjjsMvwzWpCWgyRS3601G D/hQ== 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=ipLIvxmXFEp/52jBUxtNr8uo8Uz63NhczbFOPgGp9eU=; b=OCSEy6eqpe56yoTvkW3foQb2poU5HmXnT1o4BvZB8QywoQok8kaIPJUqD1zLsaJnJx ufnUczxGBtiVhrJ9WkbCLiv7LZy1WvlGtmFrDu7o3lDBwl1/cHt8m3WCtOLob8YoVtTZ wiChCpWcUtYbX5ZfgFMmpzCACbHl9LdgzK03pw5O/nf/aNTC7E+TtEtWKdBONdB0jWcb IGKDjDHpLSNgiGli1n9f/rvBSrL6ELJlZzj6LQFjXv6s/iuN701J9UX2hh73LMc1NwaQ oegcrG0vXUmZgKOIjD2eT1FqK82vdXBABbeM3urvYqxfEanbTytroeOU1VnkZUqxSKXO ZN8w== X-Gm-Message-State: AOAM5301/uSelphmUXKS+hNlfJKNsWyFXY6BarOtBljgbSgKwCHLw9+0 5KtofYhAQhvdY9PMJc0nuaZbiYH1gz3bkA== X-Google-Smtp-Source: ABdhPJzmA4dYYtXSdm/OyaWI16VRIdgPYeM8m1tOcJXdtvAGqrGftYKHioOd2wyON9GGzRrJCvn5VA== X-Received: by 2002:a17:90a:ba8b:: with SMTP id t11mr20633656pjr.177.1615126508506; Sun, 07 Mar 2021 06:15:08 -0800 (PST) Received: from [172.30.1.19] ([14.32.163.5]) by smtp.gmail.com with ESMTPSA id z2sm7690268pfa.121.2021.03.07.06.15.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Mar 2021 06:15:07 -0800 (PST) Subject: Re: [PATCH v3 1/4] devfreq: Register devfreq as a cooling device on demand To: Daniel Lezcano Cc: lukasz.luba@arm.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, steven.price@arm.com, MyungJoo Ham , Kyungmin Park , Chanwoo Choi References: <20210307094519.9032-1-daniel.lezcano@linaro.org> From: Chanwoo Choi Message-ID: <63c715bf-5bae-4251-f826-baa81b1d3e1c@gmail.com> Date: Sun, 7 Mar 2021 23:15:03 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210307094519.9032-1-daniel.lezcano@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21. 3. 7. 오후 6:45, Daniel Lezcano wrote: > Currently the default behavior is to manually having the devfreq > backend to register themselves as a devfreq cooling device. > > Instead of adding the code in the drivers for the thermal cooling > device registering, let's provide a flag in the devfreq's profile to > tell the common devfreq code to register the newly created devfreq as > a cooling device. > > Suggested-by: Chanwoo Choi > Signed-off-by: Daniel Lezcano > --- > V3: > - Rebased on linux-pm branch without units.h > - Set the cdev to NULL in case of error > - Added description for the cdev field in the devfreq structure > V2: > - Added is_cooling_device boolean in profile structure > - Register cooling device when the is_cooling_device boolean is set > - Remove devfreq cooling device registration in the backend drivers > V1: > - Register devfreq as a cooling device unconditionnally > --- > drivers/devfreq/devfreq.c | 13 +++++++++++++ > include/linux/devfreq.h | 8 ++++++++ > 2 files changed, 21 insertions(+) > > diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c > index bf3047896e41..cf64aeec468f 100644 > --- a/drivers/devfreq/devfreq.c > +++ b/drivers/devfreq/devfreq.c > @@ -11,6 +11,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -26,6 +27,7 @@ > #include > #include > #include > +#include > #include "governor.h" > > #define CREATE_TRACE_POINTS > @@ -935,6 +937,15 @@ struct devfreq *devfreq_add_device(struct device *dev, > > mutex_unlock(&devfreq_list_lock); > > + if (devfreq->profile->is_cooling_device) { > + devfreq->cdev = devfreq_cooling_em_register(devfreq, NULL); > + if (IS_ERR(devfreq->cdev)) { > + dev_info(dev, "Failed to register devfreq " > + "cooling device\n"); > + devfreq->cdev = NULL; > + } > + } > + > return devfreq; > > err_init: > @@ -960,6 +971,8 @@ int devfreq_remove_device(struct devfreq *devfreq) > if (!devfreq) > return -EINVAL; > > + thermal_cooling_device_unregister(devfreq->cdev); I have a question. Why don't you use devfreq_cooling_unregister()? When thermal_cooling_device_unregister(), how can we remove the pm_qos_request of devfreq device? > + > if (devfreq->governor) { > devfreq->governor->event_handler(devfreq, > DEVFREQ_GOV_STOP, NULL); > diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h > index 26ea0850be9b..aba7ace11b72 100644 > --- a/include/linux/devfreq.h > +++ b/include/linux/devfreq.h > @@ -98,11 +98,15 @@ struct devfreq_dev_status { > * @freq_table: Optional list of frequencies to support statistics > * and freq_table must be generated in ascending order. > * @max_state: The size of freq_table. > + * > + * @is_cooling_device: A self-explanatory boolean giving the device a > + * cooling effect property. > */ > struct devfreq_dev_profile { > unsigned long initial_freq; > unsigned int polling_ms; > enum devfreq_timer timer; > + bool is_cooling_device; > > int (*target)(struct device *dev, unsigned long *freq, u32 flags); > int (*get_dev_status)(struct device *dev, > @@ -156,6 +160,7 @@ struct devfreq_stats { > * @suspend_count: suspend requests counter for a device. > * @stats: Statistics of devfreq device behavior > * @transition_notifier_list: list head of DEVFREQ_TRANSITION_NOTIFIER notifier > + * @cdev: Cooling device pointer if the devfreq has cooling property > * @nb_min: Notifier block for DEV_PM_QOS_MIN_FREQUENCY > * @nb_max: Notifier block for DEV_PM_QOS_MAX_FREQUENCY > * > @@ -198,6 +203,9 @@ struct devfreq { > > struct srcu_notifier_head transition_notifier_list; > > + /* Pointer to the cooling device if used for thermal mitigation */ > + struct thermal_cooling_device *cdev; > + > struct notifier_block nb_min; > struct notifier_block nb_max; > }; > -- Best Regards, Samsung Electronics Chanwoo Choi