cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order
Subsystems (3)
PATCH 1/1 cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order
From: Markus Mayer <[email protected]>
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.
--- drivers/cpufreq/brcmstb-avs-cpufreq.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/cpufreq/brcmstb-avs-cpufreq.c +5 -4
@@ -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 ;
Signature · 1 line
2.7.4
Viresh Kumar
maintainerQuoted 6 lines · Markus Mayer
From: Markus Mayer <[email protected]>
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.
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.
Quoted 37 lines
Signed-off-by Markus Mayer <[email protected]>--- drivers/cpufreq/brcmstb-avs-cpufreq.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)drivers/cpufreq/brcmstb-avs-cpufreq.c +5
-4@@ -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 ;Signature · 1 line
2.7.4
Signature · 1 line
viresh
Quoted 8 lines · Viresh Kumar
Quoted 6 lines · Markus Mayer
From: Markus Mayer <[email protected]>
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.
Quoted 7 lines
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?
Quoted 3 lines
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?
Quoted 39 lines
Quoted 38 lines
Signed-off-by Markus Mayer <[email protected]>--- drivers/cpufreq/brcmstb-avs-cpufreq.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)drivers/cpufreq/brcmstb-avs-cpufreq.c +5
-4@@ -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 ;Signature · 1 line
2.7.4
Signature · 1 line
Florian
Viresh Kumar
maintainerQuoted 13 lines · Florian Fainelli
Quoted 12 lines · Viresh Kumar
Quoted 6 lines · Markus Mayer
From: Markus Mayer <[email protected]>
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.
Quoted 6 lines
Quoted 3 lines
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?
set_freq_table_sorted() doesn't sort the frequency table but checks if the table is already sorted in a particular order. And then cpufreq_frequency_table_target() is optimized based on this flag. We don't have to enforce any particular ordering here.
Quoted 7 lines
Quoted 2 lines
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?
Right. It shouldn't make any performance improvements.
Signature · 1 line
viresh