linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthias Kaehlcke <mka@chromium.org>
To: Amit Kucheria <amit.kucheria@linaro.org>
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	bjorn.andersson@linaro.org, viresh.kumar@linaro.org,
	edubezval@gmail.com, andy.gross@linaro.org, tdas@codeaurora.org,
	swboyd@chromium.org, dianders@chromium.org,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	"open list:CPU FREQUENCY DRIVERS" <linux-pm@vger.kernel.org>
Subject: Re: [PATCH v1 2/7] drivers: cpufreq: Add thermal_cooling_device pointer to struct cpufreq_policy
Date: Wed, 9 Jan 2019 17:01:57 -0800	[thread overview]
Message-ID: <20190110010157.GU261387@google.com> (raw)
In-Reply-To: <aadc9cff04dc310138b41979239ce51938afedce.1547078153.git.amit.kucheria@linaro.org>

On Thu, Jan 10, 2019 at 05:30:51AM +0530, Amit Kucheria wrote:
> Several cpufreq drivers register themselves as thermal cooling devices.
> Adding a pointer to struct cpufreq_policy removes the need for them to
> store this pointer in a private data structure.
> 
> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> ---
>  include/linux/cpufreq.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index c86d6d8bdfed..2496549d7573 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -95,6 +95,8 @@ struct cpufreq_policy {
>  	struct cpufreq_frequency_table	*freq_table;
>  	enum cpufreq_table_sorting freq_table_sorted;
>  
> +	struct thermal_cooling_device *cooldev; /* Pointer to the cooling
> +						 * device if used for thermal mitigation */
>  	struct list_head        policy_list;
>  	struct kobject		kobj;
>  	struct completion	kobj_unregister;

I've mixed feelings about this. It's definitely desirable to avoid
code duplication and tying the cooling device to the cpufreq_policy is
a convenient way to achieve that. However semantically it seems a bit
odd that a CPU cooling device is part of the cpufreq policy.

Anyway, unless there are better ideas we probably want to be pragmatic
here, so if Viresh is fine with it who am I to complain ;-)

Cheers

Matthias



  reply	other threads:[~2019-01-10  1:02 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-10  0:00 [PATCH v1 0/7] Thermal throttling for SDM845 Amit Kucheria
2019-01-10  0:00 ` [PATCH v1 1/7] drivers: thermal: of-thermal: Print name of device node with error Amit Kucheria
2019-01-10  0:15   ` Stephen Boyd
2019-01-10  0:00 ` [PATCH v1 2/7] drivers: cpufreq: Add thermal_cooling_device pointer to struct cpufreq_policy Amit Kucheria
2019-01-10  1:01   ` Matthias Kaehlcke [this message]
2019-01-10  0:00 ` [PATCH v1 3/7] cpu_cooling: Add generic driver ready callback Amit Kucheria
2019-01-10  6:14   ` Viresh Kumar
2019-01-10  0:00 ` [PATCH v1 4/7] cpufreq: qcom-hw: Move to device_initcall Amit Kucheria
2019-01-10  6:44   ` Viresh Kumar
2019-01-10  0:00 ` [PATCH v1 5/7] cpufreq: qcom-hw: Register as a cpufreq cooling device Amit Kucheria
2019-01-10  6:12   ` Viresh Kumar
2019-01-10  9:03     ` Amit Kucheria
2019-01-10  9:32     ` Rafael J. Wysocki
2019-01-10  0:00 ` [PATCH v1 6/7] arm64: dts: sdm845: Increase alert trip point to 95 degrees Amit Kucheria
2019-01-10  0:29   ` Stephen Boyd
2019-01-10 17:14     ` Doug Anderson
2019-01-10 20:06     ` Amit Kucheria
2019-01-10  1:15   ` Matthias Kaehlcke
2019-01-10  2:15     ` Matthias Kaehlcke
2019-01-10 19:45       ` Amit Kucheria
2019-01-10 20:00         ` Matthias Kaehlcke
2019-01-11  3:32           ` Viresh Kumar
2019-01-11 10:24     ` Amit Kucheria
2019-01-11 18:30       ` Matthias Kaehlcke
2019-01-10  0:00 ` [PATCH v1 7/7] arm64: dts: sdm845: wireup the thermal trip points to cpufreq Amit Kucheria
2019-01-10  0:28   ` Stephen Boyd
2019-01-10 12:28     ` Amit Kucheria
2019-01-10  2:22   ` Matthias Kaehlcke
2019-01-10  6:23     ` Viresh Kumar
2019-01-10 18:42       ` Matthias Kaehlcke
2019-01-11  3:46         ` Viresh Kumar
2019-01-11 19:58           ` Matthias Kaehlcke
2019-01-14  5:59             ` Viresh Kumar
2019-01-11  0:30   ` Matthias Kaehlcke
2019-01-11 11:17     ` Amit Kucheria
2019-01-11 20:36       ` Matthias Kaehlcke
2019-01-14  8:22         ` Amit Kucheria

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190110010157.GU261387@google.com \
    --to=mka@chromium.org \
    --cc=amit.kucheria@linaro.org \
    --cc=andy.gross@linaro.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=dianders@chromium.org \
    --cc=edubezval@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=swboyd@chromium.org \
    --cc=tdas@codeaurora.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).