linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eduardo Valentin <edubezval@gmail.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: linux-pm@vger.kernel.org, linaro-kernel@lists.linaro.org,
	rui.zhang@intel.com
Subject: Re: [PATCH 24/26] cpu_cooling: Store frequencies in descending order
Date: Tue, 2 Dec 2014 19:21:30 -0400	[thread overview]
Message-ID: <20141202232128.GA3645@developer> (raw)
In-Reply-To: <ecb90bfbe1dd69ad73210630ce0a2f988d6210f1.1417167599.git.viresh.kumar@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 4720 bytes --]

Viresh,

On Fri, Nov 28, 2014 at 03:14:18PM +0530, Viresh Kumar wrote:
> CPUFreq framework *doesn't* guarantee that frequencies present in cpufreq table
> will be in ascending or descending order. But cpu_cooling somehow assumes that.
> 
> Probably because most of current users are creating this list from DT, which is
> done with the help of OPP layer. And OPP layer creates the list in ascending
> order of frequencies.
> 
> But cpu_cooling can be used for other platforms too, which don't have
> frequencies arranged in any order.
> 
> This patch tries to fix this issue by creating another list of valid frequencies
> in descending order. Care is also taken to throw warnings for duplicate entries.
> 
> Later patches would use it to simplify code.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
>  drivers/thermal/cpu_cooling.c | 41 ++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 40 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 07414c5..9a4a323 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -65,6 +65,7 @@ struct cpufreq_cooling_device {
>  	unsigned int cpufreq_state;
>  	unsigned int cpufreq_val;
>  	unsigned int max_level;
> +	unsigned int *freq_table;	/* In descending order */
>  	struct cpumask allowed_cpus;
>  	struct list_head head;
>  };
> @@ -321,6 +322,20 @@ static struct notifier_block thermal_cpufreq_notifier_block = {
>  	.notifier_call = cpufreq_thermal_notifier,
>  };
>  
> +static unsigned int find_next_max(struct cpufreq_frequency_table *table,
> +				  unsigned int prev_max)
> +{
> +	struct cpufreq_frequency_table *pos;
> +	unsigned int max = 0;
> +
> +	cpufreq_for_each_valid_entry(pos, table) {
> +		if (pos->frequency > max && pos->frequency < prev_max)

What happens if, for some random reason, the cpufreq table is in
ascending order and this function is called with prev_max == (unsigned
int) -1 ? What would be the returned max?

> +			max = pos->frequency;
> +	}
> +
> +	return max;
> +}
> +
>  /**
>   * __cpufreq_cooling_register - helper function to create cpufreq cooling device
>   * @np: a valid struct device_node to the cooling device device tree node
> @@ -343,6 +358,7 @@ __cpufreq_cooling_register(struct device_node *np,
>  	struct cpufreq_cooling_device *cpufreq_dev;
>  	char dev_name[THERMAL_NAME_LENGTH];
>  	struct cpufreq_frequency_table *pos, *table;
> +	unsigned int freq, i;
>  
>  	table = cpufreq_frequency_get_table(cpumask_first(clip_cpus));
>  	if (!table) {
> @@ -358,6 +374,14 @@ __cpufreq_cooling_register(struct device_node *np,
>  	cpufreq_for_each_valid_entry(pos, table)
>  		cpufreq_dev->max_level++;
>  
> +	cpufreq_dev->freq_table = kmalloc(sizeof(*cpufreq_dev->freq_table) *
> +					  cpufreq_dev->max_level, GFP_KERNEL);
> +	if (!cpufreq_dev->freq_table) {
> +		return ERR_PTR(-ENOMEM);
> +		cool_dev = ERR_PTR(-ENOMEM);
> +		goto free_cdev;
> +	}
> +
>  	/* max_level is an index, not a counter */
>  	cpufreq_dev->max_level--;
>  
> @@ -366,7 +390,7 @@ __cpufreq_cooling_register(struct device_node *np,
>  	cpufreq_dev->id = idr_alloc(&cpufreq_idr, NULL, 0, 0, GFP_KERNEL);
>  	if (unlikely(cpufreq_dev->id < 0)) {
>  		cool_dev = ERR_PTR(cpufreq_dev->id);
> -		goto free_cdev;
> +		goto free_table;
>  	}
>  
>  	snprintf(dev_name, sizeof(dev_name), "thermal-cpufreq-%d",
> @@ -377,6 +401,18 @@ __cpufreq_cooling_register(struct device_node *np,
>  	if (IS_ERR(cool_dev))
>  		goto remove_idr;
>  
> +	/* Fill freq-table in descending order of frequencies */
> +	for (i = 0, freq = -1; i <= cpufreq_dev->max_level; i++) {
> +		freq = find_next_max(table, freq);
> +		cpufreq_dev->freq_table[i] = freq;
> +
> +		/* Warn for duplicate entries */
> +		if (!freq)
> +			pr_warn("%s: table has duplicate entries\n", __func__);
> +		else
> +			pr_debug("%s: freq:%u KHz\n", __func__, freq);
> +	}
> +
>  	cpufreq_dev->cool_dev = cool_dev;
>  	INIT_LIST_HEAD(&cpufreq_dev->head);
>  
> @@ -394,6 +430,8 @@ __cpufreq_cooling_register(struct device_node *np,
>  
>  remove_idr:
>  	idr_remove(&cpufreq_idr, cpufreq_dev->id);
> +free_table:
> +	kfree(cpufreq_dev->freq_table);
>  free_cdev:
>  	kfree(cpufreq_dev);
>  
> @@ -467,6 +505,7 @@ void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
>  
>  	thermal_cooling_device_unregister(cpufreq_dev->cool_dev);
>  	idr_remove(&cpufreq_idr, cpufreq_dev->id);
> +	kfree(cpufreq_dev->freq_table);
>  	kfree(cpufreq_dev);
>  }
>  EXPORT_SYMBOL_GPL(cpufreq_cooling_unregister);
> -- 
> 2.0.3.693.g996b0fd
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2014-12-02 23:21 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-28  9:43 [PATCH 00/26] thermal: cpu_cooling: Fixes and cleanups Viresh Kumar
2014-11-28  9:43 ` [PATCH 01/26] thermal: db8500: pass cpu_present_mask to cpufreq_cooling_register() Viresh Kumar
2014-11-28  9:43 ` [PATCH 02/26] thermal: imx: " Viresh Kumar
2014-11-28  9:43 ` [PATCH 03/26] thermal: exynos: " Viresh Kumar
2014-11-28  9:43 ` [PATCH 04/26] thermal: exynos: Handle -EPROBE_DEFER properly Viresh Kumar
2014-12-02 23:08   ` Eduardo Valentin
2014-11-28  9:43 ` [PATCH 05/26] cpu_cooling: random comment fixups Viresh Kumar
2014-12-02 23:09   ` Eduardo Valentin
2014-11-28  9:44 ` [PATCH 06/26] cpu_cooling: fix doc comment over struct cpufreq_cooling_device Viresh Kumar
2014-11-28  9:44 ` [PATCH 07/26] cpu_cooling: Add comment to clarify relation between cooling state and frequency Viresh Kumar
2014-11-28  9:44 ` [PATCH 08/26] cpu_cooling: Pass variable instead of its type to sizeof() Viresh Kumar
2014-12-02 15:26   ` Javi Merino
2014-12-02 23:07     ` Eduardo Valentin
2014-12-03  4:38       ` Viresh Kumar
2014-11-28  9:44 ` [PATCH 09/26] cpu_cooling: no need to set cpufreq_state to zero Viresh Kumar
2014-11-28  9:44 ` [PATCH 10/26] cpu_cooling: no need to set cpufreq_dev to NULL Viresh Kumar
2014-11-28  9:44 ` [PATCH 11/26] cpu_cooling: propagate error returned by idr_alloc() Viresh Kumar
2014-12-02 15:35   ` Javi Merino
2014-12-03  4:36     ` Viresh Kumar
2014-12-02 23:03   ` Eduardo Valentin
2014-11-28  9:44 ` [PATCH 12/26] cpu_cooling: Don't match min/max frequencies for all CPUs on cooling register Viresh Kumar
2014-11-28  9:44 ` [PATCH 13/26] cpu_cooling: don't iterate over all allowed_cpus to update cpufreq policy Viresh Kumar
2014-11-28  9:44 ` [PATCH 14/26] cpu_cooling: Don't check is_cpufreq_valid() Viresh Kumar
2014-11-28  9:44 ` [PATCH 15/26] cpu_cooling: do error handling at the bottom in __cpufreq_cooling_register() Viresh Kumar
2014-12-02 15:45   ` Javi Merino
2014-11-28  9:44 ` [PATCH 16/26] cpu_cooling: Drop useless locking around idr_alloc/idr_remove Viresh Kumar
2014-12-02 15:53   ` Javi Merino
2014-12-02 23:05   ` Eduardo Valentin
2014-12-03  9:32     ` Viresh Kumar
2014-11-28  9:44 ` [PATCH 17/26] cpu_cooling: Merge cpufreq_apply_cooling() into cpufreq_set_cur_state() Viresh Kumar
2014-11-28  9:44 ` [PATCH 18/26] cpu_cooling: Merge get_cpu_frequency() " Viresh Kumar
2014-11-28  9:44 ` [PATCH 19/26] cpu_cooling: find max level during device registration Viresh Kumar
2014-12-02 23:39   ` Eduardo Valentin
2014-12-03  4:57     ` Viresh Kumar
2014-12-03 13:40       ` Eduardo Valentin
2014-11-28  9:44 ` [PATCH 20/26] cpu_cooling: get_property() doesn't need to support GET_MAXL anymore Viresh Kumar
2014-11-28  9:44 ` [PATCH 21/26] cpu_cooling: create list of cpufreq_cooling_devices Viresh Kumar
2014-12-02 23:12   ` Eduardo Valentin
2014-11-28  9:44 ` [PATCH 22/26] cpu_cooling: use cpufreq_dev_list instead of cpufreq_dev_count Viresh Kumar
2014-11-28  9:44 ` [PATCH 23/26] cpu_cooling: Pass 'cpufreq_dev' to get_property() Viresh Kumar
2014-11-28  9:44 ` [PATCH 24/26] cpu_cooling: Store frequencies in descending order Viresh Kumar
2014-12-02 23:21   ` Eduardo Valentin [this message]
2014-12-03  4:52     ` Viresh Kumar
2014-12-03 13:41       ` Eduardo Valentin
     [not found]         ` <CAKohponw7E9yyvjhP97CzjtcFcq3N+5ysde7DR5q+Nm0s=bKAw@mail.gmail.com>
2014-12-03 14:00           ` Eduardo Valentin
2014-11-28  9:44 ` [PATCH 25/26] cpu_cooling: Use cpufreq_dev->freq_table for finding level/freq Viresh Kumar
2014-12-02 23:36   ` Eduardo Valentin
2014-12-03  5:10     ` Viresh Kumar
2014-12-03 13:32       ` Eduardo Valentin
2014-11-28  9:44 ` [PATCH 26/26] cpu_cooling: update copyright tags Viresh Kumar
2014-12-02 19:41   ` Eduardo Valentin
2014-12-03  4:34     ` Viresh Kumar
2014-12-04  4:41       ` amit daniel kachhap
2014-11-28 13:26 ` [PATCH 00/26] thermal: cpu_cooling: Fixes and cleanups Eduardo Valentin
2014-11-28 13:41   ` Viresh Kumar

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=20141202232128.GA3645@developer \
    --to=edubezval@gmail.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rui.zhang@intel.com \
    --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).