| Message ID | 1887364.fvxYYNb7Mm@amdc1227 (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
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,
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
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 ? -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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,
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); -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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,
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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,
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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); }