* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
@ 2012-11-13 9:26 Tomasz Figa
2012-11-21 13:52 ` Tomasz Figa
2013-01-31 4:20 ` Viresh Kumar
0 siblings, 2 replies; 13+ messages in thread
From: Tomasz Figa @ 2012-11-13 9:26 UTC (permalink / raw)
To: linux-arm-kernel
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);
}
--
1.8.0
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
2012-11-13 9:26 [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores Tomasz Figa
@ 2012-11-21 13:52 ` Tomasz Figa
2012-11-21 20:47 ` Rafael J. Wysocki
2013-01-31 4:20 ` Viresh Kumar
1 sibling, 1 reply; 13+ messages in thread
From: Tomasz Figa @ 2012-11-21 13:52 UTC (permalink / raw)
To: linux-arm-kernel
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,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
2012-11-21 13:52 ` Tomasz Figa
@ 2012-11-21 20:47 ` Rafael J. Wysocki
2012-11-21 21:23 ` Tomasz Figa
0 siblings, 1 reply; 13+ messages in thread
From: Rafael J. Wysocki @ 2012-11-21 20:47 UTC (permalink / raw)
To: linux-arm-kernel
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
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
2012-11-21 20:47 ` Rafael J. Wysocki
@ 2012-11-21 21:23 ` Tomasz Figa
2012-11-21 23:41 ` Rafael J. Wysocki
0 siblings, 1 reply; 13+ messages in thread
From: Tomasz Figa @ 2012-11-21 21:23 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
2012-11-21 21:23 ` Tomasz Figa
@ 2012-11-21 23:41 ` Rafael J. Wysocki
0 siblings, 0 replies; 13+ messages in thread
From: Rafael J. Wysocki @ 2012-11-21 23:41 UTC (permalink / raw)
To: linux-arm-kernel
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
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
2012-11-13 9:26 [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores Tomasz Figa
2012-11-21 13:52 ` Tomasz Figa
@ 2013-01-31 4:20 ` Viresh Kumar
2013-01-31 14:45 ` Tomasz Figa
1 sibling, 1 reply; 13+ messages in thread
From: Viresh Kumar @ 2013-01-31 4:20 UTC (permalink / raw)
To: linux-arm-kernel
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 ?
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
2013-01-31 4:20 ` Viresh Kumar
@ 2013-01-31 14:45 ` Tomasz Figa
2013-01-31 14:52 ` Viresh Kumar
0 siblings, 1 reply; 13+ messages in thread
From: Tomasz Figa @ 2013-01-31 14:45 UTC (permalink / raw)
To: linux-arm-kernel
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,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
2013-01-31 14:45 ` Tomasz Figa
@ 2013-01-31 14:52 ` Viresh Kumar
2013-01-31 15:04 ` Tomasz Figa
0 siblings, 1 reply; 13+ messages in thread
From: Viresh Kumar @ 2013-01-31 14:52 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 at 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);
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
2013-01-31 14:52 ` Viresh Kumar
@ 2013-01-31 15:04 ` Tomasz Figa
2013-01-31 15:16 ` Viresh Kumar
0 siblings, 1 reply; 13+ messages in thread
From: Tomasz Figa @ 2013-01-31 15:04 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 at 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,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
2013-01-31 15:04 ` Tomasz Figa
@ 2013-01-31 15:16 ` Viresh Kumar
2013-01-31 16:07 ` Tomasz Figa
0 siblings, 1 reply; 13+ messages in thread
From: Viresh Kumar @ 2013-01-31 15:16 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
2013-01-31 15:16 ` Viresh Kumar
@ 2013-01-31 16:07 ` Tomasz Figa
2013-01-31 16:12 ` Viresh Kumar
0 siblings, 1 reply; 13+ messages in thread
From: Tomasz Figa @ 2013-01-31 16:07 UTC (permalink / raw)
To: linux-arm-kernel
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,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-02-01 3:47 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-13 9:26 [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores Tomasz Figa
2012-11-21 13:52 ` Tomasz Figa
2012-11-21 20:47 ` Rafael J. Wysocki
2012-11-21 21:23 ` Tomasz Figa
2012-11-21 23:41 ` Rafael J. Wysocki
2013-01-31 4:20 ` Viresh Kumar
2013-01-31 14:45 ` Tomasz Figa
2013-01-31 14:52 ` Viresh Kumar
2013-01-31 15:04 ` Tomasz Figa
2013-01-31 15:16 ` Viresh Kumar
2013-01-31 16:07 ` Tomasz Figa
2013-01-31 16:12 ` Viresh Kumar
2013-02-01 3:47 ` Viresh Kumar
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).