* Re: linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ]
@ 2013-02-08 8:46 Sedat Dilek
2013-02-08 11:53 ` Hillf Danton
0 siblings, 1 reply; 15+ messages in thread
From: Sedat Dilek @ 2013-02-08 8:46 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Rafael J. Wysocki, Linux ACPI,
Linux PM List, x86, Ingo Molnar, Thomas Gleixner
On Fri, Feb 8, 2013 at 5:31 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Changes since 20130207:
>
> The sound-asoc tree gained a build failure so I used the version from
> next-20130207.
>
> The watchdog tree gained a conflict against the mfd tree.
>
> I applied a patch to restore some config defaults on PPC64.
>
> ----------------------------------------------------------------------------
>
With today's Linux-Next I see this warning:
[ 0.377442] ------------[ cut here ]------------
[ 0.377452] WARNING: at kernel/smp.c:245
smp_call_function_single+0x146/0x190()
[ 0.377455] Hardware name: 530U3BI/530U4BI/530U4BH
[ 0.377458] Modules linked in:
[ 0.377463] Pid: 1, comm: swapper/0 Not tainted
3.8.0-rc6-next20130208-1-iniza-small #1
[ 0.377467] Call Trace:
[ 0.377473] [<ffffffff8105a5ef>] warn_slowpath_common+0x7f/0xc0
[ 0.377479] [<ffffffff81579130>] ? acpi_cpufreq_target+0x2c0/0x2c0
[ 0.377483] [<ffffffff8105a64a>] warn_slowpath_null+0x1a/0x20
[ 0.377487] [<ffffffff810bb7e6>] smp_call_function_single+0x146/0x190
[ 0.377492] [<ffffffff81579130>] ? acpi_cpufreq_target+0x2c0/0x2c0
[ 0.377496] [<ffffffff810bb881>] smp_call_function_any+0x51/0x100
[ 0.377500] [<ffffffff815788c9>] get_cur_val+0x99/0x130
[ 0.377504] [<ffffffff81579444>] ? acpi_cpufreq_cpu_init+0x2b4/0x6a0
[ 0.377508] [<ffffffff81578db0>] get_cur_freq_on_cpu+0x60/0x80
[ 0.377512] [<ffffffff815795a2>] acpi_cpufreq_cpu_init+0x412/0x6a0
[ 0.377517] [<ffffffff81575bb9>] cpufreq_add_dev+0x2d9/0x4f0
[ 0.377523] [<ffffffff81d44b22>] ? cpufreq_gov_dbs_init+0x2c/0x2c
[ 0.377528] [<ffffffff8145d379>] subsys_interface_register+0x89/0xd0
[ 0.377533] [<ffffffff81573dee>] cpufreq_register_driver+0x8e/0x180
[ 0.377537] [<ffffffff81d44c18>] acpi_cpufreq_init+0xf6/0x1f8
[ 0.377542] [<ffffffff814608e6>] ? platform_driver_register+0x46/0x50
[ 0.377547] [<ffffffff8100206f>] do_one_initcall+0x3f/0x170
[ 0.377553] [<ffffffff81d07029>] kernel_init_freeable+0x13e/0x1cd
[ 0.377560] [<ffffffff81d06895>] ? do_early_param+0x86/0x86
[ 0.377565] [<ffffffff8169cf20>] ? rest_init+0x80/0x80
[ 0.377569] [<ffffffff8169cf2e>] kernel_init+0xe/0xf0
[ 0.377575] [<ffffffff816c722c>] ret_from_fork+0x7c/0xb0
[ 0.377578] [<ffffffff8169cf20>] ? rest_init+0x80/0x80
[ 0.377581] ---[ end trace c6ec8280ce20313a ]---
kernel/smp.c: Line #245 see [1].
- Sedat -
[1] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=kernel/smp.c;hb=refs/tags/next-20130208#l245
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ] 2013-02-08 8:46 linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ] Sedat Dilek @ 2013-02-08 11:53 ` Hillf Danton 2013-02-08 12:47 ` Sedat Dilek 0 siblings, 1 reply; 15+ messages in thread From: Hillf Danton @ 2013-02-08 11:53 UTC (permalink / raw) To: sedat.dilek Cc: Stephen Rothwell, linux-next, linux-kernel, Rafael J. Wysocki, Linux ACPI, Linux PM List, x86, Ingo Molnar Hello Sedat On Fri, Feb 8, 2013 at 4:46 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: > On Fri, Feb 8, 2013 at 5:31 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > With today's Linux-Next I see this warning: > > [ 0.377442] ------------[ cut here ]------------ > [ 0.377452] WARNING: at kernel/smp.c:245 > smp_call_function_single+0x146/0x190() > [ 0.377455] Hardware name: 530U3BI/530U4BI/530U4BH > [ 0.377458] Modules linked in: > [ 0.377463] Pid: 1, comm: swapper/0 Not tainted > 3.8.0-rc6-next20130208-1-iniza-small #1 > [ 0.377467] Call Trace: > [ 0.377473] [<ffffffff8105a5ef>] warn_slowpath_common+0x7f/0xc0 > [ 0.377479] [<ffffffff81579130>] ? acpi_cpufreq_target+0x2c0/0x2c0 > [ 0.377483] [<ffffffff8105a64a>] warn_slowpath_null+0x1a/0x20 > [ 0.377487] [<ffffffff810bb7e6>] smp_call_function_single+0x146/0x190 > [ 0.377492] [<ffffffff81579130>] ? acpi_cpufreq_target+0x2c0/0x2c0 > [ 0.377496] [<ffffffff810bb881>] smp_call_function_any+0x51/0x100 > [ 0.377500] [<ffffffff815788c9>] get_cur_val+0x99/0x130 > [ 0.377504] [<ffffffff81579444>] ? acpi_cpufreq_cpu_init+0x2b4/0x6a0 > [ 0.377508] [<ffffffff81578db0>] get_cur_freq_on_cpu+0x60/0x80 > [ 0.377512] [<ffffffff815795a2>] acpi_cpufreq_cpu_init+0x412/0x6a0 > [ 0.377517] [<ffffffff81575bb9>] cpufreq_add_dev+0x2d9/0x4f0 > [ 0.377523] [<ffffffff81d44b22>] ? cpufreq_gov_dbs_init+0x2c/0x2c > [ 0.377528] [<ffffffff8145d379>] subsys_interface_register+0x89/0xd0 > [ 0.377533] [<ffffffff81573dee>] cpufreq_register_driver+0x8e/0x180 > [ 0.377537] [<ffffffff81d44c18>] acpi_cpufreq_init+0xf6/0x1f8 > [ 0.377542] [<ffffffff814608e6>] ? platform_driver_register+0x46/0x50 > [ 0.377547] [<ffffffff8100206f>] do_one_initcall+0x3f/0x170 > [ 0.377553] [<ffffffff81d07029>] kernel_init_freeable+0x13e/0x1cd > [ 0.377560] [<ffffffff81d06895>] ? do_early_param+0x86/0x86 > [ 0.377565] [<ffffffff8169cf20>] ? rest_init+0x80/0x80 > [ 0.377569] [<ffffffff8169cf2e>] kernel_init+0xe/0xf0 > [ 0.377575] [<ffffffff816c722c>] ret_from_fork+0x7c/0xb0 > [ 0.377578] [<ffffffff8169cf20>] ? rest_init+0x80/0x80 > [ 0.377581] ---[ end trace c6ec8280ce20313a ]--- > > kernel/smp.c: Line #245 see [1]. > Can you please try the following? --- a/kernel/smp.c Fri Feb 8 19:25:32 2013 +++ b/kernel/smp.c Fri Feb 8 19:53:14 2013 @@ -241,7 +241,7 @@ int smp_call_function_single(int cpu, sm * send smp call function interrupt to this cpu and as such deadlocks * can't happen. */ - WARN_ON_ONCE(cpu_online(this_cpu) && (irqs_disabled() || in_interrupt()) + WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled() && !oops_in_progress); if (cpu == this_cpu) { -- ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ] 2013-02-08 11:53 ` Hillf Danton @ 2013-02-08 12:47 ` Sedat Dilek 2013-02-08 13:21 ` Rafael J. Wysocki 0 siblings, 1 reply; 15+ messages in thread From: Sedat Dilek @ 2013-02-08 12:47 UTC (permalink / raw) To: Hillf Danton Cc: Stephen Rothwell, linux-next, linux-kernel, Rafael J. Wysocki, Linux ACPI, Linux PM List, x86, Ingo Molnar, Chuansheng Liu On Fri, Feb 8, 2013 at 12:53 PM, Hillf Danton <dhillf@gmail.com> wrote: > Hello Sedat > > On Fri, Feb 8, 2013 at 4:46 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >> On Fri, Feb 8, 2013 at 5:31 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: >> With today's Linux-Next I see this warning: >> >> [ 0.377442] ------------[ cut here ]------------ >> [ 0.377452] WARNING: at kernel/smp.c:245 >> smp_call_function_single+0x146/0x190() >> [ 0.377455] Hardware name: 530U3BI/530U4BI/530U4BH >> [ 0.377458] Modules linked in: >> [ 0.377463] Pid: 1, comm: swapper/0 Not tainted >> 3.8.0-rc6-next20130208-1-iniza-small #1 >> [ 0.377467] Call Trace: >> [ 0.377473] [<ffffffff8105a5ef>] warn_slowpath_common+0x7f/0xc0 >> [ 0.377479] [<ffffffff81579130>] ? acpi_cpufreq_target+0x2c0/0x2c0 >> [ 0.377483] [<ffffffff8105a64a>] warn_slowpath_null+0x1a/0x20 >> [ 0.377487] [<ffffffff810bb7e6>] smp_call_function_single+0x146/0x190 >> [ 0.377492] [<ffffffff81579130>] ? acpi_cpufreq_target+0x2c0/0x2c0 >> [ 0.377496] [<ffffffff810bb881>] smp_call_function_any+0x51/0x100 >> [ 0.377500] [<ffffffff815788c9>] get_cur_val+0x99/0x130 >> [ 0.377504] [<ffffffff81579444>] ? acpi_cpufreq_cpu_init+0x2b4/0x6a0 >> [ 0.377508] [<ffffffff81578db0>] get_cur_freq_on_cpu+0x60/0x80 >> [ 0.377512] [<ffffffff815795a2>] acpi_cpufreq_cpu_init+0x412/0x6a0 >> [ 0.377517] [<ffffffff81575bb9>] cpufreq_add_dev+0x2d9/0x4f0 >> [ 0.377523] [<ffffffff81d44b22>] ? cpufreq_gov_dbs_init+0x2c/0x2c >> [ 0.377528] [<ffffffff8145d379>] subsys_interface_register+0x89/0xd0 >> [ 0.377533] [<ffffffff81573dee>] cpufreq_register_driver+0x8e/0x180 >> [ 0.377537] [<ffffffff81d44c18>] acpi_cpufreq_init+0xf6/0x1f8 >> [ 0.377542] [<ffffffff814608e6>] ? platform_driver_register+0x46/0x50 >> [ 0.377547] [<ffffffff8100206f>] do_one_initcall+0x3f/0x170 >> [ 0.377553] [<ffffffff81d07029>] kernel_init_freeable+0x13e/0x1cd >> [ 0.377560] [<ffffffff81d06895>] ? do_early_param+0x86/0x86 >> [ 0.377565] [<ffffffff8169cf20>] ? rest_init+0x80/0x80 >> [ 0.377569] [<ffffffff8169cf2e>] kernel_init+0xe/0xf0 >> [ 0.377575] [<ffffffff816c722c>] ret_from_fork+0x7c/0xb0 >> [ 0.377578] [<ffffffff8169cf20>] ? rest_init+0x80/0x80 >> [ 0.377581] ---[ end trace c6ec8280ce20313a ]--- >> >> kernel/smp.c: Line #245 see [1]. >> > Can you please try the following? > > --- a/kernel/smp.c Fri Feb 8 19:25:32 2013 > +++ b/kernel/smp.c Fri Feb 8 19:53:14 2013 > @@ -241,7 +241,7 @@ int smp_call_function_single(int cpu, sm > * send smp call function interrupt to this cpu and as such deadlocks > * can't happen. > */ > - WARN_ON_ONCE(cpu_online(this_cpu) && (irqs_disabled() || in_interrupt()) > + WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled() > && !oops_in_progress); > > if (cpu == this_cpu) { > -- NO, it doesn't. So, you want to partly revert... commit b29f39c7c3e75a741a7da88244ec707f293ec04c "smp: Give WARN()ing if in_interrupt() when calling smp_call_function_many()/single()" ...why not completely? This patch was in last days Linux-Next and did not cause troubles (AFAICS). - Sedat - [1] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=b29f39c7c3e75a741a7da88244ec707f293ec04c ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ] 2013-02-08 12:47 ` Sedat Dilek @ 2013-02-08 13:21 ` Rafael J. Wysocki 2013-02-08 13:58 ` Ingo Molnar ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Rafael J. Wysocki @ 2013-02-08 13:21 UTC (permalink / raw) To: sedat.dilek Cc: Hillf Danton, Stephen Rothwell, linux-next, linux-kernel, Linux ACPI, Linux PM List, x86, Ingo Molnar, Chuansheng Liu On Friday, February 08, 2013 01:47:44 PM Sedat Dilek wrote: > On Fri, Feb 8, 2013 at 12:53 PM, Hillf Danton <dhillf@gmail.com> wrote: > > Hello Sedat > > > > On Fri, Feb 8, 2013 at 4:46 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: > >> On Fri, Feb 8, 2013 at 5:31 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > >> With today's Linux-Next I see this warning: > >> > >> [ 0.377442] ------------[ cut here ]------------ > >> [ 0.377452] WARNING: at kernel/smp.c:245 > >> smp_call_function_single+0x146/0x190() > >> [ 0.377455] Hardware name: 530U3BI/530U4BI/530U4BH > >> [ 0.377458] Modules linked in: > >> [ 0.377463] Pid: 1, comm: swapper/0 Not tainted > >> 3.8.0-rc6-next20130208-1-iniza-small #1 > >> [ 0.377467] Call Trace: > >> [ 0.377473] [<ffffffff8105a5ef>] warn_slowpath_common+0x7f/0xc0 > >> [ 0.377479] [<ffffffff81579130>] ? acpi_cpufreq_target+0x2c0/0x2c0 > >> [ 0.377483] [<ffffffff8105a64a>] warn_slowpath_null+0x1a/0x20 > >> [ 0.377487] [<ffffffff810bb7e6>] smp_call_function_single+0x146/0x190 > >> [ 0.377492] [<ffffffff81579130>] ? acpi_cpufreq_target+0x2c0/0x2c0 > >> [ 0.377496] [<ffffffff810bb881>] smp_call_function_any+0x51/0x100 > >> [ 0.377500] [<ffffffff815788c9>] get_cur_val+0x99/0x130 > >> [ 0.377504] [<ffffffff81579444>] ? acpi_cpufreq_cpu_init+0x2b4/0x6a0 > >> [ 0.377508] [<ffffffff81578db0>] get_cur_freq_on_cpu+0x60/0x80 > >> [ 0.377512] [<ffffffff815795a2>] acpi_cpufreq_cpu_init+0x412/0x6a0 > >> [ 0.377517] [<ffffffff81575bb9>] cpufreq_add_dev+0x2d9/0x4f0 > >> [ 0.377523] [<ffffffff81d44b22>] ? cpufreq_gov_dbs_init+0x2c/0x2c > >> [ 0.377528] [<ffffffff8145d379>] subsys_interface_register+0x89/0xd0 > >> [ 0.377533] [<ffffffff81573dee>] cpufreq_register_driver+0x8e/0x180 > >> [ 0.377537] [<ffffffff81d44c18>] acpi_cpufreq_init+0xf6/0x1f8 > >> [ 0.377542] [<ffffffff814608e6>] ? platform_driver_register+0x46/0x50 > >> [ 0.377547] [<ffffffff8100206f>] do_one_initcall+0x3f/0x170 > >> [ 0.377553] [<ffffffff81d07029>] kernel_init_freeable+0x13e/0x1cd > >> [ 0.377560] [<ffffffff81d06895>] ? do_early_param+0x86/0x86 > >> [ 0.377565] [<ffffffff8169cf20>] ? rest_init+0x80/0x80 > >> [ 0.377569] [<ffffffff8169cf2e>] kernel_init+0xe/0xf0 > >> [ 0.377575] [<ffffffff816c722c>] ret_from_fork+0x7c/0xb0 > >> [ 0.377578] [<ffffffff8169cf20>] ? rest_init+0x80/0x80 > >> [ 0.377581] ---[ end trace c6ec8280ce20313a ]--- > >> > >> kernel/smp.c: Line #245 see [1]. > >> > > Can you please try the following? > > > > --- a/kernel/smp.c Fri Feb 8 19:25:32 2013 > > +++ b/kernel/smp.c Fri Feb 8 19:53:14 2013 > > @@ -241,7 +241,7 @@ int smp_call_function_single(int cpu, sm > > * send smp call function interrupt to this cpu and as such deadlocks > > * can't happen. > > */ > > - WARN_ON_ONCE(cpu_online(this_cpu) && (irqs_disabled() || in_interrupt()) > > + WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled() > > && !oops_in_progress); > > > > if (cpu == this_cpu) { > > -- > > NO, it doesn't. > > So, you want to partly revert... > > commit b29f39c7c3e75a741a7da88244ec707f293ec04c > "smp: Give WARN()ing if in_interrupt() when calling > smp_call_function_many()/single()" > > ...why not completely? > > This patch was in last days Linux-Next and did not cause troubles (AFAICS). This problem was introduced by some cpufreq changes that have been dropped from linux-next for now (they are still present in the one you're testing, though). Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ] 2013-02-08 13:21 ` Rafael J. Wysocki @ 2013-02-08 13:58 ` Ingo Molnar 2013-02-08 14:15 ` Sedat Dilek 2013-02-08 14:45 ` [linux-pm] " Viresh Kumar 2 siblings, 0 replies; 15+ messages in thread From: Ingo Molnar @ 2013-02-08 13:58 UTC (permalink / raw) To: Rafael J. Wysocki Cc: sedat.dilek, Hillf Danton, Stephen Rothwell, linux-next, linux-kernel, Linux ACPI, Linux PM List, x86, Ingo Molnar, Chuansheng Liu * Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Friday, February 08, 2013 01:47:44 PM Sedat Dilek wrote: > > On Fri, Feb 8, 2013 at 12:53 PM, Hillf Danton <dhillf@gmail.com> wrote: > > > Hello Sedat > > > > > > On Fri, Feb 8, 2013 at 4:46 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: > > >> On Fri, Feb 8, 2013 at 5:31 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > >> With today's Linux-Next I see this warning: > > >> > > >> [ 0.377442] ------------[ cut here ]------------ > > >> [ 0.377452] WARNING: at kernel/smp.c:245 > > >> smp_call_function_single+0x146/0x190() > > >> [ 0.377455] Hardware name: 530U3BI/530U4BI/530U4BH > > >> [ 0.377458] Modules linked in: > > >> [ 0.377463] Pid: 1, comm: swapper/0 Not tainted > > >> 3.8.0-rc6-next20130208-1-iniza-small #1 > > >> [ 0.377467] Call Trace: > > >> [ 0.377473] [<ffffffff8105a5ef>] warn_slowpath_common+0x7f/0xc0 > > >> [ 0.377479] [<ffffffff81579130>] ? acpi_cpufreq_target+0x2c0/0x2c0 > > >> [ 0.377483] [<ffffffff8105a64a>] warn_slowpath_null+0x1a/0x20 > > >> [ 0.377487] [<ffffffff810bb7e6>] smp_call_function_single+0x146/0x190 > > >> [ 0.377492] [<ffffffff81579130>] ? acpi_cpufreq_target+0x2c0/0x2c0 > > >> [ 0.377496] [<ffffffff810bb881>] smp_call_function_any+0x51/0x100 > > >> [ 0.377500] [<ffffffff815788c9>] get_cur_val+0x99/0x130 > > >> [ 0.377504] [<ffffffff81579444>] ? acpi_cpufreq_cpu_init+0x2b4/0x6a0 > > >> [ 0.377508] [<ffffffff81578db0>] get_cur_freq_on_cpu+0x60/0x80 > > >> [ 0.377512] [<ffffffff815795a2>] acpi_cpufreq_cpu_init+0x412/0x6a0 > > >> [ 0.377517] [<ffffffff81575bb9>] cpufreq_add_dev+0x2d9/0x4f0 > > >> [ 0.377523] [<ffffffff81d44b22>] ? cpufreq_gov_dbs_init+0x2c/0x2c > > >> [ 0.377528] [<ffffffff8145d379>] subsys_interface_register+0x89/0xd0 > > >> [ 0.377533] [<ffffffff81573dee>] cpufreq_register_driver+0x8e/0x180 > > >> [ 0.377537] [<ffffffff81d44c18>] acpi_cpufreq_init+0xf6/0x1f8 > > >> [ 0.377542] [<ffffffff814608e6>] ? platform_driver_register+0x46/0x50 > > >> [ 0.377547] [<ffffffff8100206f>] do_one_initcall+0x3f/0x170 > > >> [ 0.377553] [<ffffffff81d07029>] kernel_init_freeable+0x13e/0x1cd > > >> [ 0.377560] [<ffffffff81d06895>] ? do_early_param+0x86/0x86 > > >> [ 0.377565] [<ffffffff8169cf20>] ? rest_init+0x80/0x80 > > >> [ 0.377569] [<ffffffff8169cf2e>] kernel_init+0xe/0xf0 > > >> [ 0.377575] [<ffffffff816c722c>] ret_from_fork+0x7c/0xb0 > > >> [ 0.377578] [<ffffffff8169cf20>] ? rest_init+0x80/0x80 > > >> [ 0.377581] ---[ end trace c6ec8280ce20313a ]--- > > >> > > >> kernel/smp.c: Line #245 see [1]. > > >> > > > Can you please try the following? > > > > > > --- a/kernel/smp.c Fri Feb 8 19:25:32 2013 > > > +++ b/kernel/smp.c Fri Feb 8 19:53:14 2013 > > > @@ -241,7 +241,7 @@ int smp_call_function_single(int cpu, sm > > > * send smp call function interrupt to this cpu and as such deadlocks > > > * can't happen. > > > */ > > > - WARN_ON_ONCE(cpu_online(this_cpu) && (irqs_disabled() || in_interrupt()) > > > + WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled() > > > && !oops_in_progress); > > > > > > if (cpu == this_cpu) { > > > -- > > > > NO, it doesn't. > > > > So, you want to partly revert... > > > > commit b29f39c7c3e75a741a7da88244ec707f293ec04c > > "smp: Give WARN()ing if in_interrupt() when calling > > smp_call_function_many()/single()" > > > > ...why not completely? > > > > This patch was in last days Linux-Next and did not cause troubles (AFAICS). > > This problem was introduced by some cpufreq changes that have > been dropped from linux-next for now (they are still present > in the one you're testing, though). SMP cross-calls from IRQ context are generally unsafe, so I'd suggest a good look at the cpufreq changes first, before reverting the stronger debugging we introduced. Thanks, Ingo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ] 2013-02-08 13:21 ` Rafael J. Wysocki 2013-02-08 13:58 ` Ingo Molnar @ 2013-02-08 14:15 ` Sedat Dilek 2013-02-08 14:50 ` Viresh Kumar 2013-02-08 14:45 ` [linux-pm] " Viresh Kumar 2 siblings, 1 reply; 15+ messages in thread From: Sedat Dilek @ 2013-02-08 14:15 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Hillf Danton, Stephen Rothwell, linux-next, linux-kernel, Linux ACPI, Linux PM List, x86, Ingo Molnar, Chuansheng Liu On Fri, Feb 8, 2013 at 2:21 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Friday, February 08, 2013 01:47:44 PM Sedat Dilek wrote: >> On Fri, Feb 8, 2013 at 12:53 PM, Hillf Danton <dhillf@gmail.com> wrote: >> > Hello Sedat >> > >> > On Fri, Feb 8, 2013 at 4:46 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >> >> On Fri, Feb 8, 2013 at 5:31 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: >> >> With today's Linux-Next I see this warning: >> >> >> >> [ 0.377442] ------------[ cut here ]------------ >> >> [ 0.377452] WARNING: at kernel/smp.c:245 >> >> smp_call_function_single+0x146/0x190() >> >> [ 0.377455] Hardware name: 530U3BI/530U4BI/530U4BH >> >> [ 0.377458] Modules linked in: >> >> [ 0.377463] Pid: 1, comm: swapper/0 Not tainted >> >> 3.8.0-rc6-next20130208-1-iniza-small #1 >> >> [ 0.377467] Call Trace: >> >> [ 0.377473] [<ffffffff8105a5ef>] warn_slowpath_common+0x7f/0xc0 >> >> [ 0.377479] [<ffffffff81579130>] ? acpi_cpufreq_target+0x2c0/0x2c0 >> >> [ 0.377483] [<ffffffff8105a64a>] warn_slowpath_null+0x1a/0x20 >> >> [ 0.377487] [<ffffffff810bb7e6>] smp_call_function_single+0x146/0x190 >> >> [ 0.377492] [<ffffffff81579130>] ? acpi_cpufreq_target+0x2c0/0x2c0 >> >> [ 0.377496] [<ffffffff810bb881>] smp_call_function_any+0x51/0x100 >> >> [ 0.377500] [<ffffffff815788c9>] get_cur_val+0x99/0x130 >> >> [ 0.377504] [<ffffffff81579444>] ? acpi_cpufreq_cpu_init+0x2b4/0x6a0 >> >> [ 0.377508] [<ffffffff81578db0>] get_cur_freq_on_cpu+0x60/0x80 >> >> [ 0.377512] [<ffffffff815795a2>] acpi_cpufreq_cpu_init+0x412/0x6a0 >> >> [ 0.377517] [<ffffffff81575bb9>] cpufreq_add_dev+0x2d9/0x4f0 >> >> [ 0.377523] [<ffffffff81d44b22>] ? cpufreq_gov_dbs_init+0x2c/0x2c >> >> [ 0.377528] [<ffffffff8145d379>] subsys_interface_register+0x89/0xd0 >> >> [ 0.377533] [<ffffffff81573dee>] cpufreq_register_driver+0x8e/0x180 >> >> [ 0.377537] [<ffffffff81d44c18>] acpi_cpufreq_init+0xf6/0x1f8 >> >> [ 0.377542] [<ffffffff814608e6>] ? platform_driver_register+0x46/0x50 >> >> [ 0.377547] [<ffffffff8100206f>] do_one_initcall+0x3f/0x170 >> >> [ 0.377553] [<ffffffff81d07029>] kernel_init_freeable+0x13e/0x1cd >> >> [ 0.377560] [<ffffffff81d06895>] ? do_early_param+0x86/0x86 >> >> [ 0.377565] [<ffffffff8169cf20>] ? rest_init+0x80/0x80 >> >> [ 0.377569] [<ffffffff8169cf2e>] kernel_init+0xe/0xf0 >> >> [ 0.377575] [<ffffffff816c722c>] ret_from_fork+0x7c/0xb0 >> >> [ 0.377578] [<ffffffff8169cf20>] ? rest_init+0x80/0x80 >> >> [ 0.377581] ---[ end trace c6ec8280ce20313a ]--- >> >> >> >> kernel/smp.c: Line #245 see [1]. >> >> >> > Can you please try the following? >> > >> > --- a/kernel/smp.c Fri Feb 8 19:25:32 2013 >> > +++ b/kernel/smp.c Fri Feb 8 19:53:14 2013 >> > @@ -241,7 +241,7 @@ int smp_call_function_single(int cpu, sm >> > * send smp call function interrupt to this cpu and as such deadlocks >> > * can't happen. >> > */ >> > - WARN_ON_ONCE(cpu_online(this_cpu) && (irqs_disabled() || in_interrupt()) >> > + WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled() >> > && !oops_in_progress); >> > >> > if (cpu == this_cpu) { >> > -- >> >> NO, it doesn't. >> >> So, you want to partly revert... >> >> commit b29f39c7c3e75a741a7da88244ec707f293ec04c >> "smp: Give WARN()ing if in_interrupt() when calling >> smp_call_function_many()/single()" >> >> ...why not completely? >> >> This patch was in last days Linux-Next and did not cause troubles (AFAICS). > > This problem was introduced by some cpufreq changes that have been dropped from > linux-next for now (they are still present in the one you're testing, though). > "...some...changes..." is not very concrete :-). Which commit(s) caused this trouble? Is current (meanwhile updated?) linux-pm.git#linux-next good (didn't check last commit-ids of your tree from Next/ dir)? - Sedat - > Thanks, > Rafael > > > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ] 2013-02-08 14:15 ` Sedat Dilek @ 2013-02-08 14:50 ` Viresh Kumar 2013-02-08 15:19 ` Sedat Dilek 0 siblings, 1 reply; 15+ messages in thread From: Viresh Kumar @ 2013-02-08 14:50 UTC (permalink / raw) To: sedat.dilek Cc: Rafael J. Wysocki, Hillf Danton, Stephen Rothwell, linux-next, linux-kernel, Linux ACPI, Linux PM List, x86, Ingo Molnar, Chuansheng Liu [-- Attachment #1: Type: text/plain, Size: 2419 bytes --] On Fri, Feb 8, 2013 at 7:45 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: > "...some...changes..." is not very concrete :-). > Which commit(s) caused this trouble? > > Is current (meanwhile updated?) linux-pm.git#linux-next good (didn't > check last commit-ids of your tree from Next/ dir)? Attached patch would fix it for you and it looks like and is going to be pulled in by Rafael: From: Viresh Kumar <viresh.kumar@linaro.org> Date: Fri, 8 Feb 2013 10:35:31 +0530 Subject: [PATCH] cpufreq: Remove unnecessary locking I have placed some locks intentionally around calls to driver->ops (init/exit), which look to be wrong as these calls can call routines that potentially sleep. Lets remove these locks. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> --- drivers/cpufreq/cpufreq.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 5d8a422..04aab05 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -795,10 +795,8 @@ static int cpufreq_add_dev_interface(unsigned int cpu, if (ret) { pr_debug("setting policy failed\n"); - spin_lock_irqsave(&cpufreq_driver_lock, flags); if (driver->exit) driver->exit(policy); - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); } return ret; @@ -920,17 +918,14 @@ static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif) init_completion(&policy->kobj_unregister); INIT_WORK(&policy->update, handle_update); - spin_lock_irqsave(&cpufreq_driver_lock, flags); /* call driver. From then on the cpufreq must be able * to accept all calls to ->verify and ->setpolicy for this CPU */ ret = driver->init(policy); if (ret) { pr_debug("initialization failed\n"); - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); goto err_set_policy_cpu; } - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); /* related cpus should atleast have policy->cpus */ cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus); @@ -1100,10 +1095,8 @@ static int __cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif wait_for_completion(cmp); pr_debug("wait complete\n"); - spin_lock_irqsave(&cpufreq_driver_lock, flags); if (driver->exit) driver->exit(data); - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); free_cpumask_var(data->related_cpus); free_cpumask_var(data->cpus); [-- Attachment #2: 0001-cpufreq-Remove-unnecessary-locking.patch --] [-- Type: application/octet-stream, Size: 2230 bytes --] From 564df37b5db51182e5e6e78969f40a2a71159b9c Mon Sep 17 00:00:00 2001 Message-Id: <564df37b5db51182e5e6e78969f40a2a71159b9c.1360300126.git.viresh.kumar@linaro.org> From: Viresh Kumar <viresh.kumar@linaro.org> Date: Fri, 8 Feb 2013 10:35:31 +0530 Subject: [PATCH] cpufreq: Remove unnecessary locking I have placed some locks intentionally around calls to driver->ops (init/exit), which look to be wrong as these calls can call routines that potentially sleep. Lets remove these locks. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> --- drivers/cpufreq/cpufreq.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 5d8a422..04aab05 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -795,10 +795,8 @@ static int cpufreq_add_dev_interface(unsigned int cpu, if (ret) { pr_debug("setting policy failed\n"); - spin_lock_irqsave(&cpufreq_driver_lock, flags); if (driver->exit) driver->exit(policy); - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); } return ret; @@ -920,17 +918,14 @@ static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif) init_completion(&policy->kobj_unregister); INIT_WORK(&policy->update, handle_update); - spin_lock_irqsave(&cpufreq_driver_lock, flags); /* call driver. From then on the cpufreq must be able * to accept all calls to ->verify and ->setpolicy for this CPU */ ret = driver->init(policy); if (ret) { pr_debug("initialization failed\n"); - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); goto err_set_policy_cpu; } - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); /* related cpus should atleast have policy->cpus */ cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus); @@ -1100,10 +1095,8 @@ static int __cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif wait_for_completion(cmp); pr_debug("wait complete\n"); - spin_lock_irqsave(&cpufreq_driver_lock, flags); if (driver->exit) driver->exit(data); - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); free_cpumask_var(data->related_cpus); free_cpumask_var(data->cpus); -- 1.7.12.rc2.18.g61b472e ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ] 2013-02-08 14:50 ` Viresh Kumar @ 2013-02-08 15:19 ` Sedat Dilek 0 siblings, 0 replies; 15+ messages in thread From: Sedat Dilek @ 2013-02-08 15:19 UTC (permalink / raw) To: Viresh Kumar Cc: Rafael J. Wysocki, Hillf Danton, Stephen Rothwell, linux-next, linux-kernel, Linux ACPI, Linux PM List, x86, Ingo Molnar, Chuansheng Liu On Fri, Feb 8, 2013 at 3:50 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > On Fri, Feb 8, 2013 at 7:45 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >> "...some...changes..." is not very concrete :-). >> Which commit(s) caused this trouble? >> >> Is current (meanwhile updated?) linux-pm.git#linux-next good (didn't >> check last commit-ids of your tree from Next/ dir)? > > Attached patch would fix it for you and it looks like and is going to be > pulled in by Rafael: > > From: Viresh Kumar <viresh.kumar@linaro.org> > Date: Fri, 8 Feb 2013 10:35:31 +0530 > Subject: [PATCH] cpufreq: Remove unnecessary locking > > I have placed some locks intentionally around calls to driver->ops (init/exit), > which look to be wrong as these calls can call routines that potentially sleep. > > Lets remove these locks. > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> ( 0001-cpufreq-Remove-unnecessary-locking.patch fixes the issue here! ) - Sedat - > --- > drivers/cpufreq/cpufreq.c | 7 ------- > 1 file changed, 7 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 5d8a422..04aab05 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -795,10 +795,8 @@ static int cpufreq_add_dev_interface(unsigned int cpu, > > if (ret) { > pr_debug("setting policy failed\n"); > - spin_lock_irqsave(&cpufreq_driver_lock, flags); > if (driver->exit) > driver->exit(policy); > - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); > } > return ret; > > @@ -920,17 +918,14 @@ static int cpufreq_add_dev(struct device *dev, > struct subsys_interface *sif) > init_completion(&policy->kobj_unregister); > INIT_WORK(&policy->update, handle_update); > > - spin_lock_irqsave(&cpufreq_driver_lock, flags); > /* call driver. From then on the cpufreq must be able > * to accept all calls to ->verify and ->setpolicy for this CPU > */ > ret = driver->init(policy); > if (ret) { > pr_debug("initialization failed\n"); > - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); > goto err_set_policy_cpu; > } > - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); > > /* related cpus should atleast have policy->cpus */ > cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus); > @@ -1100,10 +1095,8 @@ static int __cpufreq_remove_dev(struct device > *dev, struct subsys_interface *sif > wait_for_completion(cmp); > pr_debug("wait complete\n"); > > - spin_lock_irqsave(&cpufreq_driver_lock, flags); > if (driver->exit) > driver->exit(data); > - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); > > free_cpumask_var(data->related_cpus); > free_cpumask_var(data->cpus); ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-pm] linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ] 2013-02-08 13:21 ` Rafael J. Wysocki 2013-02-08 13:58 ` Ingo Molnar 2013-02-08 14:15 ` Sedat Dilek @ 2013-02-08 14:45 ` Viresh Kumar 2013-02-08 14:48 ` Sedat Dilek 2 siblings, 1 reply; 15+ messages in thread From: Viresh Kumar @ 2013-02-08 14:45 UTC (permalink / raw) To: sedat.dilek, Rafael J. Wysocki Cc: Stephen Rothwell, x86, linux-kernel, Linux ACPI, Hillf Danton, linux-next, Linux PM List, Chuansheng Liu, Ingo Molnar On 8 February 2013 18:51, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Friday, February 08, 2013 01:47:44 PM Sedat Dilek wrote: >> >> [ 0.377473] [<ffffffff8105a5ef>] warn_slowpath_common+0x7f/0xc0 >> >> [ 0.377479] [<ffffffff81579130>] ? acpi_cpufreq_target+0x2c0/0x2c0 >> >> [ 0.377483] [<ffffffff8105a64a>] warn_slowpath_null+0x1a/0x20 >> >> [ 0.377487] [<ffffffff810bb7e6>] smp_call_function_single+0x146/0x190 >> >> [ 0.377492] [<ffffffff81579130>] ? acpi_cpufreq_target+0x2c0/0x2c0 >> >> [ 0.377496] [<ffffffff810bb881>] smp_call_function_any+0x51/0x100 >> >> [ 0.377500] [<ffffffff815788c9>] get_cur_val+0x99/0x130 >> >> [ 0.377504] [<ffffffff81579444>] ? acpi_cpufreq_cpu_init+0x2b4/0x6a0 >> >> [ 0.377508] [<ffffffff81578db0>] get_cur_freq_on_cpu+0x60/0x80 >> >> [ 0.377512] [<ffffffff815795a2>] acpi_cpufreq_cpu_init+0x412/0x6a0 >> >> [ 0.377517] [<ffffffff81575bb9>] cpufreq_add_dev+0x2d9/0x4f0 > This problem was introduced by some cpufreq changes that have been dropped from > linux-next for now (they are still present in the one you're testing, though). I know why you got this crash and a pull from following would certainly fix it :) http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/for-rafael ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-pm] linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ] 2013-02-08 14:45 ` [linux-pm] " Viresh Kumar @ 2013-02-08 14:48 ` Sedat Dilek 2013-02-08 14:56 ` Viresh Kumar 0 siblings, 1 reply; 15+ messages in thread From: Sedat Dilek @ 2013-02-08 14:48 UTC (permalink / raw) To: Viresh Kumar Cc: Rafael J. Wysocki, Stephen Rothwell, x86, linux-kernel, Linux ACPI, Hillf Danton, linux-next, Linux PM List, Chuansheng Liu, Ingo Molnar On Fri, Feb 8, 2013 at 3:45 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > On 8 February 2013 18:51, Rafael J. Wysocki <rjw@sisk.pl> wrote: >> On Friday, February 08, 2013 01:47:44 PM Sedat Dilek wrote: >>> >> [ 0.377473] [<ffffffff8105a5ef>] warn_slowpath_common+0x7f/0xc0 >>> >> [ 0.377479] [<ffffffff81579130>] ? acpi_cpufreq_target+0x2c0/0x2c0 >>> >> [ 0.377483] [<ffffffff8105a64a>] warn_slowpath_null+0x1a/0x20 >>> >> [ 0.377487] [<ffffffff810bb7e6>] smp_call_function_single+0x146/0x190 >>> >> [ 0.377492] [<ffffffff81579130>] ? acpi_cpufreq_target+0x2c0/0x2c0 >>> >> [ 0.377496] [<ffffffff810bb881>] smp_call_function_any+0x51/0x100 >>> >> [ 0.377500] [<ffffffff815788c9>] get_cur_val+0x99/0x130 >>> >> [ 0.377504] [<ffffffff81579444>] ? acpi_cpufreq_cpu_init+0x2b4/0x6a0 >>> >> [ 0.377508] [<ffffffff81578db0>] get_cur_freq_on_cpu+0x60/0x80 >>> >> [ 0.377512] [<ffffffff815795a2>] acpi_cpufreq_cpu_init+0x412/0x6a0 >>> >> [ 0.377517] [<ffffffff81575bb9>] cpufreq_add_dev+0x2d9/0x4f0 > >> This problem was introduced by some cpufreq changes that have been dropped from >> linux-next for now (they are still present in the one you're testing, though). > > I know why you got this crash and a pull from following would > certainly fix it :) > > http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/for-rafael Nah, I pulled in latest pm-next where this commit is new... commit 8d5666f3456f2fd4a4e5dced228475b829851e53 "ACPI: Unbind ACPI drv when probe failed" ...building with it. Same to you, say concretely which commit is fixing what... Pull-N-B-Happy was never my strategy... I want to understand what went wrong and have stolen my time. - Sedat - [1] http://git.kernel.org/?p=linux/kernel/git/rafael/linux-pm.git;a=commitdiff;h=8d5666f3456f2fd4a4e5dced228475b829851e53 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-pm] linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ] 2013-02-08 14:48 ` Sedat Dilek @ 2013-02-08 14:56 ` Viresh Kumar 2013-02-08 15:21 ` Sedat Dilek 0 siblings, 1 reply; 15+ messages in thread From: Viresh Kumar @ 2013-02-08 14:56 UTC (permalink / raw) To: sedat.dilek Cc: Rafael J. Wysocki, Stephen Rothwell, x86, linux-kernel, Linux ACPI, Hillf Danton, linux-next, Linux PM List, Chuansheng Liu, Ingo Molnar On Fri, Feb 8, 2013 at 8:18 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: > Nah, I pulled in latest pm-next where this commit is new... > > commit 8d5666f3456f2fd4a4e5dced228475b829851e53 > "ACPI: Unbind ACPI drv when probe failed" > > ...building with it. > > Same to you, say concretely which commit is fixing what... > > Pull-N-B-Happy was never my strategy... I want to understand what went > wrong and have stolen my time. I don't have any pointers to broken tree and so can't point you to the culprit, but it was this patch: http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=commit;h=e034e731f4d9d18ad0401f033f485a3096796c58 minus the patch i sent you as attachment. There were some locking introduced around init/exit of cpufreq_driver, which caused some drivers to break. Its fixed now in the above commit. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-pm] linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ] 2013-02-08 14:56 ` Viresh Kumar @ 2013-02-08 15:21 ` Sedat Dilek 2013-02-08 16:28 ` Sedat Dilek 0 siblings, 1 reply; 15+ messages in thread From: Sedat Dilek @ 2013-02-08 15:21 UTC (permalink / raw) To: Viresh Kumar Cc: Rafael J. Wysocki, Stephen Rothwell, x86, linux-kernel, Linux ACPI, Hillf Danton, linux-next, Linux PM List, Chuansheng Liu, Ingo Molnar On Fri, Feb 8, 2013 at 3:56 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > On Fri, Feb 8, 2013 at 8:18 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >> Nah, I pulled in latest pm-next where this commit is new... >> >> commit 8d5666f3456f2fd4a4e5dced228475b829851e53 >> "ACPI: Unbind ACPI drv when probe failed" >> >> ...building with it. >> >> Same to you, say concretely which commit is fixing what... >> >> Pull-N-B-Happy was never my strategy... I want to understand what went >> wrong and have stolen my time. > > I don't have any pointers to broken tree and so can't point you to the culprit, > but it was this patch: > > http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=commit;h=e034e731f4d9d18ad0401f033f485a3096796c58 > > minus > > the patch i sent you as attachment. > > There were some locking introduced around init/exit of cpufreq_driver, which > caused some drivers to break. Its fixed now in the above commit. Hmm, this "high-patch-maths" is not user-friendly! I will pull-in your tree into Linux-Next (next-20130208) and see if it applies cleanly. - Sedat - ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-pm] linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ] 2013-02-08 15:21 ` Sedat Dilek @ 2013-02-08 16:28 ` Sedat Dilek 2013-02-08 16:51 ` Sedat Dilek 0 siblings, 1 reply; 15+ messages in thread From: Sedat Dilek @ 2013-02-08 16:28 UTC (permalink / raw) To: Viresh Kumar Cc: Rafael J. Wysocki, Stephen Rothwell, x86, linux-kernel, Linux ACPI, Hillf Danton, linux-next, Linux PM List, Chuansheng Liu, Ingo Molnar [-- Attachment #1: Type: text/plain, Size: 1360 bytes --] On Fri, Feb 8, 2013 at 4:21 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: > On Fri, Feb 8, 2013 at 3:56 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote: >> On Fri, Feb 8, 2013 at 8:18 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >>> Nah, I pulled in latest pm-next where this commit is new... >>> >>> commit 8d5666f3456f2fd4a4e5dced228475b829851e53 >>> "ACPI: Unbind ACPI drv when probe failed" >>> >>> ...building with it. >>> >>> Same to you, say concretely which commit is fixing what... >>> >>> Pull-N-B-Happy was never my strategy... I want to understand what went >>> wrong and have stolen my time. >> >> I don't have any pointers to broken tree and so can't point you to the culprit, >> but it was this patch: >> >> http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=commit;h=e034e731f4d9d18ad0401f033f485a3096796c58 >> >> minus >> >> the patch i sent you as attachment. >> >> There were some locking introduced around init/exit of cpufreq_driver, which >> caused some drivers to break. Its fixed now in the above commit. > > Hmm, this "high-patch-maths" is not user-friendly! > > I will pull-in your tree into Linux-Next (next-20130208) and see if it > applies cleanly. > > - Sedat - No, it did NOT apply cleanly and I merged your tree like this. To me it does not look like your changes from the patch you sent me are included? - Sedat - [-- Attachment #2: cpufreq-next.patch --] [-- Type: application/octet-stream, Size: 37253 bytes --] Andrew Lunn (1): cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs Dirk Brandewie (5): cpufreq: Retrieve current frequency from scaling drivers with internal governors cpufreq: Only call cpufreq_out_of_sync() for driver that implement cpufreq_driver.target() cpufreq: Do not track governor name for scaling drivers with internal governors. cpufreq_stats: do not remove sysfs files if frequency table is not present cpufreq/x86: Add P-state driver for sandy bridge. Sedat Dilek (2): Merge tag 'next-20130208' of git://git.kernel.org/.../next/linux-next into Linux-Next-v20130208 Merge branch 'for-rafael' of git://git.linaro.org/people/vireshk/linux into cpufreq-next Viresh Kumar (5): cpufreq: governors: Fix WARN_ON() for multi-policy platforms cpufreq: Remove unused HOTPLUG_CPU code cpufreq: Create a macro for unlock_policy_rwsem{read,write} cpufreq: Fix locking issues cpufreq: exynos: simplify .init() for setting policy->cpus Documentation/devicetree/bindings/arm/kirkwood.txt | 27 + drivers/clk/mvebu/clk-gating-ctrl.c | 1 + drivers/cpufreq/Kconfig.arm | 6 + drivers/cpufreq/Kconfig.x86 | 18 + drivers/cpufreq/Makefile | 2 + drivers/cpufreq/cpufreq.c | 21 +- drivers/cpufreq/cpufreq_stats.c | 4 + drivers/cpufreq/exynos-cpufreq.c | 14 +- drivers/cpufreq/intel_pstate.c | 806 +++++++++++++++++++++ drivers/cpufreq/kirkwood-cpufreq.c | 259 +++++++ 10 files changed, 1134 insertions(+), 24 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/kirkwood.txt b/Documentation/devicetree/bindings/arm/kirkwood.txt new file mode 100644 index 0000000..98cce9a --- /dev/null +++ b/Documentation/devicetree/bindings/arm/kirkwood.txt @@ -0,0 +1,27 @@ +Marvell Kirkwood Platforms Device Tree Bindings +----------------------------------------------- + +Boards with a SoC of the Marvell Kirkwood +shall have the following property: + +Required root node property: + +compatible: must contain "marvell,kirkwood"; + +In order to support the kirkwood cpufreq driver, there must be a node +cpus/cpu@0 with three clocks, "cpu_clk", "ddrclk" and "powersave", +where the "powersave" clock is a gating clock used to switch the CPU +between the "cpu_clk" and the "ddrclk". + +Example: + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + device_type = "cpu"; + compatible = "marvell,sheeva-88SV131"; + clocks = <&core_clk 1>, <&core_clk 3>, <&gate_clk 11>; + clock-names = "cpu_clk", "ddrclk", "powersave"; + }; diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c b/drivers/clk/mvebu/clk-gating-ctrl.c index 8fa5408..ebf141d 100644 --- a/drivers/clk/mvebu/clk-gating-ctrl.c +++ b/drivers/clk/mvebu/clk-gating-ctrl.c @@ -193,6 +193,7 @@ static const struct mvebu_soc_descr __initconst kirkwood_gating_descr[] = { { "runit", NULL, 7 }, { "xor0", NULL, 8 }, { "audio", NULL, 9 }, + { "powersave", "cpuclk", 11 }, { "sata0", NULL, 14 }, { "sata1", NULL, 15 }, { "xor1", NULL, 16 }, diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index 6693cf0..030ddf6 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -77,6 +77,12 @@ config ARM_EXYNOS5250_CPUFREQ This adds the CPUFreq driver for Samsung EXYNOS5250 SoC. +config ARM_KIRKWOOD_CPUFREQ + def_bool ARCH_KIRKWOOD && OF + help + This adds the CPUFreq driver for Marvell Kirkwood + SoCs. + config ARM_IMX6Q_CPUFREQ tristate "Freescale i.MX6Q cpufreq support" depends on SOC_IMX6Q diff --git a/drivers/cpufreq/Kconfig.x86 b/drivers/cpufreq/Kconfig.x86 index 4ea4e2b..bd1733a 100644 --- a/drivers/cpufreq/Kconfig.x86 +++ b/drivers/cpufreq/Kconfig.x86 @@ -2,6 +2,24 @@ # x86 CPU Frequency scaling drivers # +config X86_INTEL_PSTATE + tristate "Intel P state control" + depends on X86 + help + This driver provides a P state for Intel core processors. + The driver implements an internal governor and will become + the scaling driver and governor for Sandy bridge processors. + + When this driver is enabled it will become the perferred + scaling driver for Sandy bridge processors. + + Note: This driver should be built with the same settings as + the other scaling drivers configured into the system + (module/built-in) in order for the driver to register itself + as the scaling driver on the system. + + If in doubt, say N. + config X86_PCC_CPUFREQ tristate "Processor Clocking Control interface driver" depends on ACPI && ACPI_PROCESSOR diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index 655e8a9..863fd18 100644 --- a/drivers/cpufreq/Makefile +++ b/drivers/cpufreq/Makefile @@ -40,6 +40,7 @@ obj-$(CONFIG_X86_SPEEDSTEP_SMI) += speedstep-smi.o obj-$(CONFIG_X86_SPEEDSTEP_CENTRINO) += speedstep-centrino.o obj-$(CONFIG_X86_P4_CLOCKMOD) += p4-clockmod.o obj-$(CONFIG_X86_CPUFREQ_NFORCE2) += cpufreq-nforce2.o +obj-$(CONFIG_X86_INTEL_PSTATE) += intel_pstate.o ################################################################################## # ARM SoC drivers @@ -51,6 +52,7 @@ obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o +obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o obj-$(CONFIG_ARM_SPEAR_CPUFREQ) += spear-cpufreq.o obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 79511ab..873cd11 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -794,10 +794,8 @@ static int cpufreq_add_dev_interface(unsigned int cpu, if (ret) { pr_debug("setting policy failed\n"); - spin_lock_irqsave(&cpufreq_driver_lock, flags); if (driver->exit) driver->exit(policy); - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); } return ret; @@ -919,17 +917,14 @@ static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif) init_completion(&policy->kobj_unregister); INIT_WORK(&policy->update, handle_update); - spin_lock_irqsave(&cpufreq_driver_lock, flags); /* call driver. From then on the cpufreq must be able * to accept all calls to ->verify and ->setpolicy for this CPU */ ret = driver->init(policy); if (ret) { pr_debug("initialization failed\n"); - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); goto err_set_policy_cpu; } - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); /* related cpus should atleast have policy->cpus */ cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus); @@ -1039,8 +1034,9 @@ static int __cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif __cpufreq_governor(data, CPUFREQ_GOV_STOP); #ifdef CONFIG_HOTPLUG_CPU - strncpy(per_cpu(cpufreq_cpu_governor, cpu), data->governor->name, - CPUFREQ_NAME_LEN); + if (!driver->setpolicy) + strncpy(per_cpu(cpufreq_cpu_governor, cpu), + data->governor->name, CPUFREQ_NAME_LEN); #endif WARN_ON(lock_policy_rwsem_write(cpu)); @@ -1098,10 +1094,8 @@ static int __cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif wait_for_completion(cmp); pr_debug("wait complete\n"); - spin_lock_irqsave(&cpufreq_driver_lock, flags); if (driver->exit) driver->exit(data); - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); free_cpumask_var(data->related_cpus); free_cpumask_var(data->cpus); @@ -1172,9 +1166,14 @@ static void cpufreq_out_of_sync(unsigned int cpu, unsigned int old_freq, */ unsigned int cpufreq_quick_get(unsigned int cpu) { - struct cpufreq_policy *policy = cpufreq_cpu_get(cpu); + struct cpufreq_driver *driver = rcu_dereference(cpufreq_driver); + struct cpufreq_policy *policy; unsigned int ret_freq = 0; + if (driver && driver->setpolicy && driver->get) + return driver->get(cpu); + + policy = cpufreq_cpu_get(cpu); if (policy) { ret_freq = policy->cur; cpufreq_cpu_put(policy); @@ -1790,7 +1789,7 @@ int cpufreq_update_policy(unsigned int cpu) pr_debug("Driver did not initialize current freq"); data->cur = policy.cur; } else { - if (data->cur != policy.cur) + if (data->cur != policy.cur && driver->target) cpufreq_out_of_sync(cpu, data->cur, policy.cur); } diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c index a2dee4c..2fd779e 100644 --- a/drivers/cpufreq/cpufreq_stats.c +++ b/drivers/cpufreq/cpufreq_stats.c @@ -179,6 +179,10 @@ static void cpufreq_stats_free_table(unsigned int cpu) static void cpufreq_stats_free_sysfs(unsigned int cpu) { struct cpufreq_policy *policy = cpufreq_cpu_get(cpu); + + if (!cpufreq_frequency_get_table(cpu)) + return; + if (policy && !policy_is_shared(policy)) { pr_debug("%s: Free sysfs stat\n", __func__); sysfs_remove_group(&policy->kobj, &stats_attr_group); diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c index 4268e46..93f2eea 100644 --- a/drivers/cpufreq/exynos-cpufreq.c +++ b/drivers/cpufreq/exynos-cpufreq.c @@ -249,19 +249,7 @@ static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy) /* set the transition latency value */ policy->cpuinfo.transition_latency = 100000; - /* - * EXYNOS4 multi-core processors has 2 cores - * that the frequency cannot be set independently. - * Each cpu is bound to the same speed. - * So the affected cpu is all of the cpus. - */ - if (num_online_cpus() == 1) { - 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); - } + cpumask_setall(policy->cpus); return cpufreq_frequency_table_cpuinfo(policy, exynos_info->freq_table); } diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c new file mode 100644 index 0000000..86ad482 --- /dev/null +++ b/drivers/cpufreq/intel_pstate.c @@ -0,0 +1,806 @@ +/* + * cpufreq_snb.c: Native P state management for Intel processors + * + * (C) Copyright 2012 Intel Corporation + * Author: Dirk Brandewie <dirk.j.brandewie@intel.com> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; version 2 + * of the License. + */ + +#include <linux/kernel.h> +#include <linux/kernel_stat.h> +#include <linux/module.h> +#include <linux/ktime.h> +#include <linux/hrtimer.h> +#include <linux/tick.h> +#include <linux/slab.h> +#include <linux/sched.h> +#include <linux/list.h> +#include <linux/cpu.h> +#include <linux/cpufreq.h> +#include <linux/sysfs.h> +#include <linux/types.h> +#include <linux/fs.h> +#include <linux/debugfs.h> +#include <trace/events/power.h> + +#include <asm/div64.h> +#include <asm/msr.h> +#include <asm/cpu_device_id.h> + +#define SAMPLE_COUNT 3 + +#define FRAC_BITS 8 +#define int_tofp(X) ((int64_t)(X) << FRAC_BITS) +#define fp_toint(X) ((X) >> FRAC_BITS) + +static inline int32_t mul_fp(int32_t x, int32_t y) +{ + return ((int64_t)x * (int64_t)y) >> FRAC_BITS; +} + +static inline int32_t div_fp(int32_t x, int32_t y) +{ + return div_s64((int64_t)x << FRAC_BITS, (int64_t)y); +} + +struct sample { + ktime_t start_time; + ktime_t end_time; + int core_pct_busy; + int pstate_pct_busy; + u64 duration_us; + u64 idletime_us; + u64 aperf; + u64 mperf; + int freq; +}; + +struct pstate_data { + int current_pstate; + int min_pstate; + int max_pstate; + int turbo_pstate; +}; + +struct _pid { + int setpoint; + int32_t integral; + int32_t p_gain; + int32_t i_gain; + int32_t d_gain; + int deadband; + int last_err; +}; + +struct cpudata { + int cpu; + + char name[64]; + + struct timer_list timer; + + struct pstate_adjust_policy *pstate_policy; + struct pstate_data pstate; + struct _pid pid; + struct _pid idle_pid; + + int min_pstate_count; + int idle_mode; + + ktime_t prev_sample; + u64 prev_idle_time_us; + u64 prev_aperf; + u64 prev_mperf; + int sample_ptr; + struct sample samples[SAMPLE_COUNT]; +}; + +static struct cpudata **all_cpu_data; +struct pstate_adjust_policy { + int sample_rate_ms; + int deadband; + int setpoint; + int p_gain_pct; + int d_gain_pct; + int i_gain_pct; +}; + +static struct pstate_adjust_policy default_policy = { + .sample_rate_ms = 10, + .deadband = 0, + .setpoint = 109, + .p_gain_pct = 17, + .d_gain_pct = 0, + .i_gain_pct = 4, +}; + +struct perf_limits { + int no_turbo; + int max_perf_pct; + int min_perf_pct; + int32_t max_perf; + int32_t min_perf; +}; + +static struct perf_limits limits = { + .no_turbo = 0, + .max_perf_pct = 100, + .max_perf = int_tofp(1), + .min_perf_pct = 0, + .min_perf = 0, +}; + +static inline void pid_reset(struct _pid *pid, int setpoint, int busy, + int deadband, int integral) { + pid->setpoint = setpoint; + pid->deadband = deadband; + pid->integral = int_tofp(integral); + pid->last_err = setpoint - busy; +} + +static inline void pid_p_gain_set(struct _pid *pid, int percent) +{ + pid->p_gain = div_fp(int_tofp(percent), int_tofp(100)); +} + +static inline void pid_i_gain_set(struct _pid *pid, int percent) +{ + pid->i_gain = div_fp(int_tofp(percent), int_tofp(100)); +} + +static inline void pid_d_gain_set(struct _pid *pid, int percent) +{ + + pid->d_gain = div_fp(int_tofp(percent), int_tofp(100)); +} + +static signed int pid_calc(struct _pid *pid, int busy) +{ + signed int err, result; + int32_t pterm, dterm, fp_error; + int32_t integral_limit; + + err = pid->setpoint - busy; + fp_error = int_tofp(err); + + if (abs(err) <= pid->deadband) + return 0; + + pterm = mul_fp(pid->p_gain, fp_error); + + pid->integral += fp_error; + + /* limit the integral term */ + integral_limit = int_tofp(30); + if (pid->integral > integral_limit) + pid->integral = integral_limit; + if (pid->integral < -integral_limit) + pid->integral = -integral_limit; + + dterm = mul_fp(pid->d_gain, (err - pid->last_err)); + pid->last_err = err; + + result = pterm + mul_fp(pid->integral, pid->i_gain) + dterm; + + return (signed int)fp_toint(result); +} + +static inline void intel_pstate_busy_pid_reset(struct cpudata *cpu) +{ + pid_p_gain_set(&cpu->pid, cpu->pstate_policy->p_gain_pct); + pid_d_gain_set(&cpu->pid, cpu->pstate_policy->d_gain_pct); + pid_i_gain_set(&cpu->pid, cpu->pstate_policy->i_gain_pct); + + pid_reset(&cpu->pid, + cpu->pstate_policy->setpoint, + 100, + cpu->pstate_policy->deadband, + 0); +} + +static inline void intel_pstate_idle_pid_reset(struct cpudata *cpu) +{ + pid_p_gain_set(&cpu->idle_pid, cpu->pstate_policy->p_gain_pct); + pid_d_gain_set(&cpu->idle_pid, cpu->pstate_policy->d_gain_pct); + pid_i_gain_set(&cpu->idle_pid, cpu->pstate_policy->i_gain_pct); + + pid_reset(&cpu->idle_pid, + 75, + 50, + cpu->pstate_policy->deadband, + 0); +} + +static inline void intel_pstate_reset_all_pid(void) +{ + unsigned int cpu; + for_each_online_cpu(cpu) { + if (all_cpu_data[cpu]) + intel_pstate_busy_pid_reset(all_cpu_data[cpu]); + } +} + +/************************** debugfs begin ************************/ +static int pid_param_set(void *data, u64 val) +{ + *(u32 *)data = val; + intel_pstate_reset_all_pid(); + return 0; +} +static int pid_param_get(void *data, u64 *val) +{ + *val = *(u32 *)data; + return 0; +} +DEFINE_SIMPLE_ATTRIBUTE(fops_pid_param, pid_param_get, + pid_param_set, "%llu\n"); + +struct pid_param { + char *name; + void *value; +}; + +static struct pid_param pid_files[] = { + {"sample_rate_ms", &default_policy.sample_rate_ms}, + {"d_gain_pct", &default_policy.d_gain_pct}, + {"i_gain_pct", &default_policy.i_gain_pct}, + {"deadband", &default_policy.deadband}, + {"setpoint", &default_policy.setpoint}, + {"p_gain_pct", &default_policy.p_gain_pct}, + {NULL, NULL} +}; + +static struct dentry *debugfs_parent; +static void intel_pstate_debug_expose_params(void) +{ + int i = 0; + + debugfs_parent = debugfs_create_dir("pstate_snb", NULL); + if (IS_ERR_OR_NULL(debugfs_parent)) + return; + while (pid_files[i].name) { + debugfs_create_file(pid_files[i].name, 0660, + debugfs_parent, pid_files[i].value, + &fops_pid_param); + i++; + } +} + +/************************** debugfs end ************************/ + +/************************** sysfs begin ************************/ +#define show_one(file_name, object) \ + static ssize_t show_##file_name \ + (struct kobject *kobj, struct attribute *attr, char *buf) \ + { \ + return sprintf(buf, "%u\n", limits.object); \ + } + +static ssize_t store_no_turbo(struct kobject *a, struct attribute *b, + const char *buf, size_t count) +{ + unsigned int input; + int ret; + ret = sscanf(buf, "%u", &input); + if (ret != 1) + return -EINVAL; + limits.no_turbo = clamp_t(int, input, 0 , 1); + + return count; +} + +static ssize_t store_max_perf_pct(struct kobject *a, struct attribute *b, + const char *buf, size_t count) +{ + unsigned int input; + int ret; + ret = sscanf(buf, "%u", &input); + if (ret != 1) + return -EINVAL; + + limits.max_perf_pct = clamp_t(int, input, 0 , 100); + limits.max_perf = div_fp(int_tofp(limits.max_perf_pct), int_tofp(100)); + return count; +} + +static ssize_t store_min_perf_pct(struct kobject *a, struct attribute *b, + const char *buf, size_t count) +{ + unsigned int input; + int ret; + ret = sscanf(buf, "%u", &input); + if (ret != 1) + return -EINVAL; + limits.min_perf_pct = clamp_t(int, input, 0 , 100); + limits.min_perf = div_fp(int_tofp(limits.min_perf_pct), int_tofp(100)); + + return count; +} + +show_one(no_turbo, no_turbo); +show_one(max_perf_pct, max_perf_pct); +show_one(min_perf_pct, min_perf_pct); + +define_one_global_rw(no_turbo); +define_one_global_rw(max_perf_pct); +define_one_global_rw(min_perf_pct); + +static struct attribute *intel_pstate_attributes[] = { + &no_turbo.attr, + &max_perf_pct.attr, + &min_perf_pct.attr, + NULL +}; + +static struct attribute_group intel_pstate_attr_group = { + .attrs = intel_pstate_attributes, +}; +static struct kobject *intel_pstate_kobject; + +static void intel_pstate_sysfs_expose_params(void) +{ + int rc; + + intel_pstate_kobject = kobject_create_and_add("intel_pstate", + &cpu_subsys.dev_root->kobj); + BUG_ON(!intel_pstate_kobject); + rc = sysfs_create_group(intel_pstate_kobject, + &intel_pstate_attr_group); + BUG_ON(rc); +} + +/************************** sysfs end ************************/ + +static int intel_pstate_min_pstate(void) +{ + u64 value; + rdmsrl(0xCE, value); + return (value >> 40) & 0xFF; +} + +static int intel_pstate_max_pstate(void) +{ + u64 value; + rdmsrl(0xCE, value); + return (value >> 8) & 0xFF; +} + +static int intel_pstate_turbo_pstate(void) +{ + u64 value; + int nont, ret; + rdmsrl(0x1AD, value); + nont = intel_pstate_max_pstate(); + ret = ((value) & 255); + if (ret <= nont) + ret = nont; + return ret; +} + +static void intel_pstate_get_min_max(struct cpudata *cpu, int *min, int *max) +{ + int max_perf = cpu->pstate.turbo_pstate; + int min_perf; + if (limits.no_turbo) + max_perf = cpu->pstate.max_pstate; + + max_perf = fp_toint(mul_fp(int_tofp(max_perf), limits.max_perf)); + *max = clamp_t(int, max_perf, + cpu->pstate.min_pstate, cpu->pstate.turbo_pstate); + + min_perf = fp_toint(mul_fp(int_tofp(max_perf), limits.min_perf)); + *min = clamp_t(int, min_perf, + cpu->pstate.min_pstate, max_perf); +} + +static void intel_pstate_set_pstate(struct cpudata *cpu, int pstate) +{ + int max_perf, min_perf; + + intel_pstate_get_min_max(cpu, &min_perf, &max_perf); + + pstate = clamp_t(int, pstate, min_perf, max_perf); + + if (pstate == cpu->pstate.current_pstate) + return; + +#ifndef MODULE + trace_cpu_frequency(pstate * 100000, cpu->cpu); +#endif + cpu->pstate.current_pstate = pstate; + wrmsrl(MSR_IA32_PERF_CTL, pstate << 8); + +} + +static inline void intel_pstate_pstate_increase(struct cpudata *cpu, int steps) +{ + int target; + target = cpu->pstate.current_pstate + steps; + + intel_pstate_set_pstate(cpu, target); +} + +static inline void intel_pstate_pstate_decrease(struct cpudata *cpu, int steps) +{ + int target; + target = cpu->pstate.current_pstate - steps; + intel_pstate_set_pstate(cpu, target); +} + +static void intel_pstate_get_cpu_pstates(struct cpudata *cpu) +{ + sprintf(cpu->name, "Intel 2nd generation core"); + + cpu->pstate.min_pstate = intel_pstate_min_pstate(); + cpu->pstate.max_pstate = intel_pstate_max_pstate(); + cpu->pstate.turbo_pstate = intel_pstate_turbo_pstate(); + + /* + * goto max pstate so we don't slow up boot if we are built-in if we are + * a module we will take care of it during normal operation + */ + intel_pstate_set_pstate(cpu, cpu->pstate.max_pstate); +} + +static inline void intel_pstate_calc_busy(struct cpudata *cpu, + struct sample *sample) +{ + u64 core_pct; + sample->pstate_pct_busy = 100 - div64_u64( + sample->idletime_us * 100, + sample->duration_us); + core_pct = div64_u64(sample->aperf * 100, sample->mperf); + sample->freq = cpu->pstate.turbo_pstate * core_pct * 1000; + + sample->core_pct_busy = sample->pstate_pct_busy * core_pct / 100; +} + +static inline void intel_pstate_sample(struct cpudata *cpu) +{ + ktime_t now; + u64 idle_time_us; + u64 aperf, mperf; + + now = ktime_get(); + idle_time_us = get_cpu_idle_time_us(cpu->cpu, NULL); + + rdmsrl(MSR_IA32_APERF, aperf); + rdmsrl(MSR_IA32_MPERF, mperf); + /* for the first sample, don't actually record a sample, just + * set the baseline */ + if (cpu->prev_idle_time_us > 0) { + cpu->sample_ptr = (cpu->sample_ptr + 1) % SAMPLE_COUNT; + cpu->samples[cpu->sample_ptr].start_time = cpu->prev_sample; + cpu->samples[cpu->sample_ptr].end_time = now; + cpu->samples[cpu->sample_ptr].duration_us = + ktime_us_delta(now, cpu->prev_sample); + cpu->samples[cpu->sample_ptr].idletime_us = + idle_time_us - cpu->prev_idle_time_us; + + cpu->samples[cpu->sample_ptr].aperf = aperf; + cpu->samples[cpu->sample_ptr].mperf = mperf; + cpu->samples[cpu->sample_ptr].aperf -= cpu->prev_aperf; + cpu->samples[cpu->sample_ptr].mperf -= cpu->prev_mperf; + + intel_pstate_calc_busy(cpu, &cpu->samples[cpu->sample_ptr]); + } + + cpu->prev_sample = now; + cpu->prev_idle_time_us = idle_time_us; + cpu->prev_aperf = aperf; + cpu->prev_mperf = mperf; +} + +static inline void intel_pstate_set_sample_time(struct cpudata *cpu) +{ + int sample_time, delay; + + sample_time = cpu->pstate_policy->sample_rate_ms; + delay = msecs_to_jiffies(sample_time); + delay -= jiffies % delay; + mod_timer_pinned(&cpu->timer, jiffies + delay); +} + +static inline void intel_pstate_idle_mode(struct cpudata *cpu) +{ + cpu->idle_mode = 1; +} + +static inline void intel_pstate_normal_mode(struct cpudata *cpu) +{ + cpu->idle_mode = 0; +} + +static inline int intel_pstate_get_scaled_busy(struct cpudata *cpu) +{ + int32_t busy_scaled; + int32_t core_busy, turbo_pstate, current_pstate; + + core_busy = int_tofp(cpu->samples[cpu->sample_ptr].core_pct_busy); + turbo_pstate = int_tofp(cpu->pstate.turbo_pstate); + current_pstate = int_tofp(cpu->pstate.current_pstate); + busy_scaled = mul_fp(core_busy, div_fp(turbo_pstate, current_pstate)); + + return fp_toint(busy_scaled); +} + +static inline void intel_pstate_adjust_busy_pstate(struct cpudata *cpu) +{ + int busy_scaled; + struct _pid *pid; + signed int ctl = 0; + int steps; + + pid = &cpu->pid; + busy_scaled = intel_pstate_get_scaled_busy(cpu); + + ctl = pid_calc(pid, busy_scaled); + + steps = abs(ctl); + if (ctl < 0) + intel_pstate_pstate_increase(cpu, steps); + else + intel_pstate_pstate_decrease(cpu, steps); +} + +static inline void intel_pstate_adjust_idle_pstate(struct cpudata *cpu) +{ + int busy_scaled; + struct _pid *pid; + int ctl = 0; + int steps; + + pid = &cpu->idle_pid; + + busy_scaled = intel_pstate_get_scaled_busy(cpu); + + ctl = pid_calc(pid, 100 - busy_scaled); + + steps = abs(ctl); + if (ctl < 0) + intel_pstate_pstate_decrease(cpu, steps); + else + intel_pstate_pstate_increase(cpu, steps); + + if (cpu->pstate.current_pstate == cpu->pstate.min_pstate) + intel_pstate_normal_mode(cpu); +} + +static void intel_pstate_timer_func(unsigned long __data) +{ + struct cpudata *cpu = (struct cpudata *) __data; + + intel_pstate_sample(cpu); + + if (!cpu->idle_mode) + intel_pstate_adjust_busy_pstate(cpu); + else + intel_pstate_adjust_idle_pstate(cpu); + +#if defined(XPERF_FIX) + if (cpu->pstate.current_pstate == cpu->pstate.min_pstate) { + cpu->min_pstate_count++; + if (!(cpu->min_pstate_count % 5)) { + intel_pstate_set_pstate(cpu, cpu->pstate.max_pstate); + intel_pstate_idle_mode(cpu); + } + } else + cpu->min_pstate_count = 0; +#endif + intel_pstate_set_sample_time(cpu); +} + +#define ICPU(model, policy) \ + { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)&policy } + +static const struct x86_cpu_id intel_pstate_cpu_ids[] = { + ICPU(0x2a, default_policy), + ICPU(0x2d, default_policy), + {} +}; +MODULE_DEVICE_TABLE(x86cpu, intel_pstate_cpu_ids); + +static int intel_pstate_init_cpu(unsigned int cpunum) +{ + + const struct x86_cpu_id *id; + struct cpudata *cpu; + + id = x86_match_cpu(intel_pstate_cpu_ids); + if (!id) + return -ENODEV; + + all_cpu_data[cpunum] = kzalloc(sizeof(struct cpudata), GFP_KERNEL); + if (!all_cpu_data[cpunum]) + return -ENOMEM; + + cpu = all_cpu_data[cpunum]; + + intel_pstate_get_cpu_pstates(cpu); + + cpu->cpu = cpunum; + cpu->pstate_policy = + (struct pstate_adjust_policy *)id->driver_data; + init_timer_deferrable(&cpu->timer); + cpu->timer.function = intel_pstate_timer_func; + cpu->timer.data = + (unsigned long)cpu; + cpu->timer.expires = jiffies + HZ/100; + intel_pstate_busy_pid_reset(cpu); + intel_pstate_idle_pid_reset(cpu); + intel_pstate_sample(cpu); + intel_pstate_set_pstate(cpu, cpu->pstate.max_pstate); + + add_timer_on(&cpu->timer, cpunum); + + pr_info("Intel pstate controlling: cpu %d\n", cpunum); + + return 0; +} + +static unsigned int intel_pstate_get(unsigned int cpu_num) +{ + struct sample *sample; + struct cpudata *cpu; + + cpu = all_cpu_data[cpu_num]; + if (!cpu) + return 0; + sample = &cpu->samples[cpu->sample_ptr]; + return sample->freq; +} + +static int intel_pstate_set_policy(struct cpufreq_policy *policy) +{ + struct cpudata *cpu; + int min, max; + + cpu = all_cpu_data[policy->cpu]; + + intel_pstate_get_min_max(cpu, &min, &max); + + limits.min_perf_pct = (policy->min * 100) / policy->cpuinfo.max_freq; + limits.min_perf_pct = clamp_t(int, limits.min_perf_pct, 0 , 100); + limits.min_perf = div_fp(int_tofp(limits.min_perf_pct), int_tofp(100)); + + limits.max_perf_pct = policy->max * 100 / policy->cpuinfo.max_freq; + limits.max_perf_pct = clamp_t(int, limits.max_perf_pct, 0 , 100); + limits.max_perf = div_fp(int_tofp(limits.max_perf_pct), int_tofp(100)); + + if (policy->policy == CPUFREQ_POLICY_PERFORMANCE) { + limits.min_perf_pct = 100; + limits.min_perf = int_tofp(1); + limits.max_perf_pct = 100; + limits.max_perf = int_tofp(1); + limits.no_turbo = 0; + } + + return 0; +} + +static int intel_pstate_verify_policy(struct cpufreq_policy *policy) +{ + cpufreq_verify_within_limits(policy, + policy->cpuinfo.min_freq, + policy->cpuinfo.max_freq); + + if ((policy->policy != CPUFREQ_POLICY_POWERSAVE) && + (policy->policy != CPUFREQ_POLICY_PERFORMANCE)) + return -EINVAL; + + return 0; +} + +static int __cpuinit intel_pstate_cpu_exit(struct cpufreq_policy *policy) +{ + int cpu = policy->cpu; + + del_timer(&all_cpu_data[cpu]->timer); + kfree(all_cpu_data[cpu]); + all_cpu_data[cpu] = NULL; + return 0; +} + +static int __cpuinit intel_pstate_cpu_init(struct cpufreq_policy *policy) +{ + int rc, min_pstate, max_pstate; + struct cpudata *cpu; + + rc = intel_pstate_init_cpu(policy->cpu); + if (rc) + return rc; + + cpu = all_cpu_data[policy->cpu]; + + if (!limits.no_turbo && + limits.min_perf_pct == 100 && limits.max_perf_pct == 100) + policy->policy = CPUFREQ_POLICY_PERFORMANCE; + else + policy->policy = CPUFREQ_POLICY_POWERSAVE; + + intel_pstate_get_min_max(cpu, &min_pstate, &max_pstate); + policy->min = min_pstate * 100000; + policy->max = max_pstate * 100000; + + /* cpuinfo and default policy values */ + policy->cpuinfo.min_freq = cpu->pstate.min_pstate * 100000; + policy->cpuinfo.max_freq = cpu->pstate.turbo_pstate * 100000; + policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL; + cpumask_set_cpu(policy->cpu, policy->cpus); + + return 0; +} + +static struct cpufreq_driver intel_pstate_driver = { + .flags = CPUFREQ_CONST_LOOPS, + .verify = intel_pstate_verify_policy, + .setpolicy = intel_pstate_set_policy, + .get = intel_pstate_get, + .init = intel_pstate_cpu_init, + .exit = intel_pstate_cpu_exit, + .name = "intel_pstate", + .owner = THIS_MODULE, +}; + +static void intel_pstate_exit(void) +{ + int cpu; + + sysfs_remove_group(intel_pstate_kobject, + &intel_pstate_attr_group); + debugfs_remove_recursive(debugfs_parent); + + cpufreq_unregister_driver(&intel_pstate_driver); + + if (!all_cpu_data) + return; + + get_online_cpus(); + for_each_online_cpu(cpu) { + if (all_cpu_data[cpu]) { + del_timer_sync(&all_cpu_data[cpu]->timer); + kfree(all_cpu_data[cpu]); + } + } + + put_online_cpus(); + vfree(all_cpu_data); +} +module_exit(intel_pstate_exit); + +static int __init intel_pstate_init(void) +{ + int rc = 0; + const struct x86_cpu_id *id; + + id = x86_match_cpu(intel_pstate_cpu_ids); + if (!id) + return -ENODEV; + + pr_info("Intel P-state driver initializing.\n"); + + all_cpu_data = vmalloc(sizeof(void *) * num_possible_cpus()); + if (!all_cpu_data) + return -ENOMEM; + memset(all_cpu_data, 0, sizeof(void *) * num_possible_cpus()); + + rc = cpufreq_register_driver(&intel_pstate_driver); + if (rc) + goto out; + + intel_pstate_debug_expose_params(); + intel_pstate_sysfs_expose_params(); + return rc; +out: + intel_pstate_exit(); + return -ENODEV; +} +device_initcall(intel_pstate_init); + +MODULE_AUTHOR("Dirk Brandewie <dirk.j.brandewie@intel.com>"); +MODULE_DESCRIPTION("'intel_pstate' - P state driver Intel Core processors"); +MODULE_LICENSE("GPL"); diff --git a/drivers/cpufreq/kirkwood-cpufreq.c b/drivers/cpufreq/kirkwood-cpufreq.c new file mode 100644 index 0000000..0e83e3c --- /dev/null +++ b/drivers/cpufreq/kirkwood-cpufreq.c @@ -0,0 +1,259 @@ +/* + * kirkwood_freq.c: cpufreq driver for the Marvell kirkwood + * + * Copyright (C) 2013 Andrew Lunn <andrew@lunn.ch> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/clk.h> +#include <linux/clk-provider.h> +#include <linux/cpufreq.h> +#include <linux/of.h> +#include <linux/platform_device.h> +#include <linux/io.h> +#include <asm/proc-fns.h> + +#define CPU_SW_INT_BLK BIT(28) + +static struct priv +{ + struct clk *cpu_clk; + struct clk *ddr_clk; + struct clk *powersave_clk; + struct device *dev; + void __iomem *base; +} priv; + +#define STATE_CPU_FREQ 0x01 +#define STATE_DDR_FREQ 0x02 + +/* + * Kirkwood can swap the clock to the CPU between two clocks: + * + * - cpu clk + * - ddr clk + * + * The frequencies are set at runtime before registering this * + * table. + */ +static struct cpufreq_frequency_table kirkwood_freq_table[] = { + {STATE_CPU_FREQ, 0}, /* CPU uses cpuclk */ + {STATE_DDR_FREQ, 0}, /* CPU uses ddrclk */ + {0, CPUFREQ_TABLE_END}, +}; + +static unsigned int kirkwood_cpufreq_get_cpu_frequency(unsigned int cpu) +{ + if (__clk_is_enabled(priv.powersave_clk)) + return kirkwood_freq_table[1].frequency; + return kirkwood_freq_table[0].frequency; +} + +static void kirkwood_cpufreq_set_cpu_state(unsigned int index) +{ + struct cpufreq_freqs freqs; + unsigned int state = kirkwood_freq_table[index].index; + unsigned long reg; + + freqs.old = kirkwood_cpufreq_get_cpu_frequency(0); + freqs.new = kirkwood_freq_table[index].frequency; + freqs.cpu = 0; /* Kirkwood is UP */ + + cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE); + + dev_dbg(priv.dev, "Attempting to set frequency to %i KHz\n", + kirkwood_freq_table[index].frequency); + dev_dbg(priv.dev, "old frequency was %i KHz\n", + kirkwood_cpufreq_get_cpu_frequency(0)); + + if (freqs.old != freqs.new) { + local_irq_disable(); + + /* Disable interrupts to the CPU */ + reg = readl_relaxed(priv.base); + reg |= CPU_SW_INT_BLK; + writel_relaxed(reg, priv.base); + + switch (state) { + case STATE_CPU_FREQ: + clk_disable(priv.powersave_clk); + break; + case STATE_DDR_FREQ: + clk_enable(priv.powersave_clk); + break; + } + + /* Wait-for-Interrupt, while the hardware changes frequency */ + cpu_do_idle(); + + /* Enable interrupts to the CPU */ + reg = readl_relaxed(priv.base); + reg &= ~CPU_SW_INT_BLK; + writel_relaxed(reg, priv.base); + + local_irq_enable(); + } + cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE); +}; + +static int kirkwood_cpufreq_verify(struct cpufreq_policy *policy) +{ + return cpufreq_frequency_table_verify(policy, kirkwood_freq_table); +} + +static int kirkwood_cpufreq_target(struct cpufreq_policy *policy, + unsigned int target_freq, + unsigned int relation) +{ + unsigned int index = 0; + + if (cpufreq_frequency_table_target(policy, kirkwood_freq_table, + target_freq, relation, &index)) + return -EINVAL; + + kirkwood_cpufreq_set_cpu_state(index); + + return 0; +} + +/* Module init and exit code */ +static int kirkwood_cpufreq_cpu_init(struct cpufreq_policy *policy) +{ + int result; + + /* cpuinfo and default policy values */ + policy->cpuinfo.transition_latency = 5000; /* 5uS */ + policy->cur = kirkwood_cpufreq_get_cpu_frequency(0); + + result = cpufreq_frequency_table_cpuinfo(policy, kirkwood_freq_table); + if (result) + return result; + + cpufreq_frequency_table_get_attr(kirkwood_freq_table, policy->cpu); + + return 0; +} + +static int kirkwood_cpufreq_cpu_exit(struct cpufreq_policy *policy) +{ + cpufreq_frequency_table_put_attr(policy->cpu); + return 0; +} + +static struct freq_attr *kirkwood_cpufreq_attr[] = { + &cpufreq_freq_attr_scaling_available_freqs, + NULL, +}; + +static struct cpufreq_driver kirkwood_cpufreq_driver = { + .get = kirkwood_cpufreq_get_cpu_frequency, + .verify = kirkwood_cpufreq_verify, + .target = kirkwood_cpufreq_target, + .init = kirkwood_cpufreq_cpu_init, + .exit = kirkwood_cpufreq_cpu_exit, + .name = "kirkwood-cpufreq", + .owner = THIS_MODULE, + .attr = kirkwood_cpufreq_attr, +}; + +static int kirkwood_cpufreq_probe(struct platform_device *pdev) +{ + struct device_node *np; + struct resource *res; + int err; + + priv.dev = &pdev->dev; + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (!res) { + dev_err(&pdev->dev, "Cannot get memory resource\n"); + return -ENODEV; + } + priv.base = devm_request_and_ioremap(&pdev->dev, res); + if (!priv.base) { + dev_err(&pdev->dev, "Cannot ioremap\n"); + return -EADDRNOTAVAIL; + } + + np = of_find_node_by_path("/cpus/cpu@0"); + if (!np) + return -ENODEV; + + priv.cpu_clk = of_clk_get_by_name(np, "cpu_clk"); + if (IS_ERR(priv.cpu_clk)) { + dev_err(priv.dev, "Unable to get cpuclk"); + return PTR_ERR(priv.cpu_clk); + } + + clk_prepare_enable(priv.cpu_clk); + kirkwood_freq_table[0].frequency = clk_get_rate(priv.cpu_clk) / 1000; + + priv.ddr_clk = of_clk_get_by_name(np, "ddrclk"); + if (IS_ERR(priv.ddr_clk)) { + dev_err(priv.dev, "Unable to get ddrclk"); + err = PTR_ERR(priv.ddr_clk); + goto out_cpu; + } + + clk_prepare_enable(priv.ddr_clk); + kirkwood_freq_table[1].frequency = clk_get_rate(priv.ddr_clk) / 1000; + + priv.powersave_clk = of_clk_get_by_name(np, "powersave"); + if (IS_ERR(priv.powersave_clk)) { + dev_err(priv.dev, "Unable to get powersave"); + err = PTR_ERR(priv.powersave_clk); + goto out_ddr; + } + clk_prepare(priv.powersave_clk); + + of_node_put(np); + np = NULL; + + err = cpufreq_register_driver(&kirkwood_cpufreq_driver); + if (!err) + return 0; + + dev_err(priv.dev, "Failed to register cpufreq driver"); + + clk_disable_unprepare(priv.powersave_clk); +out_ddr: + clk_disable_unprepare(priv.ddr_clk); +out_cpu: + clk_disable_unprepare(priv.cpu_clk); + of_node_put(np); + + return err; +} + +static int kirkwood_cpufreq_remove(struct platform_device *pdev) +{ + cpufreq_unregister_driver(&kirkwood_cpufreq_driver); + + clk_disable_unprepare(priv.powersave_clk); + clk_disable_unprepare(priv.ddr_clk); + clk_disable_unprepare(priv.cpu_clk); + + return 0; +} + +static struct platform_driver kirkwood_cpufreq_platform_driver = { + .probe = kirkwood_cpufreq_probe, + .remove = kirkwood_cpufreq_remove, + .driver = { + .name = "kirkwood-cpufreq", + .owner = THIS_MODULE, + }, +}; + +module_platform_driver(kirkwood_cpufreq_platform_driver); + +MODULE_LICENSE("GPL v2"); +MODULE_AUTHOR("Andrew Lunn <andrew@lunn.ch"); +MODULE_DESCRIPTION("cpufreq driver for Marvell's kirkwood CPU"); +MODULE_ALIAS("platform:kirkwood-cpufreq"); ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [linux-pm] linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ] 2013-02-08 16:28 ` Sedat Dilek @ 2013-02-08 16:51 ` Sedat Dilek 2013-02-08 16:55 ` Viresh Kumar 0 siblings, 1 reply; 15+ messages in thread From: Sedat Dilek @ 2013-02-08 16:51 UTC (permalink / raw) To: Viresh Kumar Cc: Rafael J. Wysocki, Stephen Rothwell, x86, linux-kernel, Linux ACPI, Hillf Danton, linux-next, Linux PM List, Chuansheng Liu, Ingo Molnar On Fri, Feb 8, 2013 at 5:28 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: > On Fri, Feb 8, 2013 at 4:21 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >> On Fri, Feb 8, 2013 at 3:56 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote: >>> On Fri, Feb 8, 2013 at 8:18 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >>>> Nah, I pulled in latest pm-next where this commit is new... >>>> >>>> commit 8d5666f3456f2fd4a4e5dced228475b829851e53 >>>> "ACPI: Unbind ACPI drv when probe failed" >>>> >>>> ...building with it. >>>> >>>> Same to you, say concretely which commit is fixing what... >>>> >>>> Pull-N-B-Happy was never my strategy... I want to understand what went >>>> wrong and have stolen my time. >>> >>> I don't have any pointers to broken tree and so can't point you to the culprit, >>> but it was this patch: >>> >>> http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=commit;h=e034e731f4d9d18ad0401f033f485a3096796c58 >>> >>> minus >>> >>> the patch i sent you as attachment. >>> >>> There were some locking introduced around init/exit of cpufreq_driver, which >>> caused some drivers to break. Its fixed now in the above commit. >> >> Hmm, this "high-patch-maths" is not user-friendly! >> >> I will pull-in your tree into Linux-Next (next-20130208) and see if it >> applies cleanly. >> >> - Sedat - > > No, it did NOT apply cleanly and I merged your tree like this. > To me it does not look like your changes from the patch you sent me > are included? > > - Sedat - Looks like I did it correct - no WARNINGs. # diff -uprN /boot/config-3.8.0-rc6-next20130208-1-iniza-small /boot/config-3.8.0-rc6-next20130208-6-iniza-small --- /boot/config-3.8.0-rc6-next20130208-1-iniza-small 2013-02-08 09:34:59.000000000 +0100 +++ /boot/config-3.8.0-rc6-next20130208-6-iniza-small 2013-02-08 17:36:02.000000000 +0100 @@ -601,6 +601,7 @@ CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y # # x86 CPU frequency scaling drivers # +CONFIG_X86_INTEL_PSTATE=y CONFIG_X86_PCC_CPUFREQ=y CONFIG_X86_ACPI_CPUFREQ=y CONFIG_X86_ACPI_CPUFREQ_CPB=y # dmesg | grep -i pstate [ 0.387256] Intel pstate controlling: cpu 0 [ 0.387273] Intel pstate controlling: cpu 1 [ 0.387286] Intel pstate controlling: cpu 2 [ 0.387303] Intel pstate controlling: cpu 3 [ 151.315937] Intel pstate controlling: cpu 1 [ 151.329400] Intel pstate controlling: cpu 2 [ 151.342778] Intel pstate controlling: cpu 3 So, suspend-resume is good here. - Sedat - ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-pm] linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ] 2013-02-08 16:51 ` Sedat Dilek @ 2013-02-08 16:55 ` Viresh Kumar 0 siblings, 0 replies; 15+ messages in thread From: Viresh Kumar @ 2013-02-08 16:55 UTC (permalink / raw) To: sedat.dilek Cc: Rafael J. Wysocki, Stephen Rothwell, x86, linux-kernel, Linux ACPI, Hillf Danton, linux-next, Linux PM List, Chuansheng Liu, Ingo Molnar On 8 February 2013 22:21, Sedat Dilek <sedat.dilek@gmail.com> wrote: >> No, it did NOT apply cleanly and I merged your tree like this. Patch looks fine to me. >> To me it does not look like your changes from the patch you sent me >> are included? Yes they do. Check most of the changes from cpufreq.c which remove locks around init/exit. > Looks like I did it correct - no WARNINGs. > > So, suspend-resume is good here. Great!! ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2013-02-08 16:55 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-02-08 8:46 linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ] Sedat Dilek 2013-02-08 11:53 ` Hillf Danton 2013-02-08 12:47 ` Sedat Dilek 2013-02-08 13:21 ` Rafael J. Wysocki 2013-02-08 13:58 ` Ingo Molnar 2013-02-08 14:15 ` Sedat Dilek 2013-02-08 14:50 ` Viresh Kumar 2013-02-08 15:19 ` Sedat Dilek 2013-02-08 14:45 ` [linux-pm] " Viresh Kumar 2013-02-08 14:48 ` Sedat Dilek 2013-02-08 14:56 ` Viresh Kumar 2013-02-08 15:21 ` Sedat Dilek 2013-02-08 16:28 ` Sedat Dilek 2013-02-08 16:51 ` Sedat Dilek 2013-02-08 16:55 ` 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.