[PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order

Florian Fainelli f.fainelli at gmail.com
Wed May 16 12:24:23 PDT 2018


On 05/15/2018 09:32 PM, Viresh Kumar wrote:
> On 15-05-18, 20:49, Markus Mayer wrote:
>> From: Markus Mayer <mmayer at broadcom.com>
>>
>> Most CPUfreq drivers (at least on ARM) seem to be sorting the available
>> frequencies from lowest to highest. To match this behaviour, we reverse
>> the sorting order in brcmstb-avs-cpufreq, so it is now also lowest to
>> highest.
> 
> The reasoning isn't correct. Just because everyone else is doing it
> doesn't make it right and so you shouldn't change just because of
> that.
> 
> What you must written instead in the commit log is that the cpufreq
> core performs better if the table is sorted (in any order), and so we
> must sort it as well.

Is there a reason why set_freq_table_sorted() tries an ascending or
descending sort, but does not enforce one versus another for all drivers?

> 
> But I feel the table is already sorted for your platform, isn't it?
> And I don't see a clear advantage of merging this patch.

The patch changes the order to have the lowest to highest, whereas the
current implementation has them from highest to lowest. From what you
are saying, it sounds like this is unnecessary, since the sorting is
already making things efficient enough, so this is just a cosmetic thing?

> 
>> Signed-off-by: Markus Mayer <mmayer at broadcom.com>
>> ---
>>  drivers/cpufreq/brcmstb-avs-cpufreq.c | 9 +++++----
>>  1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> index b07559b9ed99..7dac3205d3eb 100644
>> --- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> +++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> @@ -403,7 +403,7 @@ brcm_avs_get_freq_table(struct device *dev, struct private_data *priv)
>>  {
>>  	struct cpufreq_frequency_table *table;
>>  	unsigned int pstate;
>> -	int i, ret;
>> +	int p, i, ret;
>>  
>>  	/* Remember P-state for later */
>>  	ret = brcm_avs_get_pstate(priv, &pstate);
>> @@ -415,12 +415,13 @@ brcm_avs_get_freq_table(struct device *dev, struct private_data *priv)
>>  	if (!table)
>>  		return ERR_PTR(-ENOMEM);
>>  
>> -	for (i = AVS_PSTATE_P0; i <= AVS_PSTATE_MAX; i++) {
>> -		ret = brcm_avs_set_pstate(priv, i);
>> +	for (p = AVS_PSTATE_MAX, i = 0; p >= 0; p--, i++) {
>> +		ret = brcm_avs_set_pstate(priv, p);
>>  		if (ret)
>>  			return ERR_PTR(ret);
>>  		table[i].frequency = brcm_avs_get_frequency(priv->base);
>> -		table[i].driver_data = i;
>> +		/* Store the corresponding P-state with each frequency */
>> +		table[i].driver_data = p;
>>  	}
>>  	table[i].frequency = CPUFREQ_TABLE_END;
>>  
>> -- 
>> 2.7.4
> 


-- 
Florian



More information about the linux-arm-kernel mailing list