diff mbox

cpufreq: exynos: Broadcast frequency change notifications for all cores

Message ID 1887364.fvxYYNb7Mm@amdc1227 (mailing list archive)
State New, archived
Headers show

Commit Message

Tomasz Figa Nov. 13, 2012, 9:26 a.m. UTC
On Exynos SoCs all cores share the same frequency setting, so changing
frequency of one core will affect rest of cores.

This patch modifies the exynos-cpufreq driver to inform cpufreq core
about this behavior and broadcast frequency change notifications for all
cores.

Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 drivers/cpufreq/exynos-cpufreq.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

Comments

Tomasz Figa Nov. 21, 2012, 1:52 p.m. UTC | #1
On Tuesday 13 of November 2012 10:26:12 Tomasz Figa wrote:
> On Exynos SoCs all cores share the same frequency setting, so changing
> frequency of one core will affect rest of cores.
> 
> This patch modifies the exynos-cpufreq driver to inform cpufreq core
> about this behavior and broadcast frequency change notifications for all
> cores.
> 
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>  drivers/cpufreq/exynos-cpufreq.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/exynos-cpufreq.c
> b/drivers/cpufreq/exynos-cpufreq.c index af2d81e..c0d54a8 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -100,7 +100,8 @@ static int exynos_target(struct cpufreq_policy
> *policy, }
>  	arm_volt = volt_table[index];
> 
> -	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> +	for_each_cpu(freqs.cpu, policy->cpus)
> +		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> 
>  	/* When the new frequency is higher than current frequency */
>  	if ((freqs.new > freqs.old) && !safe_arm_volt) {
> @@ -115,7 +116,8 @@ static int exynos_target(struct cpufreq_policy
> *policy, if (freqs.new != freqs.old)
>  		exynos_info->set_freq(old_index, index);
> 
> -	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> +	for_each_cpu(freqs.cpu, policy->cpus)
> +		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> 
>  	/* When the new frequency is lower than current frequency */
>  	if ((freqs.new < freqs.old) ||
> @@ -235,6 +237,7 @@ static int exynos_cpufreq_cpu_init(struct
> cpufreq_policy *policy) cpumask_copy(policy->related_cpus,
> cpu_possible_mask);
>  		cpumask_copy(policy->cpus, cpu_online_mask);
>  	} else {
> +		policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
>  		cpumask_setall(policy->cpus);
>  	}

Ping.

Best regards,
Rafael Wysocki Nov. 21, 2012, 8:47 p.m. UTC | #2
On Wednesday, November 21, 2012 02:52:26 PM Tomasz Figa wrote:
> On Tuesday 13 of November 2012 10:26:12 Tomasz Figa wrote:
> > On Exynos SoCs all cores share the same frequency setting, so changing
> > frequency of one core will affect rest of cores.
> > 
> > This patch modifies the exynos-cpufreq driver to inform cpufreq core
> > about this behavior and broadcast frequency change notifications for all
> > cores.
> > 
> > Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> > ---
> >  drivers/cpufreq/exynos-cpufreq.c | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/exynos-cpufreq.c
> > b/drivers/cpufreq/exynos-cpufreq.c index af2d81e..c0d54a8 100644
> > --- a/drivers/cpufreq/exynos-cpufreq.c
> > +++ b/drivers/cpufreq/exynos-cpufreq.c
> > @@ -100,7 +100,8 @@ static int exynos_target(struct cpufreq_policy
> > *policy, }
> >  	arm_volt = volt_table[index];
> > 
> > -	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> > +	for_each_cpu(freqs.cpu, policy->cpus)
> > +		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> > 
> >  	/* When the new frequency is higher than current frequency */
> >  	if ((freqs.new > freqs.old) && !safe_arm_volt) {
> > @@ -115,7 +116,8 @@ static int exynos_target(struct cpufreq_policy
> > *policy, if (freqs.new != freqs.old)
> >  		exynos_info->set_freq(old_index, index);
> > 
> > -	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> > +	for_each_cpu(freqs.cpu, policy->cpus)
> > +		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> > 
> >  	/* When the new frequency is lower than current frequency */
> >  	if ((freqs.new < freqs.old) ||
> > @@ -235,6 +237,7 @@ static int exynos_cpufreq_cpu_init(struct
> > cpufreq_policy *policy) cpumask_copy(policy->related_cpus,
> > cpu_possible_mask);
> >  		cpumask_copy(policy->cpus, cpu_online_mask);
> >  	} else {
> > +		policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> >  		cpumask_setall(policy->cpus);
> >  	}
> 
> Ping.

Am I supposed to handle this?

Rafael
Tomasz Figa Nov. 21, 2012, 9:23 p.m. UTC | #3
Hi Rafael,

On Wednesday 21 of November 2012 21:47:42 Rafael J. Wysocki wrote:
> On Wednesday, November 21, 2012 02:52:26 PM Tomasz Figa wrote:
> > On Tuesday 13 of November 2012 10:26:12 Tomasz Figa wrote:
> > > On Exynos SoCs all cores share the same frequency setting, so
> > > changing
> > > frequency of one core will affect rest of cores.
> > > 
> > > This patch modifies the exynos-cpufreq driver to inform cpufreq core
> > > about this behavior and broadcast frequency change notifications for
> > > all cores.
> > > 
> > > Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> > > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> > > ---
> > > 
> > >  drivers/cpufreq/exynos-cpufreq.c | 7 +++++--
> > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/cpufreq/exynos-cpufreq.c
> > > b/drivers/cpufreq/exynos-cpufreq.c index af2d81e..c0d54a8 100644
> > > --- a/drivers/cpufreq/exynos-cpufreq.c
> > > +++ b/drivers/cpufreq/exynos-cpufreq.c
> > > @@ -100,7 +100,8 @@ static int exynos_target(struct cpufreq_policy
> > > *policy, }
> > > 
> > >  	arm_volt = volt_table[index];
> > > 
> > > -	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> > > +	for_each_cpu(freqs.cpu, policy->cpus)
> > > +		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> > > 
> > >  	/* When the new frequency is higher than current frequency */
> > >  	if ((freqs.new > freqs.old) && !safe_arm_volt) {
> > > 
> > > @@ -115,7 +116,8 @@ static int exynos_target(struct cpufreq_policy
> > > *policy, if (freqs.new != freqs.old)
> > > 
> > >  		exynos_info->set_freq(old_index, index);
> > > 
> > > -	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> > > +	for_each_cpu(freqs.cpu, policy->cpus)
> > > +		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> > > 
> > >  	/* When the new frequency is lower than current frequency */
> > >  	if ((freqs.new < freqs.old) ||
> > > 
> > > @@ -235,6 +237,7 @@ static int exynos_cpufreq_cpu_init(struct
> > > cpufreq_policy *policy) cpumask_copy(policy->related_cpus,
> > > cpu_possible_mask);
> > > 
> > >  		cpumask_copy(policy->cpus, cpu_online_mask);
> > >  	
> > >  	} else {
> > > 
> > > +		policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> > > 
> > >  		cpumask_setall(policy->cpus);
> > >  	
> > >  	}
> > 
> > Ping.
> 
> Am I supposed to handle this?

I guess. Would be really nice if you could apply this patch for 3.8.

Best regards,
Tomasz Figa
Rafael Wysocki Nov. 21, 2012, 11:41 p.m. UTC | #4
On Wednesday, November 21, 2012 10:23:02 PM Tomasz Figa wrote:
> Hi Rafael,
> 
> On Wednesday 21 of November 2012 21:47:42 Rafael J. Wysocki wrote:
> > On Wednesday, November 21, 2012 02:52:26 PM Tomasz Figa wrote:
> > > On Tuesday 13 of November 2012 10:26:12 Tomasz Figa wrote:
> > > > On Exynos SoCs all cores share the same frequency setting, so
> > > > changing
> > > > frequency of one core will affect rest of cores.
> > > > 
> > > > This patch modifies the exynos-cpufreq driver to inform cpufreq core
> > > > about this behavior and broadcast frequency change notifications for
> > > > all cores.
> > > > 
> > > > Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> > > > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> > > > ---
> > > > 
> > > >  drivers/cpufreq/exynos-cpufreq.c | 7 +++++--
> > > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/cpufreq/exynos-cpufreq.c
> > > > b/drivers/cpufreq/exynos-cpufreq.c index af2d81e..c0d54a8 100644
> > > > --- a/drivers/cpufreq/exynos-cpufreq.c
> > > > +++ b/drivers/cpufreq/exynos-cpufreq.c
> > > > @@ -100,7 +100,8 @@ static int exynos_target(struct cpufreq_policy
> > > > *policy, }
> > > > 
> > > >  	arm_volt = volt_table[index];
> > > > 
> > > > -	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> > > > +	for_each_cpu(freqs.cpu, policy->cpus)
> > > > +		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> > > > 
> > > >  	/* When the new frequency is higher than current frequency */
> > > >  	if ((freqs.new > freqs.old) && !safe_arm_volt) {
> > > > 
> > > > @@ -115,7 +116,8 @@ static int exynos_target(struct cpufreq_policy
> > > > *policy, if (freqs.new != freqs.old)
> > > > 
> > > >  		exynos_info->set_freq(old_index, index);
> > > > 
> > > > -	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> > > > +	for_each_cpu(freqs.cpu, policy->cpus)
> > > > +		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> > > > 
> > > >  	/* When the new frequency is lower than current frequency */
> > > >  	if ((freqs.new < freqs.old) ||
> > > > 
> > > > @@ -235,6 +237,7 @@ static int exynos_cpufreq_cpu_init(struct
> > > > cpufreq_policy *policy) cpumask_copy(policy->related_cpus,
> > > > cpu_possible_mask);
> > > > 
> > > >  		cpumask_copy(policy->cpus, cpu_online_mask);
> > > >  	
> > > >  	} else {
> > > > 
> > > > +		policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> > > > 
> > > >  		cpumask_setall(policy->cpus);
> > > >  	
> > > >  	}
> > > 
> > > Ping.
> > 
> > Am I supposed to handle this?
> 
> I guess. Would be really nice if you could apply this patch for 3.8.

OK

Applied to linux-pm.git/linux-next as v3.8 material.

Thanks,
Rafael
Viresh Kumar Jan. 31, 2013, 4:20 a.m. UTC | #5
On Tue, Nov 13, 2012 at 2:56 PM, Tomasz Figa <t.figa@samsung.com> wrote:
> On Exynos SoCs all cores share the same frequency setting, so changing
> frequency of one core will affect rest of cores.
>
> This patch modifies the exynos-cpufreq driver to inform cpufreq core
> about this behavior and broadcast frequency change notifications for all
> cores.

>         /* When the new frequency is lower than current frequency */
>         if ((freqs.new < freqs.old) ||
> @@ -235,6 +237,7 @@ static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
>                 cpumask_copy(policy->related_cpus, cpu_possible_mask);
>                 cpumask_copy(policy->cpus, cpu_online_mask);
>         } else {
> +               policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
>                 cpumask_setall(policy->cpus);

I couldn't understand the use of this change. Can you please explain ?
Tomasz Figa Jan. 31, 2013, 2:45 p.m. UTC | #6
Hi Viresh,

On Thursday 31 of January 2013 09:50:37 Viresh Kumar wrote:
> On Tue, Nov 13, 2012 at 2:56 PM, Tomasz Figa <t.figa@samsung.com> wrote:
> > On Exynos SoCs all cores share the same frequency setting, so changing
> > frequency of one core will affect rest of cores.
> > 
> > This patch modifies the exynos-cpufreq driver to inform cpufreq core
> > about this behavior and broadcast frequency change notifications for
> > all cores.
> > 
> >         /* When the new frequency is lower than current frequency */
> >         if ((freqs.new < freqs.old) ||
> > 
> > @@ -235,6 +237,7 @@ static int exynos_cpufreq_cpu_init(struct
> > cpufreq_policy *policy)> 
> >                 cpumask_copy(policy->related_cpus, cpu_possible_mask);
> >                 cpumask_copy(policy->cpus, cpu_online_mask);
> >         
> >         } else {
> > 
> > +               policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> > 
> >                 cpumask_setall(policy->cpus);
> 
> I couldn't understand the use of this change. Can you please explain ?

All cores on Exynos SoCs share the same clock source, which means that 
they all always run at the same frequency. So setting frequency on one 
core sets the frequency on all cores and so it doesn't matter on which 
core the frequency setting operation is done.

As you can see in include/linux/cpufreq.h:

#define CPUFREQ_SHARED_TYPE_ANY  (3) /* Freq can be set from any dependent 
CPU*/

which basically tells (together with rest of the patch) the cpufreq 
subsystem about what I wrote earlier.

Best regards,
Viresh Kumar Jan. 31, 2013, 2:52 p.m. UTC | #7
On 31 January 2013 20:15, Tomasz Figa <t.figa@samsung.com> wrote:
> On Thursday 31 of January 2013 09:50:37 Viresh Kumar wrote:
>> > +               policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;

>> I couldn't understand the use of this change. Can you please explain ?
>
> All cores on Exynos SoCs share the same clock source, which means that
> they all always run at the same frequency. So setting frequency on one
> core sets the frequency on all cores and so it doesn't matter on which
> core the frequency setting operation is done.

Great, that's like most other platforms and for this you just need to set mask
of all the possible cpus (online or offline) into policy->cpus

> As you can see in include/linux/cpufreq.h:
>
> #define CPUFREQ_SHARED_TYPE_ANY  (3) /* Freq can be set from any dependent
> CPU*/
>
> which basically tells (together with rest of the patch) the cpufreq
> subsystem about what I wrote earlier.

I don't think so. Because i wasn't using it on my system and it was
working well.
Then i grepped it in kernel source

viresh@blr-linut-001:$ git grep shared_type drivers/cpufreq/
drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type !=
CPUFREQ_SHARED_TYPE_ANY)
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type = perf->shared_type;
drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type ==
CPUFREQ_SHARED_TYPE_ALL ||
drivers/cpufreq/acpi-cpufreq.c:     policy->shared_type ==
CPUFREQ_SHARED_TYPE_ANY) {
drivers/cpufreq/acpi-cpufreq.c:         policy->shared_type =
CPUFREQ_SHARED_TYPE_ALL;
drivers/cpufreq/acpi-cpufreq.c:         policy->shared_type =
CPUFREQ_SHARED_TYPE_HW;
drivers/cpufreq/cpufreq-cpu0.c: policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
drivers/cpufreq/db8500-cpufreq.c:       policy->shared_type =
CPUFREQ_SHARED_TYPE_ALL;
drivers/cpufreq/omap-cpufreq.c:         policy->shared_type =
CPUFREQ_SHARED_TYPE_ANY;
drivers/cpufreq/speedstep-centrino.c:           if
(policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
drivers/cpufreq/speedstep-centrino.c:           if
(policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)

I couldn't see any core file using this stuff other than acpi-cpufreq.c,
which is for x86 only systems if i am not wrong.

@Rafael: You view on this.. ? Actually i believe it was just used by many
ARM drivers without knowing the real use of it and new drivers have just
followed it.

I can get a patch to fix it at all places if you agree.

BTW, grep in full kernel source gave, which is again acpi only:

viresh@blr-linut-001:$ git grep shared_type

arch/arm/mach-tegra/cpu-tegra.c:        policy->shared_type =
CPUFREQ_SHARED_TYPE_ALL;
drivers/acpi/processor_perflib.c:
pr->performance->shared_type = CPUFREQ_SHARED_TYPE_ALL;
drivers/acpi/processor_perflib.c:
pr->performance->shared_type = CPUFREQ_SHARED_TYPE_HW;
drivers/acpi/processor_perflib.c:
pr->performance->shared_type = CPUFREQ_SHARED_TYPE_ANY;
drivers/acpi/processor_perflib.c:
match_pr->performance->shared_type =
drivers/acpi/processor_perflib.c:
 pr->performance->shared_type;
drivers/acpi/processor_perflib.c:
pr->performance->shared_type = CPUFREQ_SHARED_TYPE_ALL;
drivers/acpi/processor_throttling.c:
pthrottling->shared_type = DOMAIN_COORD_TYPE_SW_ALL;
drivers/acpi/processor_throttling.c:    pthrottling->shared_type =
pdomain->coord_type;
drivers/acpi/processor_throttling.c:
pthrottling->shared_type = DOMAIN_COORD_TYPE_SW_ALL;
drivers/acpi/processor_throttling.c:    if (p_throttling->shared_type
== DOMAIN_COORD_TYPE_SW_ANY) {
drivers/acpi/processor_throttling.c:
pthrottling->shared_type = DOMAIN_COORD_TYPE_SW_ALL;
drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type !=
CPUFREQ_SHARED_TYPE_ANY)
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type = perf->shared_type;
drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type ==
CPUFREQ_SHARED_TYPE_ALL ||
drivers/cpufreq/acpi-cpufreq.c:     policy->shared_type ==
CPUFREQ_SHARED_TYPE_ANY) {
drivers/cpufreq/acpi-cpufreq.c:         policy->shared_type =
CPUFREQ_SHARED_TYPE_ALL;
drivers/cpufreq/acpi-cpufreq.c:         policy->shared_type =
CPUFREQ_SHARED_TYPE_HW;
drivers/cpufreq/cpufreq-cpu0.c: policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
drivers/cpufreq/db8500-cpufreq.c:       policy->shared_type =
CPUFREQ_SHARED_TYPE_ALL;
drivers/cpufreq/omap-cpufreq.c:         policy->shared_type =
CPUFREQ_SHARED_TYPE_ANY;
drivers/cpufreq/speedstep-centrino.c:           if
(policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
drivers/cpufreq/speedstep-centrino.c:           if
(policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c:
rtlpcipriv->bt_coexist.bt_radio_shared_type =
drivers/net/wireless/rtlwifi/rtl8723ae/hw.c:
pcipriv->bt_coexist.bt_radio_shared_type =
drivers/net/wireless/rtlwifi/rtl8723ae/hw.c:
pcipriv->bt_coexist.bt_radio_shared_type);
drivers/net/wireless/rtlwifi/wifi.h:    u8 bt_radio_shared_type;
drivers/xen/xen-acpi-processor.c:       dst->shared_type =
_pr->performance->shared_type;
drivers/xen/xen-acpi-processor.c:
dst->shared_type = CPUFREQ_SHARED_TYPE_ALL;
drivers/xen/xen-acpi-processor.c:
dst->shared_type = CPUFREQ_SHARED_TYPE_HW;
drivers/xen/xen-acpi-processor.c:
dst->shared_type = CPUFREQ_SHARED_TYPE_ANY;
include/acpi/processor.h:       unsigned int shared_type;
include/acpi/processor.h:       unsigned int shared_type;
include/linux/cpufreq.h:        unsigned int            shared_type;
/* ANY or ALL affected CPUs
include/xen/interface/platform.h:       uint32_t shared_type;     /*
coordination type of this processor */
tools/perf/util/dwarf-aux.c:             tag == DW_TAG_shared_type);
Tomasz Figa Jan. 31, 2013, 3:04 p.m. UTC | #8
On Thursday 31 of January 2013 20:22:50 Viresh Kumar wrote:
> On 31 January 2013 20:15, Tomasz Figa <t.figa@samsung.com> wrote:
> > On Thursday 31 of January 2013 09:50:37 Viresh Kumar wrote:
> >> > +               policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> >> 
> >> I couldn't understand the use of this change. Can you please explain
> >> ?
> > 
> > All cores on Exynos SoCs share the same clock source, which means that
> > they all always run at the same frequency. So setting frequency on one
> > core sets the frequency on all cores and so it doesn't matter on which
> > core the frequency setting operation is done.
> 
> Great, that's like most other platforms and for this you just need to
> set mask of all the possible cpus (online or offline) into policy->cpus
> > As you can see in include/linux/cpufreq.h:
> > 
> > #define CPUFREQ_SHARED_TYPE_ANY  (3) /* Freq can be set from any
> > dependent CPU*/
> > 
> > which basically tells (together with rest of the patch) the cpufreq
> > subsystem about what I wrote earlier.
> 
> I don't think so. Because i wasn't using it on my system and it was
> working well.
> Then i grepped it in kernel source
> 
> viresh@blr-linut-001:$ git grep shared_type drivers/cpufreq/
> drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type !=
> CPUFREQ_SHARED_TYPE_ANY)
> drivers/cpufreq/acpi-cpufreq.c: policy->shared_type = perf->shared_type;
> drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type ==
> CPUFREQ_SHARED_TYPE_ALL ||
> drivers/cpufreq/acpi-cpufreq.c:     policy->shared_type ==
> CPUFREQ_SHARED_TYPE_ANY) {
> drivers/cpufreq/acpi-cpufreq.c:         policy->shared_type =
> CPUFREQ_SHARED_TYPE_ALL;
> drivers/cpufreq/acpi-cpufreq.c:         policy->shared_type =
> CPUFREQ_SHARED_TYPE_HW;
> drivers/cpufreq/cpufreq-cpu0.c: policy->shared_type =
> CPUFREQ_SHARED_TYPE_ANY; drivers/cpufreq/db8500-cpufreq.c:      
> policy->shared_type =
> CPUFREQ_SHARED_TYPE_ALL;
> drivers/cpufreq/omap-cpufreq.c:         policy->shared_type =
> CPUFREQ_SHARED_TYPE_ANY;
> drivers/cpufreq/speedstep-centrino.c:           if
> (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
> drivers/cpufreq/speedstep-centrino.c:           if
> (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
> 
> I couldn't see any core file using this stuff other than acpi-cpufreq.c,
> which is for x86 only systems if i am not wrong.
> 
> @Rafael: You view on this.. ? Actually i believe it was just used by
> many ARM drivers without knowing the real use of it and new drivers
> have just followed it.
> 
> I can get a patch to fix it at all places if you agree.
> 
> BTW, grep in full kernel source gave, which is again acpi only:
> 
> viresh@blr-linut-001:$ git grep shared_type
> 
> arch/arm/mach-tegra/cpu-tegra.c:        policy->shared_type =
> CPUFREQ_SHARED_TYPE_ALL;
> drivers/acpi/processor_perflib.c:
> pr->performance->shared_type = CPUFREQ_SHARED_TYPE_ALL;
> drivers/acpi/processor_perflib.c:
> pr->performance->shared_type = CPUFREQ_SHARED_TYPE_HW;
> drivers/acpi/processor_perflib.c:
> pr->performance->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> drivers/acpi/processor_perflib.c:
> match_pr->performance->shared_type =
> drivers/acpi/processor_perflib.c:
>  pr->performance->shared_type;
> drivers/acpi/processor_perflib.c:
> pr->performance->shared_type = CPUFREQ_SHARED_TYPE_ALL;
> drivers/acpi/processor_throttling.c:
> pthrottling->shared_type = DOMAIN_COORD_TYPE_SW_ALL;
> drivers/acpi/processor_throttling.c:    pthrottling->shared_type =
> pdomain->coord_type;
> drivers/acpi/processor_throttling.c:
> pthrottling->shared_type = DOMAIN_COORD_TYPE_SW_ALL;
> drivers/acpi/processor_throttling.c:    if (p_throttling->shared_type
> == DOMAIN_COORD_TYPE_SW_ANY) {
> drivers/acpi/processor_throttling.c:
> pthrottling->shared_type = DOMAIN_COORD_TYPE_SW_ALL;
> drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type !=
> CPUFREQ_SHARED_TYPE_ANY)
> drivers/cpufreq/acpi-cpufreq.c: policy->shared_type = perf->shared_type;
> drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type ==
> CPUFREQ_SHARED_TYPE_ALL ||
> drivers/cpufreq/acpi-cpufreq.c:     policy->shared_type ==
> CPUFREQ_SHARED_TYPE_ANY) {
> drivers/cpufreq/acpi-cpufreq.c:         policy->shared_type =
> CPUFREQ_SHARED_TYPE_ALL;
> drivers/cpufreq/acpi-cpufreq.c:         policy->shared_type =
> CPUFREQ_SHARED_TYPE_HW;
> drivers/cpufreq/cpufreq-cpu0.c: policy->shared_type =
> CPUFREQ_SHARED_TYPE_ANY; drivers/cpufreq/db8500-cpufreq.c:      
> policy->shared_type =
> CPUFREQ_SHARED_TYPE_ALL;
> drivers/cpufreq/omap-cpufreq.c:         policy->shared_type =
> CPUFREQ_SHARED_TYPE_ANY;
> drivers/cpufreq/speedstep-centrino.c:           if
> (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
> drivers/cpufreq/speedstep-centrino.c:           if
> (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
> drivers/net/wireless/rtlwifi/rtl8192ce/hw.c:
> rtlpcipriv->bt_coexist.bt_radio_shared_type =
> drivers/net/wireless/rtlwifi/rtl8723ae/hw.c:
> pcipriv->bt_coexist.bt_radio_shared_type =
> drivers/net/wireless/rtlwifi/rtl8723ae/hw.c:
> pcipriv->bt_coexist.bt_radio_shared_type);
> drivers/net/wireless/rtlwifi/wifi.h:    u8 bt_radio_shared_type;
> drivers/xen/xen-acpi-processor.c:       dst->shared_type =
> _pr->performance->shared_type;
> drivers/xen/xen-acpi-processor.c:
> dst->shared_type = CPUFREQ_SHARED_TYPE_ALL;
> drivers/xen/xen-acpi-processor.c:
> dst->shared_type = CPUFREQ_SHARED_TYPE_HW;
> drivers/xen/xen-acpi-processor.c:
> dst->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> include/acpi/processor.h:       unsigned int shared_type;
> include/acpi/processor.h:       unsigned int shared_type;
> include/linux/cpufreq.h:        unsigned int            shared_type;
> /* ANY or ALL affected CPUs
> include/xen/interface/platform.h:       uint32_t shared_type;     /*
> coordination type of this processor */
> tools/perf/util/dwarf-aux.c:             tag == DW_TAG_shared_type);

Well, the fact that it isn't used at the moment doesn't mean that it 
shouldn't be set correctly. The field is present in the structure and has 
a set of defined values - one of which should be selected. For example,
I can imagine some governor taking this information into account.

Best regards,
Viresh Kumar Jan. 31, 2013, 3:16 p.m. UTC | #9
On 31 January 2013 20:34, Tomasz Figa <t.figa@samsung.com> wrote:
> Well, the fact that it isn't used at the moment doesn't mean that it
> shouldn't be set correctly. The field is present in the structure and has
> a set of defined values - one of which should be selected. For example,
> I can imagine some governor taking this information into account.

Governors already take this information but from a different variable:
policy->cpus.

Look at the patch which added it:

commit 3b2d99429e3386b6e2ac949fc72486509c8bbe36
Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Date:   Wed Dec 14 15:05:00 2005 -0500

    P-state software coordination for ACPI core

    http://bugzilla.kernel.org/show_bug.cgi?id=5737

    Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/acpi/processor_perflib.c | 228
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/acpi/processor.h         |  27 ++++++++++++-
 include/linux/cpufreq.h          |   4 ++
 3 files changed, 258 insertions(+), 1 deletion(-)


It was clearly for ACPI, but was probably named badly and we people
got confused that it is for our use.

--
viresh
Tomasz Figa Jan. 31, 2013, 4:07 p.m. UTC | #10
On Thursday 31 of January 2013 20:46:10 Viresh Kumar wrote:
> On 31 January 2013 20:34, Tomasz Figa <t.figa@samsung.com> wrote:
> > Well, the fact that it isn't used at the moment doesn't mean that it
> > shouldn't be set correctly. The field is present in the structure and
> > has a set of defined values - one of which should be selected. For
> > example, I can imagine some governor taking this information into
> > account.
> Governors already take this information but from a different variable:
> policy->cpus.
> 
> Look at the patch which added it:
> 
> commit 3b2d99429e3386b6e2ac949fc72486509c8bbe36
> Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
> Date:   Wed Dec 14 15:05:00 2005 -0500
> 
>     P-state software coordination for ACPI core
> 
>     http://bugzilla.kernel.org/show_bug.cgi?id=5737
> 
>     Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
>     Signed-off-by: Len Brown <len.brown@intel.com>
> ---
>  drivers/acpi/processor_perflib.c | 228
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++++++++++++++++++++++++++++++++++++ include/acpi/processor.h         |
>  27 ++++++++++++-
>  include/linux/cpufreq.h          |   4 ++
>  3 files changed, 258 insertions(+), 1 deletion(-)
> 
> 
> It was clearly for ACPI, but was probably named badly and we people
> got confused that it is for our use.

Hmm. Now as I think of it, there might be another confusing aspect:

Could you explain what "sw coordination" and "any coordination" mean?
I mean specifically cpufreq_policy.cpus and cpufreq_policy.related_cpus 
masks.

Best regards,
Viresh Kumar Jan. 31, 2013, 4:12 p.m. UTC | #11
On 31 January 2013 21:37, Tomasz Figa <t.figa@samsung.com> wrote:
> Hmm. Now as I think of it, there might be another confusing aspect:
>
> Could you explain what "sw coordination" and "any coordination" mean?
> I mean specifically cpufreq_policy.cpus and cpufreq_policy.related_cpus
> masks.

Check this out:

https://lkml.org/lkml/2013/1/30/587
Viresh Kumar Feb. 1, 2013, 3:47 a.m. UTC | #12
On 31 January 2013 21:42, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 31 January 2013 21:37, Tomasz Figa <t.figa@samsung.com> wrote:
>> Hmm. Now as I think of it, there might be another confusing aspect:
>>
>> Could you explain what "sw coordination" and "any coordination" mean?
>> I mean specifically cpufreq_policy.cpus and cpufreq_policy.related_cpus
>> masks.
>
> Check this out:
>
> https://lkml.org/lkml/2013/1/30/587

You would really like to look and ack this one too:

https://lkml.org/lkml/2013/1/30/592
diff mbox

Patch

diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index af2d81e..c0d54a8 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -100,7 +100,8 @@  static int exynos_target(struct cpufreq_policy *policy,
 	}
 	arm_volt = volt_table[index];
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+	for_each_cpu(freqs.cpu, policy->cpus)
+		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
 
 	/* When the new frequency is higher than current frequency */
 	if ((freqs.new > freqs.old) && !safe_arm_volt) {
@@ -115,7 +116,8 @@  static int exynos_target(struct cpufreq_policy *policy,
 	if (freqs.new != freqs.old)
 		exynos_info->set_freq(old_index, index);
 
-	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+	for_each_cpu(freqs.cpu, policy->cpus)
+		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
 
 	/* When the new frequency is lower than current frequency */
 	if ((freqs.new < freqs.old) ||
@@ -235,6 +237,7 @@  static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
 		cpumask_copy(policy->related_cpus, cpu_possible_mask);
 		cpumask_copy(policy->cpus, cpu_online_mask);
 	} else {
+		policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
 		cpumask_setall(policy->cpus);
 	}