* [PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order
@ 2018-05-16 3:49 Markus Mayer
2018-05-16 4:32 ` Viresh Kumar
0 siblings, 1 reply; 7+ messages in thread
From: Markus Mayer @ 2018-05-16 3:49 UTC (permalink / raw)
To: Viresh Kumar, Rafael J. Wysocki, Brian Norris, Gregory Fong,
Florian Fainelli
Cc: Markus Mayer, Broadcom Kernel List, Power Management List,
ARM Kernel List, Linux Kernel Mailing List
From: Markus Mayer <mmayer@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.
Signed-off-by: Markus Mayer <mmayer@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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order
2018-05-16 3:49 [PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order Markus Mayer
@ 2018-05-16 4:32 ` Viresh Kumar
0 siblings, 0 replies; 7+ messages in thread
From: Viresh Kumar @ 2018-05-16 4:32 UTC (permalink / raw)
To: Markus Mayer
Cc: Rafael J. Wysocki, Brian Norris, Gregory Fong, Florian Fainelli,
Markus Mayer, Broadcom Kernel List, Power Management List,
ARM Kernel List, Linux Kernel Mailing List
On 15-05-18, 20:49, Markus Mayer wrote:
> From: Markus Mayer <mmayer@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.
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.
> Signed-off-by: Markus Mayer <mmayer@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
--
viresh
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order
@ 2018-05-16 4:32 ` Viresh Kumar
0 siblings, 0 replies; 7+ messages in thread
From: Viresh Kumar @ 2018-05-16 4:32 UTC (permalink / raw)
To: linux-arm-kernel
On 15-05-18, 20:49, Markus Mayer wrote:
> From: Markus Mayer <mmayer@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.
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.
> Signed-off-by: Markus Mayer <mmayer@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
--
viresh
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order
2018-05-16 4:32 ` Viresh Kumar
@ 2018-05-16 19:24 ` Florian Fainelli
-1 siblings, 0 replies; 7+ messages in thread
From: Florian Fainelli @ 2018-05-16 19:24 UTC (permalink / raw)
To: Viresh Kumar, Markus Mayer
Cc: Rafael J. Wysocki, Brian Norris, Gregory Fong, Florian Fainelli,
Markus Mayer, Broadcom Kernel List, Power Management List,
ARM Kernel List, Linux Kernel Mailing List
On 05/15/2018 09:32 PM, Viresh Kumar wrote:
> On 15-05-18, 20:49, Markus Mayer wrote:
>> From: Markus Mayer <mmayer@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@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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order
@ 2018-05-16 19:24 ` Florian Fainelli
0 siblings, 0 replies; 7+ messages in thread
From: Florian Fainelli @ 2018-05-16 19:24 UTC (permalink / raw)
To: linux-arm-kernel
On 05/15/2018 09:32 PM, Viresh Kumar wrote:
> On 15-05-18, 20:49, Markus Mayer wrote:
>> From: Markus Mayer <mmayer@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@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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order
2018-05-16 19:24 ` Florian Fainelli
@ 2018-05-17 4:14 ` Viresh Kumar
-1 siblings, 0 replies; 7+ messages in thread
From: Viresh Kumar @ 2018-05-17 4:14 UTC (permalink / raw)
To: Florian Fainelli
Cc: Markus Mayer, Rafael J. Wysocki, Brian Norris, Gregory Fong,
Markus Mayer, Broadcom Kernel List, Power Management List,
ARM Kernel List, Linux Kernel Mailing List
On 16-05-18, 12:24, Florian Fainelli wrote:
> On 05/15/2018 09:32 PM, Viresh Kumar wrote:
> > On 15-05-18, 20:49, Markus Mayer wrote:
> >> From: Markus Mayer <mmayer@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?
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.
> > 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.
--
viresh
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order
@ 2018-05-17 4:14 ` Viresh Kumar
0 siblings, 0 replies; 7+ messages in thread
From: Viresh Kumar @ 2018-05-17 4:14 UTC (permalink / raw)
To: linux-arm-kernel
On 16-05-18, 12:24, Florian Fainelli wrote:
> On 05/15/2018 09:32 PM, Viresh Kumar wrote:
> > On 15-05-18, 20:49, Markus Mayer wrote:
> >> From: Markus Mayer <mmayer@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?
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.
> > 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.
--
viresh
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-05-17 4:14 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-16 3:49 [PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order Markus Mayer
2018-05-16 4:32 ` Viresh Kumar
2018-05-16 4:32 ` Viresh Kumar
2018-05-16 19:24 ` Florian Fainelli
2018-05-16 19:24 ` Florian Fainelli
2018-05-17 4:14 ` Viresh Kumar
2018-05-17 4:14 ` Viresh Kumar
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.